Wireless transmit / receive unit and method for performing same

Abstract

A wireless transmit / receive unit and a method performed by the same are disclosed. The method includes receiving configuration information indicating a persistent sidelink listen-before-talk failure (CSLF) parameter; determining a CSLF associated with a resource set of a resource pool, wherein the determination of the CSLF is based on a number of listen before talk (LBT) failures associated with the resource set of the resource pool; determining that the CSLF associated with the resource set is not cancelled; and selecting, for a sidelink (SL) transmission, a resource from the resource pool that does not include the resource set associated with the CSLF based on a determination that the CSLF associated with the resource set is not cancelled.

Description

[0001] This divisional application is a divisional application with the application date of October 31, 2022, application number 202280079877.7, and invention name “Continuous Sidelink Listen-Before-Speak Failure”.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application claims the benefit of Provisional U.S. Patent Application No. 63 / 275,354 filed on November 3, 2021 and Provisional U.S. Patent Application No. 63 / 388,030 filed on July 11, 2022, the disclosures of which are incorporated herein by reference in their entirety. Background Art

[0004] Mobile communications using wireless communications continue to evolve. The fifth generation of mobile communications radio access technology (RAT) may be referred to as 5G New Radio (NR). The previous generation (legacy) mobile communications RAT may be, for example, fourth generation (4G) long term evolution (LTE). Wireless communication devices may establish communications with other devices and data networks, for example, via access networks such as radio access networks (RAN). Summary of the invention

[0005] Disclosed herein are systems, methods, and tools for handling a persistent sidelink (SL) listen-before-talk (LBT) failure (CSLF). A wireless transmit / receive unit (WTRU) may perform a listen-before-talk (LBT) procedure associated with a sidelink (SL) bandwidth. The SL bandwidth may include a set of resource blocks (RBs). The WTRU may determine a CSLF associated with the set of RBs of the SL bandwidth based on the LBT procedure. The WTRU may determine resources for reporting the CSLF, for example, based on a priority rule. The priority rule may indicate that a licensed resource has a higher priority than an unlicensed resource. The priority rule may indicate that if a persistent LBT failure is not detected on an unlicensed uplink (UL) resource, the unlicensed UL resource has a higher priority than the unlicensed SL resource. The WTRU may send a medium access control (MAC) control element (CE) using the determined resources. In an example, the MAC CE may indicate an identification of the RB set and / or the WTRU associated with the SL bandwidth.

[0006] The priority rule may indicate that if no CSLF is detected on a first unlicensed SL resource and a CSLF is detected on a second unlicensed SL resource, the first unlicensed SL resource has a higher priority than the second unlicensed SL resource. The priority rule may indicate that if a persistent LBT failure is detected on an unlicensed UL resource and no CSLF is detected on the unlicensed SL resource, the unlicensed UL resource has a lower priority for CSLF reporting than the unlicensed SL resource.

[0007] The WTRU may switch from a first RB set to a second RB set based on determining one or more LBT failures on the first RB set. The WTRU may detect a CSLF on the first RB set, for example, by performing a first LBT process including at least one LBT attempt for TB transmission. The WTRU may determine the second RB set based on the detection of the CSLF associated with the first RB set. In an example, the WTRU may perform a second LBT process associated with the second RB set. The WTRU may determine that the second LBT process is successful or that the number of LBT failures associated with the second RB set is less than a value. The WTRU may determine the TB associated with the first RB set and transmit the TB using the second RB set. In some examples, the WTRU may transmit the TB associated with the first RB using the second RB set based on receiving SL control information (SCI) associated with the second RB set from another WTRU associated with the second RB set. The first RB set and the second RB set may be associated with the same data resource pool or with different data resource pools.

[0008] For example, when the number of SL LBT failures associated with an RB set (e.g., the first RB set) is equal to or greater than a value, the WTRU may determine the CSLF associated with the RB set based on the number of SL LBT failures associated with the RB set. For example, if the WTRU determines that an SCI has not been received from another WTRU associated with the RB set within a certain period of time, the WTRU may increment the number of SL LBT failures associated with the RB set. If the WTRU determines that a channel busy rate (CBR) associated with the RB set is equal to or greater than a value, the WTRU may increment the number of SL LBT failures associated with the RB set. In an example, the LBT process may include determining whether the SCI is received from another WTRU associated with the RB set or determining the CBR associated with the RB set. The WTRU may increment the number of SL LBT failures associated with the RB set based on the LBT process.

[0009] The WTRU may indicate a SL LBT failure to a base station. The WTRU may perform an LBT procedure including one or more LBT attempts. The WTRU may determine that an LBT attempt for a set of RBs was unsuccessful. The WTRU may determine a SL LBT failure associated with the set of RBs based on the unsuccessful LBT attempt for the set of RBs. The WTRU may send an indication of the SL LBT failure to the base station, for example using a MAC CE or using a negative acknowledgement of a physical uplink control channel (PUCCH) transmission from the base station.

[0010] The WTRU may perform multiple LBT attempts on corresponding RB sets in the configured RB sets. The WTRU may receive configuration information indicating multiple RB sets. The WTRU may perform corresponding LBT attempts on the RB sets in the configured RB sets. The WTRU may determine that the LBT attempt on the RB set in the configured RB set is successful. The WTRU may transmit a TB using the RB set associated with the successful LBT attempt. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

[0013] Figure 1C It is shown that according to the embodiment, Figure 1A A system diagram of an exemplary radio access network (RAN) and an exemplary core network (CN) for use within a communication system is shown.

[0014] Figure 1D It is shown that according to the embodiment, Figure 1A A system diagram of another exemplary RAN and another exemplary CN for use within the communication system is shown.

[0015] Figure 2 are examples of detected CSLF and LBT faults reported on the Uu link.

[0016] Figure 3 An example 300 of reporting a CSLF is shown.

[0017] Figure 4 An example 400 of SL resource switching is shown. DETAILED DESCRIPTION

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

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

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

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

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

[0023] More specifically, as noted above, the communication system 100 may be a multiple access system and may employ one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base station 114a in the RAN 104 / 113 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish the air interface 115 / 116 / 117. 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 ​​UL Packet Access (HSUPA).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0045] Figure 1C The illustrated CN 106 may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. While each of the foregoing elements is depicted as being 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 a CN operator.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0072] A wireless transmit-receive unit (WTRU) may be configured to indicate a SL failure (e.g., LBT failure, CSLF, etc.) to a network. The WTRU may perform an LBT operation associated with a SL. The WTRU may determine a CSLF associated with the SL. The CSLF may be determined based on the number of SL LBT failures being higher than a value. The WTRU may increase the number of SL LBT failures based on one or more failure events. The failure event may include a condition that no SL control information (SCI) is received from another WTRU on a bandwidth (BW) associated with the LBT operation. The failure event may include a condition that a channel busy rate (CBR) is lower than a specific value. The WTRU may determine a carrier for reporting a CSLF associated with the SL, for example, based on a priority rule. For example, the priority rule may indicate that a licensed carrier (e.g., a licensed SL carrier or a licensed UL carrier) has a higher priority than a UL carrier (e.g., an unlicensed UL carrier) in which a persistent LBT failure is not detected. The priority rule may indicate that a UL carrier (e.g., an unlicensed UL carrier) in which a persistent LBT failure is not detected has a higher priority than an unlicensed SL carrier in which a CSLF associated with an unlicensed SL carrier is not detected. The WTRU may report the CSLF associated with the SL to the base station using the determined carrier. For example, the indication of the CSLF may be multiplexed on a transport block. The indication of the CSLF may include a medium access control (MAC) control element (CE) that includes a destination WTRU ID and / or a set of resource blocks where the CSLF was detected. In some examples, the WTRU may be configured to report an indication of a SL LBT failure to the base station (e.g., a NACK on the PUCCH or a MAC CE for each SL LBT failure).

[0073] The WTRU may report an indication of LBT failure (e.g., NACK or explicit indication on PUCCH), received signal strength indicator (RSSI), or channel occupancy, for example, to a base station such as a gNB. The WTRU may be configured to detect CSLF on a SL channel. If both the UL (e.g., Uu link) and the SL are on the same carrier, a persistent LBT failure may be detected on both in the event that a persistent LBT failure is detected on either medium access control (MAC) entity. The WTRU may be configured to multiplex the SL LBT failure MAC control element (CE) on a transport block (TB) (e.g., a new TB) and may transmit a TB on Uu, which may include whether LBT on the SL or Uu has failed and the destination WTRU ID in the CE content. The WTRU may be configured to prioritize carriers for transmitting MAC CEs according to the following order of availability: licensed carriers (e.g., SL licensed carriers or UL licensed carriers), UL carriers where no persistent LBT failure is detected (e.g., unlicensed UL carriers), unlicensed SL carriers where no persistent sidelink LBT failure (CSLF) is detected. The WTRU may be configured to relay a TB using the Uu-PUSCH and may include the destination WTRU ID for the TB, for example, if a peer WTRU is within coverage.

[0074] The WTRU may be configured to detect CSLF on the SL channel. The WTRU may be configured to switch to (e.g., select) a different data resource pool on a different LBT bandwidth (e.g., carrier, BWP, or sub-BWP). The WTRU may be configured to transmit an LBT failure indication (e.g., SCI or SL LBT failure MAC CE), which may include the destination WTRU ID in the CE content. The WTRU may be configured to relay the LBT failed TB via a different third WTRU connected to the receiving WTRU. The WTRU may be configured to relay the LBT failure indication, SCI, or LBT failure MAC CE via a third WTRU connected to the peer WTRU.

[0075] The WTRU may switch RB sets, for example, after an LBT failure. The peer WTRU may provide a channel sensing indication to the tx WTRU, which indicates, for example, which of the monitored RB sets are sensed as idle. The tx WTRU may include, for example, an SCI or MAC CE transmission along with TB / SL data, which indicates which RB sets are sensed as idle. After an LBT failure, the peer WTRU may switch to another RB set from the monitored RB set to transmit a hybrid automatic repeat request (HARQ) feedback or SCI in response to the received SL data. For example, after receiving feedback, acknowledgment, or SCI from the peer WTRU, the txWTRU may retransmit TBs that were not acknowledged or associated with a failed LBT operation on a different RB set or resource pool. The tx WTRU may maintain a CSLF process, for example, based on RB sets.

[0076] References to gNB herein may refer to an exemplary base station, and gNB may be replaced with any other suitable base station. References to timers herein may refer to a time, a time period / duration, a tracking time, a tracking time period / duration, etc. References to starting a timer may refer to a time period / duration having started, having started to be tracked, etc. References to timer expiration herein may refer to a determination that a time has occurred or a determination that a time period / duration has expired. References to a timer running may indicate that the time period / duration started / tracked has not expired. References to counters herein may refer to a number of event occurrences, a tracking number of event occurrences, etc. References to counter expiration herein may refer to a determination that the number of event occurrences has reached or exceeded a predefined limit / threshold.

[0077] Unlicensed operation may be implemented. Channel access in unlicensed bands may use a listen-before-talk (LBT) mechanism. In some examples, LBT may be enforced, for example, independently of whether the channel is occupied. In some examples, transmission (e.g., immediate transmission) may be applied after a short switching gap.

[0078] In the case of a frame-based system, LBT can be characterized by a clear channel assessment (CCA) time (e.g., approximately 20 μs), a channel occupancy time (e.g., minimum 1 ms, maximum 10 ms), an idle period (e.g., a minimum of 5% of the channel occupancy time), a fixed frame period (e.g., equal to the channel occupancy time + idle period), a short control signaling transmission time (e.g., a maximum duty cycle of 5% within an observation period of 50 ms), and / or a CAA energy detection threshold.

[0079] In the case of a load-based system (e.g., where the transmit / receive structure may not be fixed in time), the LBT may be characterized by a number N corresponding to the number of idle slots in the extended CCA (e.g., rather than a fixed frame period). N may be selected within a range (e.g., randomly).

[0080] Radio access technology (RAT) operation (e.g., new radio (NR) operation) may be implemented in an unlicensed band. RAT operation (e.g., NR operation) may support flexible transmission duration within a timeslot. RAT operation (e.g., NR operation) may support configuration grant type 1 for UL transmission, for example, where the network may (e.g., semi-statically) configure the UL grant and the WTRU may use the UL grant without L1 indication / activation (e.g., autonomously). Configuration grant type 2 may be similar to type 1 and may take into account L1 indication / activation. RAT (e.g., NR operation) may support DL SPS resources (or DL ​​configuration grants) on which the WTRU may receive, for example, DL data regarding an active DL CG without the need for scheduling necessary for each DL transport block (TB).

[0081] RAT operations (e.g., NR operations) in an unlicensed band (NR-U) may be supported for a Uu link between a WTRU and a base station (e.g., a gNB), which may include initial access, scheduling / HARQ, and mobility. Coexistence methods with other RATs (e.g., LTE License Assisted Access (LAA) or other existing RATs) may be supported. Deployment scenarios may include different independent RAT-based (e.g., NR-based) operations, different variants of dual connectivity operations (e.g., EN-DC with at least one carrier operating according to an LTE radio access technology (RAT) or NR DC with at least two sets of one or more carriers operating according to an NR RAT), and / or different variants of carrier aggregation (CA) (e.g., which may include different combinations of zero or more carriers of each of LTE and NR RATs). RAT unlicensed operations (e.g., NR-U) may support configuration grant transmissions for configuration grants and / or CBG-based transmissions.

[0082] RAT unlicensed operation (e.g., NR-U) may support a side link (SL) between WTRUs. PHY layer signals and / or channels may be modified to, for example, support RAT operation (e.g., NR operation) in an unlicensed spectrum. In order to support RAT operation (e.g., NR) in an unlicensed spectrum, one or more of the following modifications may be made to the PHY layer signals and / or channels. The modification may be to enhance DCI 2_0 to provide a time domain and frequency domain channel occupancy time (COT) structure. The modification may be to introduce a search space group switching feature, for example, where the WTRU may be controlled (e.g., dynamically) to perform PDCCH monitoring using one of two sets of search space sets. The modification may be to introduce an additional PDSCH mapping type B length to enable transmission at the start of the COT (e.g., immediately), for example, in response to a COT being initiated. The modification may be that the search space may be configured with multiple monitoring locations in the frequency domain, for example, to enable PDCCH monitoring across multiple LBT bands. The modification may be to introduce an interleaving structure for PUCCH and PUSCH and / or to extend the PUCCH format to a PRB interleaving waveform and include it in one RB set. The modification may be that SRS transmission may be on a symbol of a time slot (e.g., any symbol of a time slot). The modification may be that a base station (e.g., gNB) can schedule multiple consecutive PUSCHs through a single DCI format.

[0083] A WTRU operating in a shared spectrum may perform LBT to access a channel (e.g., using a PHY layer procedure). RAT unlicensed operation (e.g., NR-U) may support dynamic channel access (e.g., using load-based equipment (LBE)) and semi-static channel access (e.g., using frame-based equipment (FBE)). In the case of FBE, a base station (e.g., only a base station, which may be a gNB) may be able to initiate COT at a specific time notified by its FFP (fixed frame period) configuration. The WTRU may (e.g., may be able to) share a semi-static channel if a gNB DL transmission is detected in an earlier part of the same FFP. The WTRU may be configured with UE-FFP and may initiate COT at a specific time determined according to its WTRU-FFP configuration.

[0084] CCA (clear channel assessment) may be performed in units of a frequency range (eg, 20 MHz). The following types of LBT (listen before talk) may be specified: CAT4 LBT (type 1); CAT2 LBT (type 2A); CAT2 LBT (type 2B); and / or CAT1 LBT (type 2C).

[0085] The COT may be initiated, for example, using CAT4 LBT. The COT may be shared by nodes that receive transmissions from the COT initiating node (eg, using CAT2 LBT or CAT1 LBT), which may depend on the size of the gap between transmissions at the switching point.

[0086] Persistent UL LBT failure may occur. A radio link failure (RLF) due to a radio link failure (e.g., UL radio link failure) may be triggered in response to reaching a maximum number of retransmissions indicated by the RLC and / or in response to reaching a maximum number of preamble transmissions resulting in random access problems indicated by the MAC. Such triggering may occur too late in unlicensed operation (e.g., NR-U) scenarios, for example, where channel acquisition load conditions may (e.g., unexpectedly) increase (e.g., due to hidden nodes or persistent interference affecting one direction). Additional RLF criteria may be used that are triggered in situations where the WTRU fails to (e.g., repeatedly) access the channel.

[0087] The channel may be asymmetric for the UL direction and the DL direction (e.g., due to hidden nodes). In the case of a sidelink, a first WTRU (e.g., a receiving WTRU) may be able to sense the channel as idle, while a second WTRU (e.g., a transmitting WTRU) may not be able to acquire the channel (e.g., due to spatial interference affecting one of the two WTRUs). Radio link failure and recovery mechanisms based on LBT failure may (e.g., preferably) be handled separately from radio link failure and recovery mechanisms used by the gNB or for RLF on the sidelink. For example, given that some MAC counters used for UL procedures (e.g., RACH and / or SR) may not increment in the event of a UL LBT failure, an explicit RLF mechanism based on UL LBT failure may be used (e.g., may be required).

[0088] Hidden nodes may exist and may affect channel acquisition. In the case where the RSSI or CO measures interference from hidden nodes, the WTRU may not be able to report the RSSI / CO (e.g., because it cannot access the channel). The reporting periodicity may not be timely enough for the WTRU to determine the occurrence of a persistent LBT failure and / or take necessary corrective actions on time (e.g., due to newly arrived hidden nodes), for example, given that the RSSI is reported periodically. A persistent UL LBT failure may be characterized by the number of repetitions of the UL LBT failure being detected. Such a failure may be reported by the WTRU to the network on different serving cells. In one or more examples herein, persistent LBT failure and persistent LBT failure may be used interchangeably.

[0089] Mechanisms for recovery and / or reporting of persistent UL LBT failure may be supported for the Uu link. The WTRU may detect a persistent UL LBT failure and may trigger a persistent UL LBT failure, for example, in response to counting a configured number of LBT failures. The WTRU may report the LBT failure to the gNB after declaring a persistent LBT failure on a given cell, for example, by multiplexing the LBT failure MAC CE in an available UL grant. The WTRU may trigger a recovery procedure after detecting a UL LBT failure on a SpCell, for example, by switching to a different bandwidth part (BWP) on which the UL LBT failure may not have been detected and / or by initiating a RA procedure (e.g., a new RA procedure) on the BWP.

[0090] Here, the term LBT failure may imply that the WTRU was unable to acquire a channel for a UL or SL transmission attempt after the CCA portion of the LBT procedure, which may be determined based on, for example, receiving a notification of the LBT failure and / or an indication of the LBT failure from the physical layer. Here, the term LBT success may imply that the WTRU was able to acquire a channel for a UL or SL transmission attempt after the CCA portion of the LBT procedure, which may be determined based on, for example, receiving a notification of the LBT failure and / or an indication of the LBT failure from the physical layer. If the channel sensing measurement (e.g., RSSI) is above a threshold, the WTRU may determine that the LBT operation has failed.

[0091] A MAC CE (e.g., SL LBT Failure MAC CE) may be used to indicate a detected LBT failure. A detected LBT failure may be reported by the WTRU using one or more of a MAC CE, a CE, or uplink control information (UCI). In this document, the term RB set and the term LBT bandwidth may be used interchangeably, either of which may be used to refer to a bandwidth subset of a carrier (e.g., a carrier performing LBT operation).

[0092] For example, due to hidden nodes and / or spatially separated inter-system interference, the acquisition probability of an unlicensed channel may not be symmetric between different directions of the communication link. In an example associated with SL, a first WTRU (e.g., a receiving WTRU) may be able to sense a channel as idle, while a second WTRU (e.g., a transmitting WTRU) may not be able to acquire the channel, for example, due to spatial interference affecting one of the first WTRU and the second WTRU. The gNB may sense the channel as IDLE, while a WTRU (e.g., a WTRU intending to transmit on the SL channel) may sense the channel as occupied, for example, due to systematic (e.g., non-temporal) interference affecting the SL channel, which may occur persistently, for example.

[0093] On the SL (e.g., unlike Uu), the gNB may not be aware of the success or failure of the WTRU's LBT attempt for transmission on a scheduling grant or configuration grant that may be issued for SL Mode 1. For example, by performing blind detection on the UL grant resources on the UL (e.g., Uu link), the gNB may not be able to detect whether the WTRU's LBT attempt succeeded or failed (e.g., because the gNB is not a receiving node). The gNB may not be able to issue a retransmission grant (e.g., dynamically), for example, without feedback from the transmitting WTRU. The retransmission grant may indicate different parameters that may enhance the channel acquisition probability. If the UL is on licensed spectrum, the WTRU may transmit HARQ feedback on the PUCCH. If the UL and SL are on unlicensed spectrum, the transmitting WTRU may not transmit on the SL or PUCCH, for example due to systematic spatial interference.

[0094] In case of SL transmit mode 2, the gNB and / or receiving WTRU may be unaware of an LBT failure on a SL channel that may occur to a WTRU (e.g., a WTRU that intends to transmit on the SL channel). The WTRU experiencing the LBT failure may be outside the network coverage.

[0095] SL LBT failures may occur continuously. CSLF may be detected. Recovering from and / or reporting CSLF may be beneficial. In one or more examples herein, recovering from and / or reporting CSLF may mitigate the problem before declaring RLF on the SL channel. In one or more examples herein, the term triggered CSLF and the term declared CSLF may be used interchangeably. The terms triggered CSLF and declared CSLF, etc. may be used interchangeably.

[0096] The WTRU may be configured to monitor, maintain discovery, detect, declare and / or report CSLF. The WTRU may maintain and / or monitor the CSLF state, for example, by counting the number of failure events (e.g., channel access failure events). The WTRU may use a counter (e.g., a CSLF counter) to count the number of failure events. For example, if the CSLF counter is greater than or equal to a value (e.g., a configurable value), the WTRU may trigger a CSLF reporting and / or recovery procedure. For example, if a duration associated with the CSLF (e.g., an associated CSLF timer) expires, the WTRU may reset the CSLF counter (e.g., to 0).

[0097] The WTRU may start a timer, for example, in response to having counted the number of LBT failures on the SL. In response to the expiration of such a timer, the WTRU may trigger a CSLF. The WTRU may increment the CSLF counter once (e.g., only once) during a configured or predefined period. When one or more LBT failures occur, the WTRU may count (e.g., only count) a single LBT failure.

[0098] The WTRU may determine the number of failure events, for example, by using a counter. When a failure event is determined, the counter may be incremented. The counter may include a CSLF counter. The CSLF counter may count failure events. The failure event may include an LBT failure caused by a transmitting WTRU, for example, on SL or Uu, or an LBT failure on SL and Uu. The failure event may include an LBT failure caused by a receiving WTRU. The failure event may include an LBT failure caused by a peer WTRU (e.g., a WTRU different from the WTRU maintaining the counter). The failure event may include an LBT failure on a channel for Uu (e.g., only for Uu) or a channel for SL (e.g., only for SL) or a channel for Uu and SL. For example, the WTRU may perform an LBT procedure (e.g., a procedure including CCA) over the SL bandwidth. The WTRU may determine a failure event based on the LBT procedure performed. The failure event may include an LBT failure on a SL resource (e.g., a sub-resource).

[0099] A failure event may include an LBT failure on a resource pool or RB set. For example, the SL bandwidth over which the LBT process is performed may include a set of RBs. A failure event may occur on a set of RBs of the SL bandwidth. A failure event may include a failure to receive a transmission from a peer WTRU. A failure event may include a failure to receive a HARQ-ACK (e.g., on a physical sidelink feedback channel (PSFCH)) from a peer WTRU. A failure event may include a failure to detect an SCI from a peer WTRU. A failure event may include a situation where a CBR value is above or below a threshold. A failure event may include an RSSI measurement above or below a threshold. A failure event may include receiving an indication of a failure event from a peer WTRU. A failure event may include the expiration of a delay budget window. A failure event may include an LBT failure of a particular type of LBT operation (e.g., LBT type 1 or type 2). A failure event may be determined based on whether the LBT failure is due to inter-WTRU blocking on the SL channel. A failure event may be determined based on whether the LBT failure is reported (e.g., to the gNB). A fault event may be determined based on whether the channel access priority class (CAPC) type of the LBT operation being performed is from a particular subset (eg, has a particular priority or is above a particular value).

[0100] An LBT failure may be defined as a failure to complete the LBT process for a transmission in a timely manner. An LBT failure may be defined as sensing energy on a channel greater than a threshold. For example, the WTRU may increment the CSLF counter in (e.g., only in) a subset of conditions that are met (e.g., only in a subset of failure events that occur here).

[0101] A timer (eg, a CSLF timer) may be started or restarted by any of the fault events described herein and / or after a value (eg, a configured or determined counter value) is reached.

[0102] The WTRU may maintain and / or monitor the CSLF state, for example, by decrementing a CSLF timer at (e.g., each) time slot or transmission opportunity. A transmission opportunity may be a resource or time instance at which the WTRU may perform a transmission, or a resource or time instance at which the WTRU has performed a transmission, or a resource or time instance at which the WTRU has attempted to perform a transmission and failed due to a channel access failure event. For example, if the timer has expired, the WTRU may trigger a CSLF reporting and / or recovery procedure.

[0103] The WTRU may determine whether to count a failure event, for example, based on one or more of a signal type, a channel type, a sub-channel, or a resource pool. For example, the WTRU may maintain different CSLF counters for different signal types, different channel types, different sub-channels, and / or different resource pools. For example, the WTRU may maintain a CSLF counter based on one or more of: based on an RB set, based on an L2 ID, based on a broadcast ID, based on a broadcast type (e.g., unicast, multicast, or broadcast), based on an SL BWP, based on a carrier, and / or based on an SL channel (e.g., based on an SL bandwidth). The WTRU may reset a CSLF counter, for example, based on a change (e.g., when switching to another RB set or another resource pool associated with a different LBT channel).

[0104] The WTRU may maintain multiple LBT processes (e.g., CSLF detection processes). In an example, the LBT processes may be performed simultaneously. For example, the WTRU may maintain the process based on the RB set or maintain the process based on the resource pool. Based on switching to a different RB set, the WTRU may, for example, reset the maintained process on the RB set. Resetting the maintained process may include resetting the detection counter and / or the detection time (e.g., the detection timer). In an example, the WTRU may perform an LBT process on a resource set (e.g., an RB set or a resource pool, etc.), and if the LBT process fails, the WTRU may increment the detection counter associated with the resource set (e.g., only the detection counter associated with the resource set) and / or may restart the detection time associated with the resource set (e.g., only the detection time associated with the resource set).

[0105] The WTRU may determine whether to count a failure event (e.g., using a CSLF counter), for example, based on the cause of the interference. For example, if the cause of the interference is from a peer WTRU, another WTRU from a shared resource pool, or from another node, the WTRU may determine whether to count a failure event. The WTRU may distinguish the cause of interference, for example, based on a CBR value or based on detection and decoding of an SCI (or preamble).

[0106] For example, the WTRU may count failures of LBT operation if (e.g., only if) the CBR value is below (or equal to) a certain value, or, for example, the WTRU may count LBT failures if (e.g., only if) the CBR value is above the value. The value may include a threshold. For example, a CBR value below the value may indicate that the LBT failure is not due to inter-WTRU blocking. In some examples, the WTRU may count LBT failures based on one or more of the CBR value, RSSI, or RSRP. The WTRU may count LBT failures if the CBR value is below a first value such as a first threshold and / or if a channel measurement (e.g., RSSI or reference signal received power (RSRP)) is above or equal to (or below) a second value such as a second threshold. The WTRU may count LBT failures based on determining that the CBR value is within a range. For example, if the CBR value is below a first value such as a first threshold and the CBR value is above a second value such as a second threshold, the WTRU may, for example, count LBT failures.

[0107] The WTRU may maintain different counters for SL transmission and SL feedback. The WTRU may maintain different timers for SL transmission and SL feedback. In an example, the WTRU may maintain a first counter and / or timer for SL transmission to a peer WTRU. The WTRU may maintain a second counter and / or timer for SL reception of feedback from a peer WTRU or SL transmission of feedback to a peer WTRU. Upon expiration of a timer (e.g., a first timer or a second timer as described herein), the txWTRU may determine a HARQ feedback value, and, for example, if feedback or SCI has not been received from the peer WTRU, the tx WTRU may assume the HARQ feedback value to be a specific value (e.g., NACK). The peer WTRU (e.g., rx WTRU) may monitor SCI reception (e.g., attempt to decode it), for example, at a preconfigured or predetermined time related to the timing of the LBT process (e.g., LBT timing) and / or the start of the receive resource. For example, if a transmission (eg, SCI or data) has not been received from the tx WTRU (eg, no transmission has been received) and / or a timer has expired, the peer WTRU may switch to another RB set.

[0108] A peer WTRU may transmit an SCI indicating that a channel (e.g., RB set or LBT BW) is sensed as idle. A peer WTRU may, for example, detect a tx WTRU and / or send a channel sense SCI (and / or other data / control information) after a period of time has elapsed without receiving data or control information from the tx WTRU.

[0109] For example, the WTRU may count failures of LBT operation if (e.g., only if) an SCI is received from an rx node (e.g., a peer WTRU). In an example, for example, the tx WTRU may increment a CSLF counter if (e.g., only if) an SCI received from an rx node indicates that the channel is sensed as idle / free / available for transmission. A peer WTRU (e.g., a peer WTRU operating as an rx node) may transmit an indication (e.g., in an SCI or MAC CE) indicating a set of RBs sensed as idle and / or assumed to be available (e.g., from the perspective of the peer WTRU, for data or control information transmission). The peer WTRU may sense the channel and then send an indication (e.g., an indication indicating whether to "clear to send"), for example, based on one or more RB sets, which may, for example, be within a given resource pool or span more than one resource pool. For example, if an SCI is received by a tx WTRU from a peer WTRU indicating an idle channel on the set of RBs of interest, the tx WTRU may use the notification (e.g., here the indication) to determine if the LBT failure is due to a hidden node (e.g., a hidden node that affects only the tx WTRU and not the rx WTRU). In some examples, for example, if no SCI is received or if an SCI is received and indicates that the set of RBs of interest is sensed as occupied, the tx WTRU may use the notification to determine that interference is affecting multiple WTRUs (e.g., the rx WTRU and the tx WTRU). The tx WTRU may then use this information to determine, among other uses, whether a CSLF is detected.

[0110] The WTRU may be configured with CSLF parameters (e.g., via received configuration information, such as RRC configuration information). The CSLF parameters may reuse LBT failure detection parameters (e.g., persistent LBT failure detection parameters). The WTRU may be configured to activate and / or deactivate the CSLF detection procedure. The WTRU may be configured with CSLF parameters based on one or more of the following: per SL channel, per SL BWP, per SL carrier, per SL peer and / or per RB set. For example, based on switching to a different RB set, the txWTRU may use the parameters configured for the newly activated RB set.

[0111] For example, the WTRU may be configured with resources (e.g., PUCCH resources) on which the WTRU may report channel access behavior or performance of a SL channel. The WTRU may report (e.g., transmitted via PUCCH) a HARQ report (e.g., an enhanced HARQ report) that may indicate whether a NACK occurred due to a channel access failure event. The WTRU may forward a CSLF report and / or a value associated with a peer WTRU to a base station, for example, via a resource (e.g., a dedicated resource, such as a PUCCH resource). The base station may include a gNB. In the case where the WTRU has UL resources (e.g., dedicated UL resources) for reporting HARQ feedback (e.g., enhanced HARQ feedback) or the occurrence of one or more failure events, the WTRU may be configured to deactivate and / or disable a CSLF counter and / or timer. In some examples, in the case of reporting the occurrence of one or more failure events in the HARQ feedback (e.g., enhanced HARQ feedback) or the dedicated UL resources, the WTRU may reset the CSLF counter and / or timer.

[0112] For example, in the case where a transmission is dropped, the CSLF process may be maintained. The WTRU may drop a transmission based on the expiration of a duration (e.g., due to the expiration of a delay budget window). The WTRU may fail to perform a transmission (e.g., one, some, or all transmissions) during a delay budget window, for example, due to a channel access failure event. In response to a transmission being dropped due to the expiration of a delay budget window, the WTRU may report and / or declare a CSLF. The WTRU may report (e.g., to a base station) the failure to transmit a packet due to the expiration of a delay budget window. The WTRU may report (e.g., to a base station) whether the failure to transmit a packet due to the expiration of a delay budget window is caused by one or more channel access failure events. The WTRU may report (e.g., to a base station) the number of channel access failure events that occurred for a packet during a delay budget window (e.g., before the expiration of the delay budget window). The WTRU may report (e.g., to a base station) a percentage or ratio of available transmission resources. For example, the WTRU may report a percentage or ratio of available transmission resources during a delay budget window in which no transmission has occurred due to a channel access failure.

[0113] The WTRU may maintain a CSLF counter and / or a CSLF timer. If the delay budget window expires, the WTRU may not have further transmissions (e.g., scheduled and / or configured transmissions). The CSLF timer may expire and / or the WTRU may reset the CSLF counter. The CSLF timer expiration and / or resetting of the CSLF counter may or may not indicate the channel experienced by the WTRU. If the delay budget window expires, the WTRU may suspend the CSLF timer and restart the CSLF timer, for example, if a future or subsequent transmission is scheduled or configured. If the delay budget window expires, the WTRU may increment or increase the CSLF timer, for example, by a configurable value. If the delay budget window expires, the WTRU may suspend the CSLF timer and start a second timer. In the event that the WTRU is scheduled or configured for a subsequent transmission, the WTRU may stop the second timer and restart the CSLF timer. If the second timer expires (e.g., in the event that the WTRU is not scheduled or configured for a subsequent transmission), the WTRU may restart the CSLF timer.

[0114] The WTRU may use a partial CSLF count. For example, in the event that a delay budget window expires and / or there is an interruption between transmissions, the WTRU may use a partial CSLF count. For example, the WTRU may maintain a CSLF counter. If a CSLF timer expires, or if a CSLF timer expires and the WTRU has no scheduled and / or configured transmissions (e.g., if a delay budget window expires), the WTRU may scale the CSLF counter by a value (e.g., a configurable value). For example, if the channel access failure event counter (and in some examples, the CSLF timer) is restarted in response to a future failure event, the scaled CSLF counter value may be used as the initial counter value.

[0115] The WTRU may select resources for transmission or retransmission based on the listening results and the resource selection window. The resource selection window may, for example, start shortly after triggering resource selection in the WTRU (e.g., arrival of a TB). In an example, the maximum window size may be based on or limited to the remaining delay budget of the TB.

[0116] The WTRU may increment a detection counter (e.g., an LBT failure counter for detecting CSLF) once (e.g., only once) according to a detection period. The detection period may correspond to a resource selection window and / or may start at the beginning of the resource selection window. In an example, the detection period may start at the first transmission opportunity associated with a resource selected during the resource selection window. The detection period may start at the first LBT failure detected on a resource selected for transmission during the resource selection window. The detection period may be configured or determined to be the same duration as the resource selection window.

[0117] The WTRU may increment the detection counter once for a transmission and / or retransmission attempt for a particular HARQ process (e.g., only once for all transmission and / or retransmission attempts for a particular HARQ process). Such transmission / retransmission attempts may be associated with an SCI transmission that reserves or indicates multiple resources. Such transmission / retransmission attempts may be associated with multiple SL resources allocated by a DCI (e.g., a single DCI in Mode 1). For example, the WTRU may be associated with multiple transmission opportunities / attempts that the WTRU may use until an LBT attempt succeeds. In this case, the WTRU may increment the counter (e.g., only once after the LBT process fails for all opportunities).

[0118] The WTRU may count LBT failures from multiple LBT failures indicated by the PHY within a detection period (e.g., only count one LBT failure). The WTRU may receive x LBT failure indications from the WTRU PHY within a resource selection window. The WTRU may increment a detection counter (e.g., LBT failure counter) by one, e.g., only increment by one, within a detection period.

[0119] The WTRU may be configured with one or more PSFCH opportunities in a combined packet (e.g., multiple consecutive PSFCH opportunities for HARQ feedback transmission in unlicensed spectrum). The WTRU may increment the detection counter once per the combined packet in the event that the LBT process fails for feedback transmission on an opportunity within the combined packet (e.g., increment only once per the combined packet in the event that the LBT process fails for feedback transmission on all opportunities within the combined packet).

[0120] The WTRU may be configured with one or more SL-SCH data and / or control transmission opportunities (e.g., SCI) in a combined packet. Within a combined packet, if an LBT attempt fails within a transmission opportunity, the same TB may be retransmitted at the next opportunity, and / or if an LBT attempt fails within a transmission opportunity, the SCI may be retransmitted at the next opportunity within the combined packet. For example, after an LBT attempt fails within the last transmission opportunity within a combined packet and / or in the event that the LBT process has failed on a transmission opportunity within a combined packet (e.g., LBT attempts for all transmission opportunities within the combined packet have failed), the WTRU may increment the detection counter once per combined packet (e.g., only once per data and / or control combined packet). In an example, the WTRU MAC may ignore LBT failure indications received from the WTRU PHY (e.g., for transmissions in a combined packet) until the last opportunity, and / or may count one (e.g., only one) LBT failure indication for a combined packet (e.g., a bundled transmission of data and / or control information).

[0121] A CSLF process may be configured. A CSLF process may include a CSLF counter and / or a CSLF timer. The WTRU may be configured with parameters associated with the CSLF counter and / or timer. The CSLF process parameters may include one or more of the following: a maximum counter value; a counter scaling value; a timer duration; a maximum timer pause duration value; an associated LBT process or an associated LBT parameter set; an associated RB set or SL carrier; an associated WTRU or WTRU group; a recovery process associated with the CSLF process (e.g., whether the recovery and / or CSLF reporting performed is on Uu, whether the recovery involves switching to a different RB set). The WTRU may, for example, maintain different CSLF processes for different LBT parameter sets. In an example, the WTRU may have transmissions on different beams / channels, which may be associated with different LBT processes (e.g., each beam / channel may be associated with an LBT process). The WTRU may maintain separate CSLF processes (e.g., one CSLF process for each beam / channel).

[0122] The WTRU may receive a CSLF parameter configuration, for example, from a base station. The WTRU may have several CSLF parameter sets and may select a suitable set. The selection of a suitable CSLF parameter set may depend on at least one of: SL mode (e.g., Mode 1 or Mode 2); Channel Busy Rate (CBR) value; Maximum number of retransmissions; Traffic type; Broadcast destination ID; L2 destination ID; Broadcast type; Channel occupancy value; RSSI measurement value; or Channel or subchannel or resource pool (e.g., RB set or SL carrier used); Number of parallel HARQ processes or resource selection processes used by the WTRU in Mode 2.

[0123] The WTRU may determine the CBR value, for example, based on a CSLF determination. For example, the WTRU may modify the CBR value based on a CSLF declaration or a specific CSLF counter or timer value.

[0124] The LBT fault process may be configured. The WTRU may, for example, maintain an LBT fault process for a radio link between the WTRU and a base station (e.g., UL) on a shared or unlicensed spectrum, and maintain a CSLF process (e.g., for a SL on a shared or unlicensed spectrum). The LBT fault process may include a persistent LBT fault process. For example, the WTRU may independently maintain an LBT fault process and a CSLF process (e.g., each LBT fault / CSLF process). For example, the WTRU may determine whether to count fault events in the LBT fault process or count fault events in the CSLF fault process based on (e.g., according to) the type or purpose of the associated transmission (e.g., whether the transmission is for the UL or for the SL). In some examples, the SL and Uu links (e.g., links between a base station and the WTRU) may be on the same shared or unlicensed spectrum (e.g., frequency band or channel). In one or more examples herein, the Uu link may be in an unlicensed spectrum or a licensed spectrum. The WTRU may maintain a joint process (e.g., a single joint process, which may be a joint LBT fault detection process) to account for Uu or SL channel access failure events. Whether the WTRU may maintain a joint LBT failure detection procedure for the Uu link and the SL may depend on the LBT parameters used for the transmission of the Uu link and / or the SL. If the same LBT parameters for transmission (e.g., beam and / or channel) are used for the Uu link and the SL, the WTRU may maintain a joint LBT failure detection procedure. For example, if the same set of physical resources is used for LBT operation (e.g., the same BWP, carrier, and / or RB set), the WTRU may use the same CSLF procedure regardless of the destination rx node.

[0125] In some examples, the WTRU may maintain a first LBT fault detection process for the Uu link, a second CSLF fault detection process for the SL, and a third joint process for the Uu link and the SL. The WTRU may determine counter and / or timer parameters for one or more of such process types (e.g., for each process type).

[0126] The WTRU may determine whether to maintain a separate LBT fault detection process or a joint fault detection process (e.g., a single joint fault detection process) based on at least one of: an indication or configuration from a base station; an LBT type or parameter set; an unlicensed spectrum, channel, or resource set; a traffic type; or a previous result of a separate or joint LBT fault detection process. The WTRU may determine the fault report type, for example, based on whether a joint LBT fault process or separate LBT fault processes are used for the Uu link and the SL.

[0127] The CSLF process may be peer-dependent. A group of WTRUs (e.g., WTRUs sharing a resource pool) may maintain a peer-dependent CSLF process or a group of CSLF processes. The master WTRU may maintain the peer-dependent CSLF process or the group of CSLF processes. In response to detecting a failure event, the non-master WTRU may feedback a signal to the master WTRU to increase the group CSLF count and may start (or restart) a CSLF timer. In some examples, the CSLF count and / or timer may be fed back to the base station, or an update may be received from the base station.

[0128] A WTRU (e.g., a master WTRU) may determine whether to count reported failure events from another WTRU, for example, based on one or more of a broadcast ID, a broadcast type, or an L2 ID. The WTRU may count failure events in a group CSLF process, for example, based on a broadcast type (e.g., broadcast, multicast, or unicast). For example, a WTRU may count more than one (e.g., all) broadcast failure events in a group CSLF detection process.

[0129] A WTRU (e.g., a master WTRU) may determine and / or count up to N (e.g., N may be greater than or equal to 1) failure events based on a period. The period may be a set of transmission resources over which transmissions may occur. The period may be determined based on or associated with one or more of: a resource pool; an LBT bandwidth (BW); or an SL channel. Multiple WTRUs that experience a failure event simultaneously may not (e.g., unnecessarily) increment the CSLF counter. Unnecessarily incrementing the CSLF counter may result in premature CSLF declarations or reports.

[0130] The WTRU may declare and / or report a CSLF to a base station or a peer WTRU. In response to declaring a CSLF, the WTRU may start a timer. During the duration that the timer is running, the WTRU may not use the associated resource pool or the associated SL channel / subchannel. The WTRU may monitor the channel / subchannel / resource pool using a first monitoring state, for example, before declaring a CSLF. The WTRU may adapt its monitoring to a second monitoring state on the channel / subchannel / resource pool, for example, after declaring a CSLF, and in some examples, may start a timer. If the timer expires, the WTRU may assume that the channel / subchannel / resource pool is back to normal operation. The WTRU may (e.g., in response) return to the first monitoring state on the channel / subchannel / resource pool. The WTRU may indicate (e.g., to a base station or a peer WTRU) to return to normal operation on the channel / subchannel / resource pool.

[0131] A two-sided LBT failure may occur. In some scenarios, systematic interference may affect multiple WTRUs (e.g., both tx WTRUs and peer WTRUs). The WTRU may not be able to acquire a channel to transmit data and / or control information (e.g., one or more of SCI, HARQ feedback, or channel measurements). The WTRU may attempt to detect a CSLF (e.g., a CSLF with respect to a single unicast SL). The WTRU (e.g., tx WTRU) may update the value of an LBT failure counter (e.g., a CSLF counter) based on an indication received from a peer WTRU, for example, on the same set of RBs or a different set of RBs.

[0132] In an example, a first WTRU (e.g., an rx WTRU, a tx WTRU, or both WTRUs) may be configured to transmit a periodic or non-periodic "activity signal or SCI", such as in a situation where it may be multiplexed with one or more of other data, SCI (other SCIs), or a buffer status report. The activity signal or SCI may be associated with one RB set or multiple RB sets (e.g., for wideband operation or for overlapping RB sets). For missed activity signals or SCIs (e.g., for each missed activity signal or SCI), a second WTRU (e.g., another WTRU) may increment an LBT failure counter (e.g., a CSLF counter). The WTRU (e.g., the first WTRU and / or the second WTRU) may switch to one or more of the following based on the LBT failure counter reaching a value (e.g., a threshold of the maximum number of LBT failures counted): a different RB set, a different resource pool, a different carrier, and / or a different BWP. For a missed activity signal or SCI (e.g., for each missed activity signal or SCI), the WTRU (e.g., the other WTRU) may increment or start a timer (e.g., an LBT failure timer). The peer WTRU (e.g., the first WTRU and / or the second WTRU) may transmit an activity signal or SCI once, for example, according to each configured period (e.g., before or upon expiration of the LBT failure detection timer). The WTRU (e.g., the first WTRU and / or the second WTRU) may switch to one or more of: a different set of RBs, a different resource pool, a different carrier, and / or a different BWP based on the expiration of a detection timer (e.g., the LBT failure detection timer). The WTRU (e.g., the first WTRU and / or the second WTRU) may determine and / or declare a CSLF based on a detection timer (e.g., upon expiration of the LBT failure detection timer) or, for example, when a configured maximum number of counted failures is reached. A WTRU (e.g., a peer WTRU) may indicate to other WTRUs (e.g., a first WTRU and / or a second WTRU) the time elapsed since the last successful channel acquisition for a given RB set and / or the number of LBT failures counted for a given RB set. A WTRU (e.g., either WTRU herein) may reset an LBT failure counter (e.g., an LBT failure detection counter) and / or a timer (e.g., an LBT failure timer) upon successful channel acquisition (e.g., for the relevant RB set) or upon receiving an active signal, data, or control information from a peer WTRU (e.g., on the relevant RB set).

[0133] A WTRU (e.g., here, each of the two WTRUs) may be configured with multiple RB sets or resource pools, for example, on independent / different LBT bandwidths, independent / different resource pools, or independent / different carriers. The WTRU may blindly decode all or a subset of resource pools and / or RB sets to receive data or control information on a SL channel. The WTRU may determine which subset of resource pools and / or RB sets to monitor (or which subset of resource pools and / or RB sets to blindly decode) based on one or more of the following or in accordance with one or more of the following: resources used for the last transmission received, resources used to transmit feedback (e.g., PSFCH) in response to a received TB, and / or the time elapsed since the last transmission was received. For example, the WTRU may be configured with a switching mode such that if the time elapsed since the last received data / control information regarding RB set x and / or the time elapsed since HARQ feedback was transmitted in response to the data / control information regarding RB set x is greater than a configured first threshold, the WTRU may switch to blind decoding of RB set y, and if the time elapsed since the last received data / control information regarding RB set x and / or the time elapsed since HARQ feedback was transmitted in response to the data / control information regarding RB set x is greater than a second threshold, the WTRU may switch to blind decoding of RB set z. RB set x, RB set y, and RB set z may or may not overlap.

[0134] The WTRU may stop blind decoding a given RB set (e.g., a first RB set) based on one or more of the following: when data, control information, SCI, or an activity signal is received from a peer WTRU on a second RB set; when data, control information, SCI, or an activity signal is transmitted on the second RB set; and / or when an acknowledgement or confirmation is received in response to transmitted data or control signaling transmitted on the second RB set (e.g., including an indication that the peer WTRU has also stopped blind decoding the first RB set).

[0135] LBT failure detection may affect MAC and / or RLF procedures. SL RLF detection may be HARQ based. The WTRU may maintain a MAC counter for the SL procedure. When an LBT attempt fails for a SL transmission, the MAC counter may or may not be incremented. In an example, the WTRU may not increment the SL MAC counter or suspend counting the SL MAC counter based on detecting an LBT failure on resources used for transmissions associated with the SL MAC counter. The WTRU may avoid starting a MAC timer based on detecting an LBT failure on resources used for transmissions associated with the MAC timer.

[0136] The WTRU may not increment the value of the discontinuous transmission (DTX) parameter numConsecutiveDTX based on, for example, determining an LBT failure associated with expected reception of a PSFCH transmission from a peer WTRU. The WTRU may determine whether to increment the DTX parameter numConsecutiveDTX based on one or more of the following.

[0137] The WTRU may determine whether to increment the DTX parameter numConsecutiveDTX based on determining that a peer WTRU has successfully acquired the channel, but has not received the PSFCH. The WTRU may determine whether to increment the DTX parameter numConsecutiveDTX based on the absence of PSFCH reception at the PSFCH reception opportunity. The WTRU may determine whether to increment the DTX parameter numConsecutiveDTX based on whether a measured channel quality metric between multiple (e.g., two WTRUs) is greater than a configured threshold.

[0138] The WTRU may determine whether to increment the DTX parameter numConsecutiveDTX based on whether the measured channel occupancy or RSSI is above or below a configured threshold.The WTRU may be configured with predefined resources to measure channel occupancy or RSSI, for example, for unicast links between WTRUs.

[0139] The WTRU may determine whether to increment the DTX parameter numConsecutiveDTX based on receiving an indication from a peer WTRU that a channel has been acquired. For example, the WTRU may increment (e.g., only increment) the value if a periodic "active signal or SCI" or clear-to-send signal is received from a peer WTRU that transmits a PSFCH transmission (e.g., within the same portion of the COT where the PSFCH transmission is expected).

[0140] The WTRU may determine whether to increment the DTX parameter numConsecutiveDTX based on whether continuous LBT failure detection is configured for the SL MAC entity. For example, the WTRU may suspend counting numConsecutiveDTX if continuous LBT failure detection is configured, and may otherwise keep counting missed PSFCH transmissions if continuous LBT failure detection is not configured.

[0141] The WTRU may determine whether to increment the DTX parameter numConsecutiveDTX based on whether the PSFCH falls within the COT initiated by the WTRU. For example, if the tx WTRU shares a COT with a peer WTRU and still does not receive a PSFSCH transmission at a time that falls within the same COT, the tx WTRU may then increment the numConsecutiveDTX count; otherwise, if the COT is not shared, the WTRU may not increment numConsecutiveDTX, or increment it by half (or increment it at intervals when the WTRU fails to receive a PSFSCH transmission at a time within the same COT).

[0142] The WTRU may determine whether to increment the DTX parameter numConsecutiveDTX based on, for example, whether any other data or control signaling is received from the same unicast link / peer WTRU in the same COT. The WTRU may determine whether to increment the DTX parameter numConsecutiveDTX based on whether the WTRU's own transmission failed an LBT attempt in a time slot adjacent to a time slot where a PSFCH transmission was expected and DTX was received instead of a PSFCH transmission. A time slot is adjacent to another time slot if, for example, it is within a delta time period from the other time slot. The WTRU may determine whether to increment the DTX parameter numConsecutiveDTX based on whether the PHY indicates a certain RSSI (e.g., an RSSI greater than a threshold) on the time slot where a PSFCH transmission was expected and DTX was received instead of a PSFCH transmission.

[0143] The WTRU may skew or partially increment the DTX parameter numConsecutiveDTX (e.g., instead of pausing counting of the DTX parameter) based on satisfying one or more of the conditions described herein. For example, if the WTRU determines that an LBT attempt performed by a peer WTRU within a PSFCH opportunity has failed, the WTRU may increment the DTX parameter numConsecutiveDTX by half (or every other DTX count). In some examples, if the tx WTRU shares a COT with a peer WTRU and still does not receive a PSFSCH transmission at an opportunity that falls within the same COT, the tx WTRU may then increment the numConsecutiveDTX count, for example, by a scaled value. For example, if counting of the DTX parameter numConsecutiveDTX is not suspended due to an LBT failure, the WTRU may reset the DTX parameter numConsecutiveDTX (e.g., to a default value or zero) based on switching to a different resource pool and / or a different set of RBs (e.g., a different LBT bandwidth).

[0144] After determining that the LBT process performed by the peer WTRU has failed (including one or more failed LBT attempts within a PSFCH reception opportunity), the WTRU may change the DTX parameter numConsecutiveDTX. For example, the WTRU may keep a count of non-existent PSFCH opportunities, including opportunities that are missed due to one or more LBT failures at the peer WTRU; the WTRU may then decrement the counter by a value x, where x is indicated by the peer WTRU and / or determined by the WTRU itself based on the number of missed PSFCH opportunities (e.g., based on differences in channel measurements).

[0145] The WTRU may be configured with more than one value for the threshold parameter sl-maxNumConsecutiveDTX. The WTRU may apply the configured value based on one or more of the following: whether the WTRU is receiving a PSFCH transmission on an unlicensed spectrum or a licensed spectrum, the set of RBs or resource pools on which the PSFCH transmission is received, whether CSLF is configured, the measured CBR of the resource pool, or other conditions herein.

[0146] In some examples, if the WTRU attempts to transmit before, on the same time slot as, or after receiving the expected PSFCH resources for DTX and the LBT attempt performed by the WTRU has failed, the WTRU may skip incrementing the DTX parameter numConsecutiveDTX, subtracting a value from the DTX parameter numConsecutiveDTX, or resetting the DTX parameter numConsecutiveDTX.

[0147] The WTRU may be configured with one or more PSFCH reception opportunities in a combined package (e.g., multiple consecutive PSFCH opportunities for feedback reception in unlicensed spectrum). The WTRU may increment the DTX parameter numConsecutiveDTX after the last PSFCH reception opportunity in the combined package (e.g., only after the last PSFCH reception opportunity). For example, the WTRU may be configured with x PSFCH reception opportunities to monitor feedback reception after transmitting a TB in unlicensed spectrum to a peer WTRU. The WTRU may increment the DTX parameter numConsecutiveDTX after not receiving a PSFCH transmission at or after the xth PSFCH reception opportunity (e.g., after not receiving any PSFCH transmission at or after the xth opportunity). In some examples, the WTRU may increment the DTX parameter numConsecutiveDTX after not receiving any PSFCH transmission on any of the x PSFCH opportunities associated with the TB / HARQ process being monitored for feedback.

[0148] SL may take precedence over Uu link. The WTRU may prioritize SL transmissions over UL transmissions of the MAC entity or other MACs (e.g., other Uu transmissions) if one of the following conditions is met: the WTRU has acquired a COT on the SL channel; the WTRU has failed an LBT attempt on a Uu UL (e.g., on PUCCH, PUSCH, or RACH) transmission; the WTRU has acquired a COT for TB retransmissions on SL after one or more LBT failures; the MAC entity cannot perform SL transmissions simultaneously with other UL transmissions at the time of transmission.

[0149] A detected persistent LBT failure on the SL may be reported. An LBT failure (e.g., a single LBT failure) may be reported. The WTRU may indicate (e.g., to a base station, such as a gNB) a notification of an LBT failure, for example, in response to a failure in an LBT attempt due to a grant (e.g., a grant issued for Mode 1 SL scheduling). Reporting The CSLF described herein may be applicable to a WTRU transmitting in SL Mode 1 or SL Mode 2.

[0150] The WTRU may indicate a notification of an LBT failure to a peer WTRU (e.g., on a given RB set), for example, by transmitting a notification of an LBT failure on an SCI or MAC CE (e.g., a MAC CE portion of another RB set) when changing to a different RB set. Based on receiving such an SCI or MAC CE, the peer WTRU may switch to another indicated RB set and / or transmit feedback to the received LBT failure notification. The peer WTRU may also report one or more of the following to the tx WTRU, for example, on a per RB set basis: LBT failure or channel sensing / acquisition status, preferred resource pool or RB set, and / or CBR measurement. The peer WTRU may switch (e.g., autonomously, for example, without receiving a request) to a different RB set, for example, based on determining that the LBT operation of the tx WTRU has failed (e.g., multiple times) or that no data or control information has been received from the tx WTRU for a period of time (e.g., no data or control information has been received from the tx WTRU).

[0151] The indication may be provided as explicit signaling via one or more of: UCI on PUCCH, on PUSCH, and / or as part of a MAC CE. The indication may be implicitly implied, for example, the indication may be in the form of a HARQ NACK for a HARQ process, which may be transmitted on a subset of PUCCH resources associated with (or configured for) such indication. In response to the LBT failure, the WTRU may include information about the channel portion of the indication of the LBT failure reported to the base station, which may include one or more of RSSI, channel occupancy, resource set index, or information about resource allocation (e.g., allocation of LBT bandwidth, carriers, and / or BWP). The WTRU may provide information about the cause of the LBT failure in the indication, for example, whether the LBT failure is due to other system interference and / or congestion within the system.

[0152] The WTRU may initiate an RRC connection to report a CSLF. The WTRU may detect a CSLF on a SL carrier or resource set. An In-Coverage (IC) WTRU may determine to report a CSLF, for example based on one or more conditions described herein. The WTRU may initiate or resume an RRC connection to report a CSLF. For example, the WTRU may initiate or resume an RRC connection after (e.g., immediately) detecting a CSLF. The WTRU may initiate or resume a connection at a subsequent time. For example, the WTRU may have a pending CSLF report and may initiate or resume a connection in response to one of the following time instances or a combination of more than one of the following time instances: the next time period associated with an allowed transmission for UL transmissions of the WTRU (e.g., via a RACH) has begun; when the WTRU is able to acquire a channel to initiate or resume a connection; a fixed or configurable time period has passed after detecting a CSLF; or a paging initiated by the NW is received.

[0153] Determining, for example, a time instance in response to which the WTRU may initiate / resume a connection (e.g., as described herein) may be based on attributes associated with the CSLF and / or attributes associated with one or more of service, priority, data QoS, SL measurements, or other factors associated with SL data at the WTRU.

[0154] In an example, the WTRU may determine whether to initiate an RRC connection to report a CSLF based on one or more of the following conditions. The WTRU may determine whether to initiate an RRC connection to report a CSLF based on whether a CSLF has been triggered on other resource sets. For example, when the WTRU cannot recover from the situation by changing resource pools, RB sets, resource sets, etc. (e.g., only when the WTRU cannot recover from the situation by changing resource pools, RB sets, resource sets, etc.). As an example, if a CSLF has been triggered on (e.g., all) resource pools, RB sets, SL BWPs, etc. that are available to the WTRU, the WTRU may initiate an RRC connection to report the CSLF.

[0155] The WTRU may determine whether to initiate an RRC connection to report the CSLF based on the SL measurements. For example, the WTRU may perform a measurement of congestion on the resource pool (e.g., CBR or CBR-like measurement) if the CSLF has been triggered. If the CBR is greater than a threshold when the CSLF is triggered, the WTRU (e.g., the WTRU may be a remote WTRU) may initiate an RRC connection to report the CSLF.

[0156] The WTRU may determine whether to initiate an RRC connection to report the CSLF based on the frequency (e.g., how often) the CSLF is triggered on different resource sets. For example, the WTRU may trigger the CSLF and switch to another resource set to continue SL transmission. If the number of such switches occurring within a defined period is greater than a threshold, the WTRU may initiate an RRC connection to report the CSLF.

[0157] The WTRU may determine whether to initiate an RRC connection to report a CSLF based on the type of broadcast and / or unicast connection. For example, when sending a SL transmission to a relay WTRU, the WTRU may initiate an RRC connection to report a CSLF. When sending a SL transmission for unicast or when the WTRU has a unicast link established when a CSLF is triggered, the WTRU may initiate an RRC connection to report a CSLF.

[0158] The WTRU may determine whether to initiate an RRC connection to report a CSLF based on the QoS of the transmissions made by or to the WTRU. For example, the WTRU may be configured with a QoS flow set or a PC5 5G NR standardized QoS identifier (PQI) that may trigger an RRC connection based on a CSLF.

[0159] For example, if the time period expires and the WTRU has not initiated RRC connection / resume, the WTRU may cancel the pending RRC connection / resume. For example, if the CSLF is canceled (e.g., based on the conditions described herein) and the WTRU has not initiated RRC_connection / resume, the WTRU may cancel the pending RRC_connection / resume.

[0160] The WTRU may report CSLF and may remain in RRC_IDLE / RRC_INACTIVE, for example, by using an Inactivity Data Transmission procedure, a RAN-based Notification Area Update (RNAU) procedure, or similar transmissions that do not involve state transitions.

[0161] The WTRU may be configured with different conditions for detecting / reporting CSLF, e.g., depending on whether it is in RRC_CONNECTED or in RRC_IDLE / RRC_INACTIVE. Such conditions may be related to one or more of data priority, data broadcast, LBT failure type, etc. If the WTRU is in RRC_CONNECTED, a first condition (e.g., data priority greater than a first threshold (e.g., threshold1)) may be used to determine whether to report CSLF. If the WTRU is not in RRC_CONNECTED, a second condition (e.g., data priority greater than a second threshold (e.g., threshold2)) may be used to determine whether to report CSLF. A WTRU (e.g., a remote WTRU) may indicate a set of resources that have triggered CSLF (e.g., since the last time the WTRU was in RRC connection) based on initiating an RRC connection.

[0162] The WTRU may report one or more failure events using UL resources. A CSLF may be reported on Uu. A persistent LBT failure may be detected on a SL channel. If a grant is available on a UL channel (e.g., a Uu channel), the WTRU may report the failure (e.g., for each persistent LBT failure detected on the SL channel), for example, by multiplexing an LBT Failure MAC CE on a PUSCH grant. The SL LBT Failure MAC CE may include one or more of the following: an indication of whether a persistent LBT failure was detected on the SL, on the UL (e.g., Uu link), or on both the SL and the UL; the destination ID (e.g., L2 ID) of the WTRU associated with the SL channel; the carrier ID where the persistent LBT failure (e.g., CSLF) was detected; the BWP, resource pool or resource set where the persistent LBT failure was detected, etc.; the type of broadcast associated with the SL used, for example, if (e.g., only if) the receiver is not the destination WTRU; a request to activate a different CG / pool, SL carrier and / or BWP; or the destination ID, priority, minimum communication range, or similar specific attributes of the SL transmission that was attempted and resulted in the LBT failure. In an example, the BWP, resource pool or resource set, etc., in which a persistent LBT failure is detected may be indicated in the form of a BWP ID, a resource pool ID, an LBT bandwidth ID or ID, etc., respectively.

[0163] The WTRU may determine a resource for reporting one or more fault events, for example based on one or more of the following: whether the resource is licensed or unlicensed; whether the resource is a SL resource or a UL resource; whether the resource is associated with one or more fault events; the number of fault events associated with the resource; the cause of one or more fault events; and whether a persistent LBT fault is associated with the resource.

[0164] The WTRU may determine resources based on priority rules. For example, in order to transmit or multiplex a MAC CE indicating a SL LBT failure (e.g., CSLF), the WTRU may use a priority rule or sequence to select a resource (e.g., a resource associated with a carrier and / or link) on which the MAC CE may be transmitted / multiplexed. For example, the WTRU may use the following sequence to select a resource (e.g., a resource that can be used as a data resource) to multiplex the MAC CE. The WTRU may prioritize the selection of licensed resources over unlicensed resources. For example, in the case of PUSCH resources on the UL, the WTRU may prioritize the selection of resources on a licensed UL carrier over resources on an unlicensed UL or SL carrier. If the WTRU is within the coverage of the base station (e.g., the Uu link is available), the WTRU may select resources on a licensed UL carrier before selecting resources on an unlicensed carrier to report the failure event. A grant (e.g., a SL grant or a UL grant) may or may not be available. If a grant is not available, the WTRU may trigger an SR on the PUCCH. In an example, an SR may be transmitted on a PUCCH resource on a licensed carrier or a carrier on which no persistent LBT failure is detected.

[0165] The WTRU may prioritize the selection of resources on a licensed SL carrier over resources on an unlicensed UL or SL carrier. In the case of SL-SCH data resources on the SL (e.g., in a situation where the WTRU is out of coverage of a base station), the WTRU may prioritize the selection of resources on a licensed SL carrier over resources on an unlicensed carrier (e.g., select resources on a licensed SL carrier before selecting resources on an unlicensed carrier).

[0166] The WTRU may determine that unlicensed UL resources have a higher priority than unlicensed SL resources. If no persistent LBT failure is detected on the unlicensed UL resources, the priority rule may indicate that the unlicensed UL resources have a higher priority than the unlicensed SL resources. For example, the priority rule may indicate that unlicensed UL resources where no persistent LBT failure is detected have a higher priority than unlicensed SL resources where no CSLF is detected. For example, in (e.g., only in) a situation where the WTRU does not have an available UL grant for a licensed UL resource or an unlicensed UL resource, the WTRU may multiplex a MAC CE on a SL-SCH resource pool (e.g., a resource pool different from a resource pool where a CSLF is detected) in the LBT bandwidth where no persistent LBT failure is detected. The prioritization rules or sequences may be predefined or indicated in the configuration information (e.g., RRC configuration information).

[0167] Figure 2 is an example of detected CSLF and LBT failures reported on the UL (e.g., Uu link). Figure 2As shown, a tx WTRU within the coverage of a network (e.g., a gNB) may detect one or more LBT failures on a SL (e.g., an unlicensed SL) associated with an rx WTRU that is outside the coverage of the network. As shown in one or more examples herein, for example, based on the number of LBT failures on the SL associated with the rx WTRU, the tx WTRU may determine that a CSLF has occurred on the SL associated with the rx WTRU. In one or more examples herein, the tx WTRU may determine resources on the UL for reporting the CSLF, for example based on priority rules. The tx WTRU may report the CSLF to the network via the UL (e.g., using resources on the UL). The resources on the UL may be licensed or unlicensed. The WTRU may monitor the PDCCH, for example, in response to transmitting an LBT failure MAC CE on the PUSCH within a configured time period. The tx WTRU may monitor the PDCCH, for example, in response to transmitting an LBT failure MAC CE on the PUSCH, for example, based on the examples herein. Figure 2 One or more LBT failures are detected by using one or more fault events caused by the interference shown.

[0168] Figure 3 An example 300 of reporting a CSLF is shown. At 0302, a device (e.g., a WTRU) may perform an LBT procedure associated with a SL bandwidth. At 0304, the device may determine a CSLF associated with the SL bandwidth based on the LBT procedure. At 0306, the device may determine resources for reporting the CSLF. At 0308, the device may indicate a CSLF using the determined resources.

[0169] The WTRU may report one or more failure events using SL resources. A CSLF may be reported on the SL. A persistent LBT failure may be detected on the SL channel. The WTRU may report a failure (e.g., each persistent LBT failure detected on the SL channel) on a SL-SCH resource or a SL control channel, for example, by at least one of: multiplexing an LBT failure MAC CE on a SL-SCH data resource; switching to a different SL BWP, carrier, and / or data resource pool; transmitting SL control information indicating that a SL persistent LBT failure has been detected; or relaying a transport block (TB) of an LBT failure, a SL LBT failure MAC CE, and / or an LBT failure indication SCI to a third WTRU connected to a peer WTRU. The third WTRU may (e.g., in response) relay the TB, MAC CE, and / or failure indication / SCI to a receiving WTRU (e.g., a peer WTRU).

[0170] For example, the WTRU may report a detected CSLF on a SL channel and / or a failed TB on a forwardable SL channel if one or more conditions are met, which may include: the WTRU is outside of network coverage; a persistent LBT failure has been detected on (e.g., all) unlicensed Uu carriers; the WTRU is transmitting in SL scheduling mode 2; or the WTRU has received an indication from a third WTRU (e.g., a relay WTRU) that is connected to the peer WTRU.

[0171] The WTRU may report the CSLF (e.g., via a MAC CE or SCI) to a WTRU (e.g., a third WTRU connected to a peer WTRU). In an example, the third WTRU may report the CSLF to the network (e.g., using a Uu link) (e.g., if it is within coverage) or to a peer WTRU connected to the third WTRU. The third WTRU may indicate the L2 ID of the WTRU that experienced / detected the CSLF and / or the associated SL resources where the CSLF has been detected.

[0172] The WTRU may transmit a CSLF report (e.g., a TB LBT Failure MAC CE or SCI indication) using a different SL carrier, a different resource pool, a different resource set, etc. that is associated with a different LBT bandwidth than the LBT bandwidth where the CSLF was detected. The multiplexed LBT Failure MAC CE may include an indication (e.g., to a peer WTRU) about a carrier to be activated or switched to, for example, for subsequent data or SL data / control resources. The WTRU may transmit the LBT Failure MAC CE on another active SL carrier that is on a data resource or resource pool that is different from the resource pool where the CSLF was detected. The WTRU may monitor (e.g., for a configured period of time) the SL control channel (e.g., for SCI), for example, in response to transmitting the LBT Failure MAC CE on the SL-SCH resources.

[0173] The WTRU may be configured (e.g., by the network or upper layers) with, for example, a dedicated L2 ID for reporting CSLF on SL. For example, the WTRU may transmit the CSLF in a groupcast / broadcast and may transmit the report using a (pre-)configured L2 ID. The WTRU may be configured with a dedicated L2 ID that is specific to one or more of: geographic location (region); type of parameter / LBT and / or COT sharing that caused the failure; type of transmission (e.g., mode 1 or mode 2, periodic or one-time, etc.); carrier or resource set or resource pool that determines the CSLF; SL and / or Uu carrier; or broadcast type of the transmission. For example, the WTRU may determine which (pre-)configured L2 IDs to use for the transmission of the report based on the factors described herein.

[0174] The WTRU may determine the broadcast type and / or intended recipient (e.g., L2 ID) of the persistent LBT fault report. The WTRU may determine the broadcast type and / or intended recipient (e.g., where the intended recipient may be associated with an L2 ID or may be associated with a base station), for example, based on one or a combination of more than one of the following factors.

[0175] The factors may be the type of broadcast at the WTRU when the CSLF was detected and / or the intended recipients of pending transmissions (e.g., any pending transmissions) and / or the PDUs intended for transmission on the SL grant. For example, if a failure occurred while the WTRU was attempting to transmit to a peer WTRU, the WTRU may transmit the CSLF to a unicast peer WTRU. If the WTRU was attempting to transmit to a second broadcast / multicast L2 ID, the WTRU may transmit the report using a first broadcast / multicast L2 ID (e.g., dedicated thereto), which may be different from or the same as the first broadcast / multicast L2 ID.

[0176] The factor may be the SL mode (e.g., Mode 1 or Mode 2). For example, a WTRU operating in Mode 1 may transmit the CSLF to a base station, while a WTRU operating in Mode 2 may transmit the CSLF to one or more peer WTRUs. The factor may be an ongoing service or a service of interest at the WTRU. For example, if the WTRU has an ongoing unicast service (e.g., only unicast service) or the WTRU has a unicast service with data available for transmission, the WTRU may transmit the CSLF to one or more peer WTRUs using unicast. If the WTRU has at least one ongoing multicast / broadcast service (e.g., if the WTRU has data available for transmission), the WTRU may transmit using broadcast.

[0177] The factors may be whether the SL and / or Uu or the carriers on the SL and / or Uu (e.g., any such carriers) are licensed or unlicensed. For example, if at least one of the WTRU's Uu carriers is licensed, the WTRU may transmit a CSLF to the base station. For example, if the WTRU's SL carriers are unlicensed (e.g., none of the WTRU's SL carriers are licensed), the WTRU may transmit a CSLF to the base station. For example, if the WTRU's Uu carriers are unlicensed (e.g., none of the WTRU's Uu carriers are licensed) and at least one of the WTRU's SL carriers is licensed, the WTRU may transmit a CSLF to a peer WTRU.

[0178] The factor may be a coverage scenario (e.g., in coverage (IC) or out of coverage (OOC)). For example, if the WTRU is in coverage, the WTRU may transmit a CSLF to a base station and / or a peer WTRU. For example, if the WTRU is OOC, the WTRU may transmit a CSLF to (e.g., only to) a peer WTRU. The factor may be the RRC state of the WTRU. For example, when the WTRU is in RRC_CONNECTED (e.g., only when the WTRU is in RRC_CONNECTED), the WTRU may transmit a CSLF to a base station. The factor may be whether the WTRU is receiving a CSLF or generating a CSLF. For example, the WTRU may determine the intended recipient of the CSLF from information in the CSLF (e.g., if a CSLF is received). If the WTRU (e.g., itself) generates a CSLF, the WTRU may determine the recipient based on other factors described herein.

[0179] The factor may be the QoS of the pending data / SL service. For example, if the QoS attribute (e.g., priority) associated with the data to be transmitted is above a configured or pre-configured threshold, the WTRU may report the CSLF to the base station and / or peer WTRU. The CSLF may be reported to the network (NW), one or more peer WTRUs, or both based on one or more of the factors.

[0180] A detected CSLF and / or a report of a detected CSLF may be cancelled based on one or more of the following conditions. The WTRU may, for example, cancel a triggered CSLF in response to performing at least one of: multiplexing an LBT failure MAC CE on a PUSCH transmission and / or on a SL data resource (e.g., SL-SCH resource) indicating a detected CSLF; transmitting a TB (e.g., with a successful LBT) that may include an LBT failure MAC CE indicating a detected CSLF; performing a successful LBT on a SL transmission and / or UL transmission on a carrier and / or BWP and / or SL resource set where a persistent LBT failure was detected; or receiving a response, acknowledgment, grant, HARQ feedback, and / or reconfiguration (e.g., from a base station), which may be performed in response to a transmitted TB including an associated LBT failure MAC CE (e.g., associated with an associated HARQ process). The WTRU may, for example, start a CSLF declaration timer in response to detecting a SL LBT failure. The WTRU may, for example, stop the timer in response to cancelling a triggered CSLF. During the duration that the timer is running, the WTRU may keep reporting and / or multiplexing the LBT Failure MAC CE for the declared CSLF. In some examples, the WTRU may multiplex the LBT Failure MAC (e.g., only once) for a persistent failure detected on the SL.

[0181] In response to the CSLF declaration timer expiring, the WTRU may cancel the detected CSLF on, for example, the applicable SL carrier / BWP. In response to the CSLF declaration timer expiring, if the WTRU has not received a response (e.g., data or control) from the base station (e.g., if the WTRU is in coverage), the WTRU may notify or report to the upper layer and / or may declare a radio link failure. In response to the CSLF declaration timer expiring, if the WTRU has not received a response (e.g., data or control) from the WTRU to which the CSLF MAC CE or SCI was transmitted, the WTRU may perform one or more of the following: notify or report to the upper layer; - disconnect the unicast link to the peer WTRU and / or discard the related configuration; or declare a radio link failure.

[0182] Recovery from persistent LBT failures detected on the SL may be implemented. SL resource switching may be implemented. In response to detecting one or more LBT failures (e.g., CSLF), the WTRU may perform at least one of the following recovery actions: switching to a different active SL carrier; switching to a different SL BWP; activating a different SL carrier; switching to a different set of resources (e.g., a different data resource pool or set of RBs) on the same BWP; (re)transmitting data and / or SCI; or transmitting a request to the gNB to activate a different set of SL resources / carriers / or BWPs.

[0183] Figure 4 An example 400 of SL resource switching is shown. At 0402, a device (e.g., a WTRU) may determine a CSLF associated with a first RB set. At 0406, the device may perform an LBT procedure associated with a second RB set. The LBT procedure associated with the second RB set may be performed before determining the CSLF associated with the first RB set or after determining the CSLF associated with the first RB set. At 0408, the device may determine that the second LBT procedure is successful (e.g., based on determining a successful LBT attempt or determining that the number of LBT failures associated with the second RB set is less than a value, e.g., within a certain time). At 0410, the device may transmit a TB using the second RB set.

[0184] The WTRU may select a different SL or UL resource set (e.g., resource pool) that may be associated with a different LBT bandwidth in which no CSLF was detected (e.g., or based on determining that the number of LBT failures associated with a second RB set is less than a value, e.g., for a certain period of time) in one or more of the following: after detecting a CSLF; after LBT fails one or more times (e.g., a configured or predefined number of times, e.g., as indicated by the value of an LBT failure counter associated with the CSLF process); after receiving an SCI from a peer WTRU on a given RB set or resource pool, which SCI may be used by the tx WTRU to retransmit a TB or SCI for which an LBT operation failed; and / or after a timer (e.g., an RB set inactivity timer or an LBT failure timer) expires.

[0185] For example, after detecting a CSLF on a first resource, the WTRU may (e.g., autonomously, e.g., without receiving an indication or request) switch to a second resource. The second resource may include an active set of UL or SL resources. The first resource may include a first RB set. The second resource may include a second RB set. For example, the WTRU may identify a second RB set after detecting a CSLF on a first RB set. The WTRU may perform or may have performed an LBT procedure on the second RB set and / or determine that a CSLF was not detected on the second RB set, for example, by determining that the LBT procedure on the second RB set was successful or that the number of LBT failures on the second RB set was less than a certain value (e.g., reaching a maximum value or threshold for CSLF). The first RB set and the second RB set may belong to the same resource pool or to different resource pools.

[0186] The WTRU may be configured with an association between resource sets, for example, such that after the WTRU detects a failure event (e.g., one or more LBT failures) associated with either of the first resource set and the second resource set, the WTRU may (e.g., may be able to) switch between the first resource set and the second resource set. The WTRU may switch to a second RB set (e.g., a second RB set within the same resource pool as the first RB set from which the WTRU may switch) after detecting one or more LBT failures or CSLF on a resource pool. The WTRU may restart a detection time (e.g., a CSLF detection timer) based on switching to different resources (e.g., a different resource pool). The WTRU may restart a detection time if the WTRU transmits or retransmits data and / or control information that the WTRU was to transmit but could not transmit on the resources where the LBT failed (e.g., conditional on switching to a different RB set that shares the same CSLF process or is maintained by the same CSLF process as the RB set where the CSLF was detected).

[0187] The WTRU may transmit a TB on a resource where no CSLF is detected. If a CSLF has not been detected on a first resource, a TB may have been transmitted on the first resource. As shown in one or more examples herein, the WTRU may switch to a second resource based on determining that a CSLF has been detected on a first resource. The LBT process on the second resource may be successful, or the number of LBT failures on the second resource may be less than a certain value (e.g., a maximum value or threshold of the CSLF is reached). The WTRU may transmit a TB on a second resource to which the WTRU switches from the first resource. In an example, the WTRU may prepare a TB for transmission on one or more resources, for example until an LBT attempt is successful on at least one of these resources. The TB may be or be configured to be transmitted on one or more resource sets on different LBT bandwidths, BWPs, or SL carriers. The LBT process on at least one of the resource sets may be successful. For example, the WTRU may prepare a TB at the MAC layer (MAC) and may provide the TB to the physical layer (PHY) for possible transmission on more than one resource set. A WTRU at the PHY may attempt to transmit a TB on one resource set at a time (e.g., sequentially), for example, until a TB is transmitted on the resource set with a successful LBT operation. LBT operation and LBT attempt may be used interchangeably in one or more examples herein. A resource set (e.g., a set of RBs) may be adjusted to belong to a resource pool (e.g., the same Mode 2 resource pool). A WTRU (e.g., via the PHY) may attempt an LBT operation on more than one RB set (e.g., a set of RBs that are consecutive in the frequency domain) simultaneously or sequentially and / or select an RB set on which to transmit a TB (or SCI), for example, from an RB set on which an LBT operation was successfully performed.

[0188] The WTRU may determine which RB set and / or resource pool to switch to, for example, based on the RB set in which the LBT failure has been detected. The WTRU may change the WTRU's receive resource pool based on switching to a different RB set or resource pool to monitor the exchange of data and / or control information from a peer WTRU. An association (e.g., link) between a tx resource pool and an rx resource pool may be assumed or configured. The WTRU may start a timer (e.g., an RB set inactivity timer) after determining an LBT failure on a given RB set and / or switching to a different RB set. For example, if an LBT attempt has not been successful for data and / or control transmission while the timer is running, the WTRU may switch to a different RB set or resource pool (e.g., for transmission and / or reception) upon expiration of the timer. Upon expiration of the timer, the WTRU may transmit on the selected or reserved resources (e.g., where the timer may be applied as a tx backoff timer). The value of such a timer (e.g., an RB set inactivity timer) may be configured or determined based on one or more of the following: configured by dedicated signaling; determined based on a CBR associated with a selected or reserved resource; determined based on an LBT indication received from the PHY; determined based on a number of LBT failures counted; determined based on the QoS or priority of data associated with the TB to be transmitted or retransmitted; and / or determined according to a value configured for a detection time (e.g., an LBT detection timer for a CSLF process).

[0189] The WTRU may select a different set or subset of mode 2 transmit parameters based on switching to a different RB set and / or resource pool, for example, after detecting an LBT failure or CSLF or after a backoff period applied after detecting an LBT failure. The tx parameters may include at least one of the following: tx periodicity, tx offset, listening window, selection window size, number of resources (e.g., number of reserved resources), and / or resource occupancy window size. The WTRU may be configured with a subset of tx parameters to use, for example, per RB set or resource pool. The WTRU may change one or more of the tx parameters of the present invention after a configured number of LBT failures. For example, the WTRU may determine which parameter set to use based on the number of LBT failures counted (e.g., based on the value of the LBT failure counter).

[0190] After one or more LBT failures, the WTRU may determine whether to trigger resource reselection based on the periodicity of the selected resources (e.g., when the selected resources are periodic). The WTRU may release occupied Mode 2 resources after an LBT failure. After an LBT failure of the transmission of a discovery message, the WTRU may change the tx parameters associated with the transmission or retransmission.

[0191] The WTRU may maintain multiple LBT processes on different resource sets (e.g., maintain multiple CSLF processes simultaneously). When selecting a resource set after a CSLF, the WTRU may select the resource set based on the CSLF status (e.g., the CSLF status on each resource set in the resource set). For example, after a CSLF on a first resource set, the WTRU may select a second resource set. The second resource set may be the resource set for which the performed LBT process results in the least number of LBT failures (e.g., the smallest CSLF counter or a zero value for the CSLF counter) among the resource sets.

[0192] The WTRU may refrain from selecting a resource set (eg, exclude the resource set from selection) for a period of time after declaring a CSLF on the resource set.

[0193] A WTRU (e.g., a peer WTRU) may blindly decode data and / or SCI resources associated with a subset of a set of RBs (or a resource pool) in an active BWP. The peer WTRU may provide an indication (e.g., a channel sense indication) to the tx WTRU (e.g., in a PSFCH, SCI, or MAC CE) indicating which of the monitored RB sets are sensed as idle or occupied (e.g., if the current set of RBs for which the SCI or PSFCH is exchanged is idle). For example, the peer WTRU may provide channel sense results for a configured subset of a set of RBs in a resource pool or a set of RBs in a BWP (e.g., an active BWP). The peer WTRU may provide the channel sense indication to the tx WTRU periodically or aperiodically (e.g., periodically or otherwise configurable by RRC signaling). In an example, a peer WTRU may provide a channel sense indication to a txWTRU prior to or concurrently with an expected periodic data transfer between WTRUs (e.g., here, a peer WTRU and a tx WTRU) and / or in conjunction with channel measurements and / or SSB transmissions. The SCI from the peer WTRU may include a channel sense status and / or may be sent based on one or more of the following: under some conditions (e.g., in the case where expected traffic is not received); when the peer WTRU has one or more of data, control information, SSB / RS, or measurements to send together; and / or when the peer WTRU is configured to send (e.g., periodically) clear to send (CTS) notifications.

[0194] In one example, the rx WTRU may sense multiple idle RB sets and send them (e.g., indications of the RB sets sensed as idle), for example, as part of the SCI, MAC CE, or PSFCH. The RX WTRU may then blindly decode those RB sets for SL data reception. For example, when the RX WTRU senses at least the RB sets indicated in the SCI as idle, the tx WTRU may select an RB set to switch to from those RB sets (e.g., after an LBT failure). The tx WTRU may perform an LBT operation on all or a subset of the indicated RB sets and transmit TBs on the RB sets (e.g., a single RB set) on which the LBT operation was successfully performed. For example, the tx WTRU may transmit if (e.g., only if) the LBT operation is successful in the LBT bandwidth (e.g., in the RB set) on which the LBT operation is performed.

[0195] The WTRU may switch the monitored resource pool (e.g., in Mode 2) and / or the monitored RB set for receiving data and / or control information from a peer WTRU after detecting one or more LBT failures (e.g., depending on the value of the LBT counter) and / or after detecting a CSLF. The WTRU may determine which Rx RB set and / or which Rx resource pool to monitor / switch to based on an LBT failure determined at the WTRU by the PHY (e.g., based on one or more of the LBT type, LBT configuration, and / or the RB set where the LBT attempt failed) and / or based on the value of a CSLF process parameter (e.g., an LBT counter or timer). The WTRU may switch the monitored resource pool (e.g., in Mode 2) and / or the monitored RB set based on the measured RSSI or channel occupancy (e.g., if the measurement is greater than a configured threshold).

[0196] Similar to Tx RB set switching, the WTRU may be configured with a mode or configuration to determine which Rx RB set to switch to. The TX and RX RB sets may be linked. The WTRU may, for example, use a sequence number to switch to the Rx resource pool (e.g., if LBT fails on RB set index y, the WTRU will switch to the RB set with index y+1). The WTRU may couple the Tx and Rx resource switching times so that both the Tx pool and the Rx pool are switched together at the same time. For example, the WTRU may switch the Rx RB set it monitors after the RB set inactivity timer expires.

[0197] The WTRU may be configured with a switching mode (e.g., an RB set switching mode) whereby the WTRU (e.g., a tx WTRU) may switch to another RB set after one or more LBT failures, and the RB set to which the WTRU switches may be based on the configured switching mode. The switching mode may be selected by the WTRU or may include some or all RB sets in a BWP (e.g., an active BWP).

[0198] In one example, the WTRU may determine which RB set and / or resource pool to switch to based on the RB set in which an LBT failure has been detected (e.g., a persistent LBT failure has been detected) and / or based on an LBT failure indication determined by the WTRU's PHY.

[0199] In an example, after one or more LBT failures in transmitting a discovery message or signal on a dedicated discovery pool, the WTRU may switch to a different resource pool or set of RBs (e.g., a shared resource pool) for transmission or retransmission of discovery messages. This may be conditioned on the number of LBT failures (e.g., the value of an LBT counter). Upon determining that a channel is occupied on a dedicated discovery pool (e.g., based on an LBT failure indication received for the dedicated resource pool and based on channel sensing that an unlicensed channel on the applicable RB set is occupied and / or based on a measured RSSI value or channel occupancy (e.g., where the measurement is above a configured threshold), the WTRU may begin monitoring the shared resource pool for receiving discovery messages from other WTRUs.

[0200] A peer WTRU may access a channel to transmit HARQ feedback or SCI (e.g., despite or during an LBT failure). The WTRU may include one or more of SCI, HARQ feedback (e.g., PSFCH), or MAC CE and SL data transmission indicating which RB sets are sensed as idle (e.g., RB sets within a resource pool). A peer WTRU may fail in an LBT operation when attempting to transmit HARQ feedback and / or other SCI (e.g., due to a hidden node affecting only the rx WTRU). The peer WTRU may switch from the monitored RB set to another RB set to transmit one or more of HARQ feedback, PSFCH, or SCI in response to the received SL data. The monitored RB set may be configured or predetermined, for example, to be a RB set within a selected resource pool.

[0201] The peer WTRU may transmit HARQ feedback (e.g., at the PSFCH) in response to received SL data, transmit an acknowledgement, or transmit an SCI after receiving a MAC CE or SCI transmitted by the tx WTRU (e.g., successful reception). The peer WTRU may transmit one or more of HARQ feedback, acknowledgement, or SCI on the RB set indicated as idle by the tx WTRU. After receiving feedback, acknowledgement, or SCI from the peer WTRU, in response to RB set switching, the tx WTRU may retransmit unacknowledged TBs (or TBs for which LBT operation failed) or transmit TBs (e.g., new TBs) on a different / indicated RB set or resource pool. The tx WTRU may transmit an RB set switching MAC CE or SCI, for example, based on one or more of the following: after a timer (e.g., a HARQ retransmission timer) expires; after multiple retransmissions; after multiple NACKs; and / or after multiple LBT failures (e.g., based on a CSLF counter). The tx WTRU may retransmit the TB after the retransmission timer expires (e.g., only after the retransmission timer expires) and / or after receiving an SCI from the rx WTRU indicating one or more of the selected RB set being occupied, an alternative idle RB set, a NACK, and / or an RB set switch (e.g., only after receiving an SCI from the rx WTRU indicating one or more of the selected RB set being occupied, an alternative idle RB set, a NACK, and / or an RB set switch).

[0202] The WTRU may exclude resources associated with a triggered CSLF. For example, the WTRU may exclude resource sets (e.g., carriers, BWPs, periodic resource reservations, resource pools, subsets of resources associated with LBT, etc.) for selection and / or transmission after a CSLF, an LBT failure, or multiple LBT failures that may have occurred on the resource set. The WTRU may (e.g., in response) exclude such resource sets, for example, for a period of time. Such time periods may be configurable or preconfigured. The WTRU may be configured or preconfigured with different time periods associated with one or more of the following: the type of LBT performed that caused the CSLF; multiple (e.g., currently available) resource sets (e.g., multiple carriers); SL ​​measurements associated with the resource sets, which may be performed when the CSLF is triggered; CBR values ​​on the resource sets; or priorities for data transmitted at the WTRU. The WTRU may exclude a resource set by performing one of the following actions or a combination of more than one of the following actions: excluding resources as possible available resources in resource selection; excluding resources from the set of available resources determined by listening; stopping listening on the resources; excluding carriers from carriers that can be used for carrier (re)selection and / or for performing (re)selection of resources reserved for future transmissions (or selected carriers) and / or resources reserved / selected prior to the CSLF; or clearing the SL HARQ buffer, which may be associated with the SL process for the affected SL resources.

[0203] In response to one or more of the actions to exclude resource sets described herein, the WTRU may exclude these resources from use in future resource selection decisions, wherein such exclusion may be performed for a period of time after the CSLF. For example, in response to detecting a CSLF on a given SL resource set, the WTRU may start an inhibit timer (e.g., a CSLF declaration timer or an RB set inactivity timer). The WTRU may maintain such a timer per LBT bandwidth, BWP, SL carrier, and / or resource set. The WTRU may maintain such a timer per transmission type (e.g., broadcast type, transmission to a specific L2 ID, QoS / priority, SL PHY channel, etc.). During the duration that the timer is running, if a CSLF is detected on the associated LBT bandwidth, BWP, and / or carrier, the WTRU may not select data and / or control resources. In response to the expiration of the inhibit timer, the WTRU may consider SL data and / or control resources on the associated LBT bandwidth, BWP, and / or carrier, for example, for retransmitting data or control information that failed LBT.

[0204] The WTRU may, for example, reconsider (e.g., prematurely, which may be before the duration of the timer is completed) a resource that was excluded based on the occurrence of a particular event. For example, the WTRU may cancel or stop the inhibit timer described herein in response to the occurrence of an event. Such an event may be associated with receiving a SL control and / or data transmission (e.g., from another WTRU), which may be associated with the resource. Such an event may include receiving an indication (e.g., an explicit or implicit indication, such as scheduling a SL transmission of an SCI from another WTRU or receiving a scheduled DCI). Such an event may include the WTRU determining that a measurement associated with the affected resource (e.g., CBR, RSSI, etc.) satisfies a particular condition (e.g., the RSSI is, for example, below a threshold for a period of time).

[0205] Data and control forwarding may be implemented. In response to detecting a CSLF, the WTRU may forward a TB and / or SCI for a failed LBT process to a base station or a third WTRU connected to a peer WTRU. The WTRU may perform such forwarding if (for example, only) the TB and / or SCI was not previously transmitted to the destination WTRU. The WTRU may include a destination broadcast ID and the forwarded data and / or SCI. In the case of data forwarded to a base station, the WTRU may transmit the data on a PUSCH grant. In the case of a forwarded SCI, the WTRU may transmit the forwarded SCI on a PUCCH transmission, or as UCI on a PUSCH transmission, and / or may include a destination peer ID. In the case of data or control forwarded to a third WTRU, the WTRU may forward the data or SCI to the third WTRU on SL-SCH resources and / or SL control resources. The forwarded SCI may include a notification of CSLF detection and a broadcast ID, for example, which may be in addition to the SCI for a failed LBT process.

[0206] A third WTRU (e.g., a relay WTRU) may provide feedback to the transmitting WTRU that the destination WTRU is reachable (e.g., the LBT procedure is successful for the destination WTRU) and / or confirmation of the forwarded data. In response to forwarding data and / or control information to the base station, the WTRU may monitor PDCCH transmissions for confirmation that the data and / or control has been forwarded (e.g., successfully) to the WTRU. The confirmation may be in the form of HARQ-ACK signaling.

[0207] Reporting to upper layers may be implemented. The WTRU may release the unicast link, for example, in response to detecting a UL LBT failure on active (e.g., all active) SL carriers, active (e.g., all active) SL resource sets, and / or active (e.g., all active) BWPs. The WTRU may notify or report (e.g., declare RLF) to upper layers in response to one or more of the following: the number of consecutive detected CSLFs, the number of consecutive carrier or resource switches performed after the detection of a CSLF, or the detection of a CSLF on SL resources (e.g., all SL resources) used by a MAC entity (e.g., all SL carriers, SL resources on all LBT bandwidths, and / or all SLBWPs).

[0208] Uu and SL may be implemented on the same unlicensed carrier. If the same unlicensed carrier is configured or used by Uu link and SL operations for the same WTRU, the WTRU may, for example, perform recovery actions described herein for both the Uu and SL MAC entities in response to detecting a CSLF on Uu, SL, or both Uu and SL. For example, in response to detecting a CSLF on the SL MAC entity, the WTRU may switch to a different BWP on the Uu link associated with the same carrier and / or BWP and / or may initiate a random access procedure (e.g., a new random access procedure) on Uu for recovery.

[0209] If the same unlicensed carrier is configured or used by Uu link and SL operation for the same WTRU, the WTRU may use (e.g., instead of) the timeslots configured for SL operation of Uu, for example, in response to the number of configured or predefined LBT failures on SL. The WTRU may report failures on the Uu-UL timeslots and / or may forward data or SCI that the LBT procedure failed.

[0210] Disclosed herein are systems, methods, and tools for handling a persistent sidelink (SL) listen-before-talk (LBT) failure (CSLF). A wireless transmit / receive unit (WTRU) may perform a listen-before-talk (LBT) procedure associated with a sidelink (SL) bandwidth. The SL bandwidth may include a set of resource blocks (RBs). The WTRU may determine a CSLF associated with the set of RBs of the SL bandwidth based on the LBT procedure. The WTRU may determine resources for reporting the CSLF, for example, based on a priority rule. The priority rule may indicate that a licensed resource has a higher priority than an unlicensed resource. The priority rule may indicate that if a persistent LBT failure is not detected on an unlicensed uplink (UL) resource, the unlicensed UL resource has a higher priority than the unlicensed SL resource. The WTRU may send a medium access control (MAC) control element (CE) using the determined resources. In an example, the MAC CE may indicate an identification of the RB set and / or the WTRU associated with the SL bandwidth.

[0211] The priority rule may indicate that if no CSLF is detected on a first unlicensed SL resource and a CSLF is detected on a second unlicensed SL resource, the first unlicensed SL resource has a higher priority than the second unlicensed SL resource. The priority rule may indicate that if a persistent LBT failure is detected on an unlicensed UL resource and no CSLF is detected on the unlicensed SL resource, the unlicensed UL resource has a lower priority for CSLF reporting than the unlicensed SL resource.

[0212] The WTRU may switch from a first RB set to a second RB set based on determining one or more LBT failures on the first RB set. The WTRU may detect a CSLF on the first RB set, for example, by performing a first LBT process including at least one LBT attempt for TB transmission. The WTRU may determine the second RB set based on the detection of the CSLF associated with the first RB set. In an example, the WTRU may perform a second LBT process associated with the second RB set. The WTRU may determine that the second LBT process is successful or that the number of LBT failures associated with the second RB set is less than a value. The WTRU may determine the TB associated with the first RB set and transmit the TB using the second RB set. In some examples, the WTRU may transmit the TB associated with the first RB using the second RB set based on receiving SL control information (SCI) associated with the second RB set from another WTRU associated with the second RB set. The first RB set and the second RB set may be associated with the same data resource pool or with different data resource pools.

[0213] For example, when the number of SL LBT failures associated with an RB set (e.g., the first RB set) is equal to or greater than a value, the WTRU may determine the CSLF associated with the RB set based on the number of SL LBT failures associated with the RB set. For example, if the WTRU determines that an SCI has not been received from another WTRU associated with the RB set within a certain period of time, the WTRU may increment the number of SL LBT failures associated with the RB set. If the WTRU determines that a channel busy rate (CBR) associated with the RB set is equal to or greater than a value, the WTRU may increment the number of SL LBT failures associated with the RB set. In an example, the LBT process may include determining whether the SCI is received from another WTRU associated with the RB set or determining the CBR associated with the RB set. The WTRU may increment the number of SL LBT failures associated with the RB set based on the LBT process.

[0214] The WTRU may indicate a SL LBT failure to a base station. The WTRU may perform an LBT procedure including one or more LBT attempts. The WTRU may determine that an LBT attempt for a set of RBs was unsuccessful. The WTRU may determine a SL LBT failure associated with the set of RBs based on the unsuccessful LBT attempt for the set of RBs. The WTRU may send an indication of the SL LBT failure to the base station, for example using a MAC CE or using a negative acknowledgement of a physical uplink control channel (PUCCH) transmission from the base station.

[0215] The WTRU may perform multiple LBT attempts on corresponding RB sets in the configured RB sets. The WTRU may receive configuration information indicating multiple RB sets. The WTRU may perform corresponding LBT attempts on the RB sets in the configured RB sets. The WTRU may determine that the LBT attempt on the RB set in the configured RB set is successful. The WTRU may transmit a TB using the RB set associated with the successful LBT attempt.

[0216] Although the above features and elements are described in particular combinations, each feature or element may be used alone without the other features and elements of the preferred embodiments, or in various combinations with or without the other features and elements.

[0217] Although the specific implementation described herein may consider 3GPP specific protocols, it should be understood that the specific implementation described herein is not limited to this scenario and is applicable to other wireless systems. For example, although the solution described herein considers LTE, LTE-A, New Radio (NR) or 5G specific protocols, it should be understood that the solution described herein is not limited to this scenario and is also applicable to other wireless systems. For example, although the system has been described with reference to 3GPP, 5G and / or NR network layers, the envisioned implementation extends to specific implementations beyond the use of specific network layer technologies. Similarly, potential implementations extend to all types of service layer architectures, systems and implementations. The techniques described herein can be applied independently and / or used in combination with other resource configuration techniques.

[0218] The processes described herein may be implemented in a computer program, software, and / or firmware incorporated in a computer-readable medium for execution by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted via a wired or wireless connection) and / or 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, but not limited to, built-in hard disks and removable disks), magneto-optical media, and / or optical media (such as compact disks (CD)-ROM disks and / or digital versatile disks (DVDs)). A processor associated with the software may be used to implement a radio frequency transceiver for a WTRU, a terminal, a base station, an RNC, and / or any host computer.

[0219] It should be understood that the entity that performs the processes described herein can be a logical entity that can be implemented in the form of software (e.g., computer executable instructions) that is stored in the memory of a mobile device, network node, or computer system and executed on its processor. That is, these processes can be implemented in the form of software (e.g., computer executable instructions) stored in the memory of a mobile device and / or a network node (such as a node or a computer system) that, when executed by the processor of the node, performs the processes in question. It should also be understood that any of the transmission and reception processes shown in the figure can be performed by the communication circuit of the node under the control of the processor of the node and the computer executable instructions (e.g., software) executed by it.

[0220] The various techniques described herein can be implemented in combination with hardware or software, or in a combination of the two where appropriate. Therefore, the specific implementation and device of the subject matter described herein or some aspects or parts thereof may take the form of program code (e.g., instructions), which is embodied in a tangible medium, which includes any other machine-readable storage medium, wherein when the program code is loaded into a machine (such as a computer) and executed by the machine, the machine becomes a device for practicing the subject matter described herein. In the case where the program code is stored on a medium, it is possible that the program code under consideration is stored on one or more media that jointly perform the action under consideration, that is, the one or more media together contain the code for performing the action, but in the case where there is more than one single medium, it is not required that any particular part of the code be stored on any particular medium. In the case of program code execution on a programmable device, the computing device generally includes a processor, a storage medium (including volatile and non-volatile memory and / or storage elements) readable by the processor, at least one input device, and at least one output device. One or more programs may implement or utilize the process described in conjunction with the subject matter described herein, for example, by using an API, a reusable control, etc. Such programs are preferably implemented in a high-level procedural or object-oriented programming language to communicate with a computer system. However, if desired, the one or more programs may be implemented in assembly or machine language. In any case, the language may be a compiled or interpreted language and combined with a hardware implementation.

[0221] Although the exemplary embodiments may involve utilizing aspects of the subject matter described herein in the context of one or more stand-alone computing systems, the subject matter described herein is not so limited, but may be implemented in conjunction with any computing environment, such as a network or distributed computing environment. Further, aspects of the subject matter described herein may be implemented in or across multiple processing chips or devices, and storage may similarly be affected across multiple devices. Such devices may include personal computers, network servers, handheld devices, supercomputers, or computers integrated into other systems, such as automobiles and airplanes.

[0222] In describing the preferred embodiments of the subject matter of the present disclosure as shown in the accompanying drawings, specific terminology is employed for the sake of clarity. However, the claimed subject matter is not intended to be limited to the specific terminology so selected, and it is to be understood that each specific element includes all technical equivalents that operate in a similar manner to achieve a similar purpose.

Claims

1. A wireless transmit / receive unit (WTRU), comprising: A processor, the processor being configured to: receiving configuration information indicating a continuous sidelink listen-before-talk failure (CSLF) parameter; determining a CSLF associated with a resource set of a resource pool, wherein the determination of the CSLF is based on a number of listen-before-talk (LBT) failures associated with the resource set of the resource pool; determining that the CSLF associated with the resource set has not been cancelled; and Based on determining that the CSLF associated with the resource set is not cancelled, selecting resources from the resource pool for side link (SL) transmission that do not include the resource set associated with the CSLF.

2. The WTRU of claim 1 , wherein: The CSLF parameters include a time period associated with the CSLF, and the processor is further configured to: Based on the determination of the CSLF, starting the time period at a first time; and At a second time associated with expiration of the time period, the CSLF associated with the set of resources is cancelled.

3. The WTRU of claim 2, wherein: The resource is selected at the first time or after the first time and before the second time.

4. The WTRU of claim 2, wherein: The start of the time period indicates the start of the CSLF reporting and recovery procedures configured for the WTRU.

5. The WTRU of claim 1 , wherein: The processor is also configured to: generating a SL LBT fault medium access control (MAC) control element (CE); and Send the SL LBT failure MAC CE.

6. The WTRU of claim 5, wherein: The SL LBT failure MAC CE indicates the CSLF associated with the resource set, and wherein the processor is further configured to: receiving an uplink (UL) grant; and The SL LBT Failure MAC CE is sent according to the UL grant.

7. The WTRU of claim 1 , wherein: The processor is also configured to: determining a bandwidth part (BWP) for transmission of the SL, wherein the BWP comprises the resource pool from which the resources for transmission are selected; and The SL transmission is sent via the BWP.

8. The WTRU of claim 1 , wherein: The CSLF parameters include a maximum counter value, and the determination of the CSLF is based on a number of the LBT failures associated with the resource set reaching the maximum counter value.

9. The WTRU of claim 8, wherein: The processor is also configured to: Determining that an LBT failure occurs on the resource set; Incrementing the counter value of the resource set by 1; determining that the number of LBT faults is equal to the maximum counter value; as well as A medium access control (MAC) control element (CE) is sent indicating a SL LBT failure of the CSLF associated with the resource set.

10. The WTRU of claim 1 wherein: The resource set includes a resource block (RB) set.

11. A method performed by a wireless transmit / receive unit (WTRU), comprising: receiving configuration information indicating a continuous sidelink listen-before-talk failure (CSLF) parameter; determining a CSLF associated with a resource set of a resource pool, wherein the determination of the CSLF is based on a number of listen-before-talk (LBT) failures associated with the resource set of the resource pool; determining that the CSLF associated with the resource set has not been cancelled; and Based on determining that the CSLF associated with the resource set is not cancelled, selecting resources from the resource pool for side link (SL) transmission that do not include the resource set associated with the CSLF.

12. The method according to claim 11, wherein: The CSLF parameters include a time period associated with the CSLF, and the method further includes: Based on the determination of the CSLF, starting the time period at a first time; and At a second time associated with expiration of the time period, the CSLF associated with the set of resources is cancelled.

13. The method according to claim 12, wherein: The resource is selected at the first time or after the first time and before the second time.

14. The method according to claim 12, wherein: The start of the time period indicates the start of the CSLF reporting and recovery procedures configured for the WTRU.

15. The method according to claim 11, further comprising: generating a SL LBT fault medium access control (MAC) control element (CE); and Send the SL LBT failure MAC CE.

16. The method according to claim 15, wherein: The SL LBT failure MAC CE indicates the CSLF associated with the resource set, and wherein the method further comprises: receiving an uplink (UL) grant; and The SL LBT Failure MAC CE is sent according to the UL grant.

17. The method according to claim 11, further comprising: determining a bandwidth part (BWP) for said SL transmission, wherein, said BWP comprising said resource pool from which said resources are selected for transmission; and The SL transmission is sent via the BWP.

18. The method according to claim 11, wherein: The CSLF parameters include a maximum counter value, and the determination of the CSLF is based on a number of the LBT failures associated with the resource set reaching the maximum counter value.

19. The method according to claim 18, further comprising: Determining that an LBT failure occurs on the resource set; Incrementing the counter value of the resource set by 1; determining that the number of LBT faults is equal to the maximum counter value; and A medium access control (MAC) control element (CE) is sent indicating a SL LBT failure of the CSLF associated with the resource set.

20. The method according to claim 11, wherein: The resource set includes a resource block (RB) set.

Images