SL RLF in multicarrier with licensed and unlicensed

Abstract

A sidechain (SL) wireless transmit and receive unit (WTRU) may be configured to: establish a unicast link with a peer WTRU that allows the use of a plurality of SL carriers; and transmitting data to the peer WTRU on at least a first SL carrier. The WTRU determines a carrier-specific SL Radio Link Failure (RLF) of the first SL carrier based on the detected number of Continuous Hybrid Automatic Repeat Request (HARQ) Discontinuous Transmission (DTX) exceeding a threshold HARQ DTX count, and performs an SL carrier reselection process to select a second SL carrier, excluding the SL carrier determined in the case of the carrier-specific SL RLF. The WTRU transmits an indication of a carrier specific RLF of the first SL carrier to the peer WTRU on one of the plurality of SL carriers in the absence of the carrier specific SL RLF. And if no available SL carrier is left, the WTRU releases the unicast link with the peer WTRU. Additional embodiments are disclosed.

Description

[0001] Cross-references in related applications This application claims the benefit of U.S. Provisional Application No. 63 / 531,227, filed August 7, 2023, the contents of which are incorporated herein by reference. Background Technology

[0002] Multicarrier operation has been specified for New Radio (NR) sidechains (SL) in 3GPP Release 18. Multicarrier operation is expected to use Long Term Evolution (LTE) as a baseline, while potentially taking into account some differences to account for unicast transmissions in NR. Additionally, unlicensed operation for SL has been specified, and there is no expectation that these two features will interact. Specifically, multicarrier operation is considered for licensed carriers in the case of Rel18 user equipment (UE). Furthermore, unlicensed operation is considered only for a single carrier. However, it is expected that future releases will require support for UEs operating on a combination of licensed and unlicensed carriers.

[0003] Several specific areas are being considered for sidechain (SL) communication to operate licensed and unlicensed carriers in a multi-carrier manner, including carrier selection, discontinuous reception (DRX), and hybrid automatic repeat request (HARQ) radio link failure (RLF). When a mixture of licensed and unlicensed carriers exists, priority-based and channel busy ratio (CBR) carrier selection may be unsuitable. Specifically, licensed and unlicensed carriers cannot be considered equivalent from the perspectives of resource utilization, QoS maintenance, and access. Currently, DRX for SL is designed only for a single carrier. For uplink and downlink (i.e., Uu interface), multi-carrier DRX exists based on DRX groups. However, defining DRX groups in the context of licensed / unlicensed multi-carrier in SL has the following limitations: the receiving (RX) UE will need to monitor all carriers configured for transmissions made by the transmitting (TX) UE, which may be undesirable from a power consumption perspective, especially if some of these carriers are in unlicensed bands. RLF determination based on hybrid automatic repeat request (HARQ) is also designed only for a single carrier. In SL multicarrier, the determination of whether there is a problem with the carrier license for the entire SL RLF may vary due to the carrier itself and / or potentially due to whether they are licensed or unlicensed.

[0004] In LTE / NR, carrier selection for licensed carriers treats all carriers equally and considers only the CBR (Carrier Selection Ratio). However, unlicensed carriers are clearly unsuitable for certain types of traffic, and a carrier selection scheme based solely on CBR may result in the selection of a set of carriers that may not meet QoS requirements.

[0005] In SL, especially in unicast, unlicensed carriers may only be used for certain traffic types or situations (e.g., large volumes of traffic without strict timing requirements). Configuring DRX groups using traditional DRX group mechanisms and having the RX UE monitor SL for all carriers would be power inefficient.

[0006] Traditional SL RLF is designed for a single carrier. One problem with HARQ-based counting in unlicensed systems is that there is no way to determine whether HARQ DTX at the RX UE is due to a decoding failure or an LBT failure.

[0007] Traditional SL RLFs based on HARQ feedback are designed for single carriers only. For multi-carrier applications, SL RLFs can be per-carrier and / or per-link, and this can depend on the correlation between carriers. Solutions are needed for multi-carrier sidechains using licensed and / or unlicensed carriers. Summary of the Invention

[0008] According to certain aspects of this disclosure, one or more of the above problems can be solved by a UE, which is interchangeably referred to herein as a Radio Transmitter Receiver Unit (WTRU), which selects at least one unlicensed carrier for multicarrier transmission based on the QoS of the data and / or the amount of data available and / or the CBR on the licensed carrier.

[0009] In one example, the SL TX WTRU may be configured with one or more thresholds, such as priority bit rate, buffer state threshold, CBR threshold, etc., for determining whether transmission on an unlicensed carrier for an SL radio bearer (SLRB) is permitted. For each destination L2 ID configured for transmissions on both licensed and unlicensed carriers, a method may include: (i) establishing one or more SL radio bearers for transmissions to the L2 ID based on an established QoS flow; (ii) determining whether to select at least one unlicensed carrier based on one or more configured parameters of the SL radio bearers and / or the buffer state associated with the one or more SL radio bearers and / or the maximum CBR on any of the selected licensed carriers for unlicensed operation; (iii) selecting multiple licensed carriers and multiple unlicensed carriers for the destination; and (iv) transmitting data for the L2 destination ID on each of the selected carriers.

[0010] In some aspects, determining whether to select at least one unlicensed carrier based on one or more configured parameters of the SL radio bearer and / or the buffer state associated with the one or more SL radio bearers and / or the maximum CBR on any of the selected licensed carriers may include: for example, whether the SL radio bearer (SLRB) is configured with a priority bit rate greater than a threshold, whether the buffer state associated with the one or more SLRBs is greater than the threshold during a configured time period, and / or whether the minimum CBR of any selected licensed carrier is greater than the CBR threshold.

[0011] According to another approach, the WTRU performs an initial transmission to the first carrier (anchor carrier) and only performs subsequent transmissions to other carriers after a positive response to the first transmission.

[0012] In one example, the SL TX WTRU establishes a unicast link with its peer WTRU and configures multiple carriers to be used for communication with the RX WTRU. The SL TX WTRU can select the licensed carrier with the lowest CBR as the anchor carrier and send an indication of the anchor carrier (e.g., in PC5-RRC) to the RX WTRU. The TX WTRU selects the SL Discontinuous Receive (DRX) configuration (e.g., DRX period, on duration, inactivity time, etc.) and sends the DRX configuration to the RX WTRU.

[0013] In one example, upon arrival of data transmitted to the RX WTRU, and if the inactivity timer at the RX WTRU is not running, the TX WTRU performs a first data transmission to the RX WTRU on the anchor carrier during the RX WTRU's active period. As part of the transmission, the TX WTRU includes (e.g., in the sidechain control information (SCI)) an indication of one or more carriers expected to be used during that active period. Upon receiving a HARQ ACK from the first transmission, the TX WTRU initiates a subsequent transmission on the carrier indicated in the first transmission and resets the inactivity timer after transmissions on both anchor and non-anchor carriers.

[0014] In another example, when data for a transmission to the RX WTRU arrives, and if an inactive timer at the RX WTRU is running, the TX WTRU performs data transmission on all carriers indicated by the last carrier transmission instruction on the anchor carrier.

[0015] According to a further aspect of this disclosure, the WTRU can jointly select initial and backup resources on unlicensed and licensed carriers, respectively, when performing some transmissions for a certain QoS.

[0016] In one example, the SL TX WTRU is configured with multiple carriers on both licensed and unlicensed carriers, and one or more bearers for the transmission to the destination, which are configured to allow or disallow backup resource selection. When data arrives for a bear that allows backup resource selection, the TX WTRU can perform a joint resource selection (reselection) process on both licensed and unlicensed carriers.

[0017] In one example, the joint resource selection (reselection) process includes selecting a first available resource on an unlicensed carrier at time t1 and a second available resource on a licensed carrier at a later time t2, where t1 and t2 are within the resource selection window. The TX WTRU performs a listen-before-talk (LBT) for transmissions on the first resource. If the LBT fails, the TX WTRU transmits data on the second resource; otherwise, it transmits data on the first resource.

[0018] According to an additional aspect of this disclosure, a method is disclosed in which the WTRU resets the carrier-specific SL-RLFHARQ DRX counter when it receives a message (e.g., a reset MAC CE) from the RX WTRU.

[0019] In one example, the SL TX WTRU establishes a unicast link with its peer WTRU (i.e., the RX WTRU) and selects multiple licensed and / or unlicensed carriers for communication. The TX WTRU performs an independent (i.e., per-carrier separate) count of Hybrid Automatic Repeat Request (HARQ) Discontinuous Transmissions (DTX) on each carrier (licensed and unlicensed). The TX WTRU receives a message (e.g., a MACCE) from the RX WTRU on licensed carriers, indicating one or more unlicensed carriers. The TX WTRU modifies the consecutive count of HARQ DTX on the indicated carrier(s). For example, the TX WTRU resets the consecutive count of HARQ DTX or subtracts a value from the current consecutive HARQ DTX count (e.g., indicated in the MAC CE). If the number of consecutive HARQ DTX on a carrier reaches a threshold, the WTRU can indicate a carrier-specific SL radio link failure (RLF) to the network for that carrier.

[0020] According to a further aspect of this disclosure, the WTRU can trigger a sidechain (SL) radio link failure (RLF), release a unicast multicarrier link, and notify the network and / or the RX WTRU when resource selection cannot find at least one licensed / unlicensed carrier that meets the channel busy ratio (CBR) threshold or when there is no carrier-specific RLF (e.g., within a given time period).

[0021] In one example, the SL TX WTRU is configured with a first CBR threshold for licensed carriers and a second CBR threshold for unlicensed carriers. The TX WTRU is also configured with a time period for avoiding carrier selection after a carrier-specific SL RLF. The SL TX WTRU establishes a unicast link with its peer / RX WTRU and selects multiple licensed / unlicensed carriers for communication. In one solution, when a carrier-specific SL RLF occurs on a single carrier, carrier selection (reselection) is triggered, and the TXWTRU selects multiple carriers in the licensed band with a CBR lower than the first threshold and multiple carriers in the unlicensed band with a CBR lower than the second threshold, wherein the time period between the triggering of carrier selection (reselection) and the last carrier-specific SL RLF for the unicast link exceeds a (pre)configured time period threshold.

[0022] In another solution, when the number of consecutive DTX counts for a first carrier exceeds a threshold DTX count, a carrier-specific RLF can be determined for the first SL carrier among multiple SL carriers used in unicast SL carrier aggregation with the TX WTRU. The TX WTRU performs a carrier reselection process to determine a second carrier from these multiple carriers, excluding carriers previously determined to have a carrier-specific RLF. The TX WTRU can provide an indication of the SL RLF for the first carrier and / or the selected second SL carrier.

[0023] According to some aspects, when the TX WTRU is unable to select at least one carrier supported by the RX WTRU and / or not determined under carrier-specific RLF conditions, the TX WTRU triggers an SL RLF, the unicast link with the RX WTRU is released, and the TX WTRU notifies the network. Otherwise, the TX WTRU selects multiple carriers and continues unicast link operation using the selected carriers. Additional embodiments are disclosed. Attached Figure Description

[0024] A more detailed understanding can be obtained from the following description, given as an example in conjunction with the accompanying drawings, wherein similar reference numerals in the figures indicate similar elements, and wherein: Figure 1A This is a system diagram illustrating an example communication system in which one or more of the disclosed embodiments may be implemented; Figure 1B The illustration shows a device that can be used according to one embodiment. Figure 1A The diagram shows a system diagram of an example wireless transmit / receive unit (WTRU) used in a communication system. Figure 1C The illustration shows a device that can be used according to one embodiment. Figure 1AThe diagram shows a system diagram of an example radio access network (RAN) and an example core network (CN) used in a communication system. Figure 1D The illustration shows a device that can be used according to one embodiment. Figure 1A The diagram shows a further example RAN and a further example CN used in the communication system. Figure 2 This is a flowchart illustrating a method for selecting a carrier from licensed and unlicensed carriers according to an embodiment; Figure 3 This is a flowchart illustrating a method for TX WTRU operation on multiple carriers according to an embodiment; Figure 4 This is a flowchart illustrating a method for resource selection for multiple carriers having licensed and unlicensed carriers according to an embodiment; Figure 5 This is a flowchart illustrating a method for carrier-specific sidechain radio link failure (RLF) based on HARQ counts for multiple carriers with licensed and unlicensed carriers according to an embodiment; Figure 6 This is a flowchart illustrating a method for handling a sidechain RLF in a multicarrier system with licensed and unlicensed carriers according to an embodiment; and Figure 7 This is a flowchart illustrating a method for determining a carrier-specific sidechain RLF based on HARQ counting for multiple carriers according to an embodiment. Detailed Implementation

[0025] Figure 1A This diagram illustrates an example communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content (such as voice, data, video, messaging, broadcasting, etc.) to multiple wireless users. The communication system 100 enables multiple wireless users to access such content by sharing system resources (including wireless bandwidth). For example, the communication system 100 may employ one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), Zero-Tail Unique Word Discrete Fourier Transform Extended OFDM (ZT-UW-DFT-S-OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

[0026] like Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112. Although it will be appreciated, the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d can be any type of device configured to operate and / or communicate in a wireless environment. As an example, WTRUs 102a, 102b, 102c, and 102d (any of which may be referred to as a Station (STA)) may be configured to transmit and / or receive wireless signals and may include User Equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain scenarios), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Any of WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

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

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

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

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

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

[0032] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as NR radio access, which can use NR to establish air interface 116.

[0033] In one embodiment, base station 114a and WTRUs 102a, 102b, and 102c can implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c can jointly implement LTE radio access and NR radio access, for example, using the dual connectivity (DC) principle. Therefore, the air interface utilized by WTRUs 102a, 102b, and 102c can 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).

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

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

[0036] RAN 104 can communicate with CN 106, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, and 102d. Data can have different Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, etc., and / or perform advanced security functions, such as user authentication. Although... Figure 1A As not shown, but as will be understood, RAN 104 and / or CN 106 can communicate directly or indirectly with other RANs that use the same RAT as RAN 104 or a different RAT. For example, in addition to connecting to RAN 104, which can utilize NR radio technology, CN 106 can also communicate with another RAN (not shown) that uses GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

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

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

[0039] Figure 1B This is a system diagram illustrating example WTRU 102. (Example:) Figure 1B As shown, WTRU 102 may include 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 supply 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138, etc. It will be appreciated that WTRU 102 may include any sub-combination of the above-described elements while remaining consistent with the embodiments.

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

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

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

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

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

[0045] The processor 118 can receive power from the power supply 134 and can be configured to distribute and / or control the power going to other components in the WTRU 102. The power supply 134 can be any suitable device for powering the WTRU 102. For example, the power supply 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.

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

[0047] The processor 118 may be further coupled to other peripherals 138, which may include one or more software and / or hardware modules providing additional features, functions, and / or wired or wireless connectivity. For example, peripherals 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and / or video), Universal Serial Bus (USB) ports, vibration devices, television transceivers, hands-free headsets, Bluetooth® modules, FM radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, etc. Peripherals 138 may include one or more sensors. These sensors may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors, geolocation sensors, altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, humidity sensors, etc.

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

[0049] Figure 1C The diagram illustrates a system diagram of RAN 104 and CN 106 according to an embodiment. As noted above, RAN 104 can employ E-UTRA radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 104 can also communicate with CN 106.

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

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

[0052] Figure 1C The CN 106 shown may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (PGW) 166. Although the foregoing elements are depicted as part of CN 106, it will be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0053] The MME 162 can connect to each of the eNode-Bs 162a, 162b, and 162c in RAN 104 via the S1 interface and can act as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, activating / deactivating bearers, and selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, and 102c. The MME 162 can provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies (such as GSM and / or WCDMA).

[0054] The SGW 164 can connect to each of the eNode Bs 160a, 160b, and 160c in RAN104 via the S1 interface. The SGW 164 can typically route and forward user data packets to / from WTRUs 102a, 102b, and 102c. The SGW 164 can perform other functions, such as anchoring the user plane during eNode-B handover, triggering paging when DL data is available for WTRUs 102a, 102b, and 102c, and managing and storing the context of WTRUs 102a, 102b, and 102c.

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

[0056] CN 106 facilitates communication with other networks. For example, CN 106 can provide WTRUs 102a, 102b, and 102c with access to a circuit-switched network (such as PSTN 108) to facilitate communication between WTRUs 102a, 102b, and 102c and conventional terrestrial line communication equipment. For example, CN 106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN 106 and PSTN 108. Additionally, CN 106 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0057] Despite WTRU in Figures 1A to 1D While described as a wireless terminal, it is envisioned that, in some representative embodiments, such a terminal may use (e.g., temporarily or permanently) a wired communication interface with a communication network.

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

[0059] In an Infrastructure Basic Services Set (BSS) mode, a WLAN may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic into and / or out of the BSS. Traffic originating outside the BSS destined for a STA can be delivered to the STA via the AP. Traffic from a STA to a destination outside the BSS can be sent to the AP for delivery to the appropriate destination. Traffic between STAs within the BSS can be sent via the AP, for example, where a source STA can send traffic to the AP, and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic can be sent between source and destination STAs (e.g., directly between them) using a direct link setup (DLS). In some representative embodiments, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). A WLAN using the Standalone BSS (IBSS) mode can exist without an access point (AP), and STAs within or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode may sometimes be referred to as a “self-organizing” communication mode in this document.

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

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

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

[0063] Operating modes below 1 GHz are supported by 802.11af and 802.11ah. The channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV white space (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support instrument-type control / machine-type communication (MTC), such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including support for (e.g., only support) certain and / or limited bandwidths. MTC devices may include batteries with a battery life exceeding a threshold (e.g., to maintain a very long battery life).

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

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

[0066] Figure 1D The diagram illustrates a system diagram of RAN 104 and CN 106 according to an embodiment. As noted above, RAN 104 may employ NR radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 104 may also communicate with CN 106.

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

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

[0069] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without also accessing other RANs (e.g., eNode-Bs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can utilize one or more of gNBs 180a, 180b, and 180c as mobility anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in unlicensed frequency bands. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate with / connect to gNBs 180a, 180b, and 180c, and simultaneously communicate with / connect to another RAN (such as eNode-Bs 160a, 160b, and 160c). For example, WTRUs 102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNBs 180a, 180b, and 180c and one or more eNode-Bs 160a, 160b, and 160c. In a non-standalone configuration, eNode-B 160a, 160b, and 160c can act as mobility anchors for WTRU 102a, 102b, and 102c, and gNB 180a, 180b, and 180c can provide additional coverage and / or throughput to serve WTRU 102a, 102b, and 102c.

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

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

[0072] AMF 182a and 182b can connect to one or more of the gNBs 180a, 180b, and 180c in RAN 104 via the N2 interface and can act as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling different Protocol Data Unit (PDU) sessions with different requirements), selecting specific SMF 183a and 183b, managing registration areas, terminating Non-Access Stratum (NAS) signaling, mobility management, etc. Network slices can be used by AMF 182a and 182b to customize CN support for WTRU 102a, 102b, and 102c based on the service types utilized by WTRU 102a, 102b, and 102c. For example, different network slices can be built for different use cases, such as services that rely on Ultra Reliable Low Latency (URLLC) access, services that rely on Enhanced Massive Mobile Broadband (eMBB) access, and services for MTC access. AMF 182a and 182b can provide control plane functions for handover between RAN 104 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies, such as WiFi.

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

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

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

[0076] Given Figures 1A to 1D as well as Figures 1A to 1D The corresponding descriptions may be performed by one or more emulation devices (not shown) to perform one or more of the functions described herein with respect to one or more of the following: WTRU102a-d, base station 114a-b, eNode-B160a-c, MME 162, SGW 164, PGW 166, gNB180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN185a-b, and / or one or more other devices described herein. An emulation device may be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functions.

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

[0078] The one or more simulation devices can perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation devices can be used in test scenarios in a test laboratory and / or in non-deployed (e.g., testing) wired and / or wireless communication networks to perform testing on one or more components. The one or more simulation devices can be test rigs. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas) can be used by the simulation devices to transmit and / or receive data.

[0079] This paper discloses a solution for multi-carrier operation using an SL WTRU, where the carriers can be licensed (i.e., access via a traditional SL) or unlicensed (i.e., access requires operation similar to an LBT). However, the solution can be extended to consider carriers with different characteristics beyond the access mechanism. In many cases, the solution can be similarly applied to multiple licensed carriers, where some difference may exist in the configuration or characteristics of such carriers. Finally, the solution is also applicable to operation over multiple bandwidth portions, multiple RB sets, etc., regardless of the number of carriers.

[0080] An example of carrier selection among licensed and unlicensed carriers will now be described. As previously mentioned, carrier selection in LTE / NR for licensed carriers treats all carriers equally and considers only the Channel Busy Ratio (CBR). However, unlicensed carriers are clearly unsuitable for certain types of traffic, and a carrier selection scheme based solely on CBR may result in the selection of a set of carriers that may not meet QoS requirements.

[0081] In one example embodiment, the WTRU selects at least one unlicensed carrier for multicarrier transmission based on the QoS of the data and / or the amount of data available and / or the CBR on the licensed carrier.

[0082] refer to Figure 2An example method 200 for carrier selection among licensed and unlicensed carriers is illustrated. The SL TXWTRU can be configured 205 with one or more thresholds (e.g., Prioritized Bit Rate (PBR), buffer state threshold, CBR threshold, etc.) for determining whether transmission on an unlicensed carrier for the SLRB is permitted. For each destination L2 ID configured for transmission on both licensed and unlicensed carriers, the WTRU can establish 210 one or more SL radio bearers for transmission to the L2 ID based on the established QoS flow. Next, the TX WTRU determines 215 whether to select at least one unlicensed carrier based on one or more configured parameters in the SL radio bearers and / or the buffer state associated with that one or more SL radio bearers and / or the maximum CBR on any of the selected licensed carriers. Based on determination 215, the TX WTRU selects 220 multiple licensed carriers and multiple unlicensed carriers for the destination. The TXWTRU can then transmit 225 data for the L2 destination ID on each of the selected carriers.

[0083] When determining whether to select at least one unlicensed carrier based on one or more configured parameters in the SL radio bearer and / or the buffer state associated with the one or more SL radio bearers and / or the maximum CBR on any of the selected licensed carriers for unlicensed operation, examples may include: whether the SLRB is configured with a priority bit rate greater than a threshold; whether the buffer state associated with the one or more SL radio bearers is greater than a threshold during a configured time period; and / or whether the minimum CBR of any selected licensed carrier is greater than the CBR threshold.

[0084] Carrier selection (reselection) behavior can be similar to that of conventional LTE V2X. Specifically, the SL WTRU can perform any of the following: (i) trigger carrier selection (reselection) for each HARQ procedure based on certain conditions related to resource selection (reselection); (ii) select multiple carriers for transmission from the carriers configured for each L2 destination ID; (iii) independently select resources on each carrier in each HARQ procedure; (iv) perform a Logical Channel Prioritization (LCP) procedure for a given grant on a carrier, taking into account the L2 destinations allowed on the carrier; and / or (v) transmit Media Access Control (MAC) Packet Data Units (MPDUs) on the carrier.

[0085] Carrier selection (reselection) conditions are considered for licensed or unlicensed carriers. In a solution family, the WTRU can perform carrier selection (reselection) by considering licensed and unlicensed carriers in different ways. WTRU actions related to carrier selection (reselection) may include determining any one or a combination of the following: (i) the number of carriers to be selected; (ii) the number of carriers of a given type to be selected; (iii) whether to include carriers of a given type in the selected carriers; (iv) when / whether to trigger carrier selection (reselection); (v) whether to select one type of carrier before another; and / or (vi) whether to prioritize one type of carrier (e.g., licensed) over another type of carrier (e.g., unlicensed).

[0086] Considering the type of carrier (e.g., licensed versus unlicensed) during carrier selection (reselection) may include any of the following when performing the above determination: performing the determination in a different manner (e.g., using different conditions herein) when one or more carriers are licensed compared to unlicensed; considering the type (licensed or unlicensed) of the currently selected carrier when performing the determination (e.g., based on some conditions herein being met); and / or possibly using the conditions herein while performing the determination using different conditions or different factors when examining the conditions for performing the determination.

[0087] Conditions for selecting (reselecting) licensed and / or unlicensed carriers. In the above embodiments, the conditions for selecting (reselecting) carriers may include any one or a combination of conditions related to the following: bearer configuration, resource pool configuration, QoS, broadcast type of transmission, modulation and coding rate (MCR), enabled / disabled HARQ feedback, listen-before-speak (LBT) fault, channel busy ratio (CBR), channel occupancy rate (CR), and / or received signal strength indicator (RSSI), as further described below.

[0088] Bearer configuration conditions may include: whether the bearer or logical channel is explicitly configured for a certain behavior; how the WTRU receives its bearer configuration (e.g., pre-configuration, System Information Block (SIB) or Dedicated Radio Resource Control (RRC) signaling); whether the bearer is a network (Uu) bearer or an SL bearer; and / or whether the bearer is the default bearer.

[0089] The conditions for configuring a resource pool can cover any factors related to the PHY channel configured for that resource pool / carrier, such as whether the PHY channel (e.g., the Physical Sidechain Feedback Channel (PSFCH)) is configured or whether the amount / density of the PSFCH is configured.

[0090] QoS considerations can be related to any conditions associated with parameters concerning (potentially specific bearers) QoS, such as priority, reliability, maximum bit rate (MBR) or guaranteed bit rate (GBR), and / or logical channel (LCH) priority bit rate.

[0091] The broadcast type may include any conditions associated with whether the WTRU is transmitting via unicast / multicast / broadcast, such that at least one sidechain radio bearer (SLRB) is established for a specific type of broadcast, the WTRU’s transmission is specific to the broadcast, and / or the amount of data available for transmission to the specific broadcast is above a threshold.

[0092] Conditions related to modulation and coding rate (MCR) can include any conditions associated with the value of MCR (e.g., compared to a threshold), whether MCR is configured, or differences in MCR between two transmissions / bearers.

[0093] Conditions related to enabled / disabled HARQ feedback may include whether the LCH has enabled / disabled HARQ feedback, whether HARQ feedback with enabled / disabled feedback is transmitted, and / or whether the WTRU is configured with HARQ resources (e.g., PSFCH, Physical Uplink Control Channel (PUCCH), etc.).

[0094] Conditions associated with an LBT failure may include: whether an LBT failure has been declared, potentially within a time period, potentially on a carrier or a set of one or more resource blocks (RBs) associated with the carrier; and / or the number of times, potentially consecutive, in which an LBT failure has occurred, potentially on a carrier or a set of one or more RBs associated with the carrier.

[0095] Conditions related to Channel Busy Ratio (CBR) may include: CBR being above or below a threshold; CBR increasing / decreasing by a threshold amount; and / or the CBR of one carrier being above / below the CBR of another carrier, possibly by the configured amount.

[0096] Conditions related to channel occupancy (CR) may include: CR being above or below a threshold; CR increasing / decreasing by a threshold amount; and / or the CR of one carrier being above / below the CR of another carrier, possibly by the configured amount.

[0097] Conditions associated with the Received Signal Strength Indicator (RSSI) may include: RSSI being above or below a threshold; RSSI increasing / decreasing by a threshold amount; and / or the RSSI of one carrier being above / below the CR of another carrier, possibly by a configured amount.

[0098] In some embodiments, the WTRU determines whether to select at least one (or a configured number) of a certain type of carrier. In one solution, the WTRU may determine whether to select one (or a configured number or a configured percentage of the total available) licensed / unlicensed carrier during carrier selection based on one or more of the conditions described above. For example, the SL WTRU may be configured with a threshold buffer state, possibly associated with one or more of the sidechain radio bearers (SLRBs) it has established. During carrier selection, if the buffer state at the time of carrier selection triggering is above a threshold, the WTRU may be allowed to select at least one (or at least N, where N may be pre-configured) unlicensed carriers.

[0099] In one example, if the buffer state is below a threshold (possibly within a specified time period), the WTRU can trigger carrier selection (reselection), and the WTRU has last selected (or is currently using) at least one (at least N) unlicensed carriers. Similarly, if the buffer state is above a threshold (possibly within a time period), the WTRU can trigger carrier selection (reselection), and the WTRU has last not selected (or is currently not using) any unlicensed carriers or has last selected (or is currently using) fewer than N unlicensed carriers.

[0100] In one example, the SL WTRU can be configured with a CBR / CR threshold associated with any one of the available / selected licensed carriers(s). If the CBR / CR of one / configured number / all available / selected licensed carriers is above the threshold, the WTRU can select at least one (at least N) unlicensed carriers. Similarly, the WTRU can consider the minimum / maximum CR / CBR of licensed carriers. Similarly, the WTRU can consider the average CBR / CR of licensed carriers. For example, the SL WTRU can be configured with a CBR / CR threshold associated with carrier reselection. Specifically, if the CBR / CR of one / configured number / all selected licensed carriers is above the threshold (potentially within a specified time period) and the WTRU has not selected any unlicensed carriers, the WTRU can trigger a reselection. Similarly, if the CBR / CR of one / configured number / all selected licensed carriers is below the threshold (e.g., within a time period) and the WTRU is currently using an unlicensed carrier, the WTRU can trigger a carrier reselection.

[0101] In one example embodiment, the SL WTRU may be configured with an indication in the SLRB configuration regarding whether a specific carrier allows the selection of one or more unlicensed carriers. If the WTRU establishes such an SLRB, the WTRU may select at least one (at least N) unlicensed carriers. Alternatively, if the WTRU has data available for transmission on at least one such established SLRB, the WTRU may select at least one (at least N) unlicensed carriers. For example, the SL WTRU may be configured with an indication in the SLRB configuration regarding a preferred carrier type. If all / the configured number / no SLRB configurations indicate that unlicensed / licensed is preferred, the WTRU may select at least one unlicensed / licensed carrier.

[0102] In another example embodiment, the SL WTRU may be configured with a threshold guaranteed bit rate (GBR), a priority bit rate (PBR), a maximum bit rate (MBR), or similar QoS parameters related to the data rate. If the WTRU has established one or more SLRBs whose (potentially total) configured values ​​for its QoS profile are above a threshold, the WTRU may select at least one (at least N) unlicensed carriers.

[0103] As another example, the SL WTRU can be configured with an RSSI threshold, or alternatively with a similar threshold related to the amount of WiFi activity measured in unlicensed carriers. This threshold can be configured per SLRB. If the number of unlicensed carriers whose measured RSSI is below the threshold is greater than the number of carriers at the threshold, the WTRU can select at least one (at least N) unlicensed carriers.

[0104] In some embodiments, the SL WTRU can select the carrier type based on the broadcast type of its transmission. For example, if the WTRU has broadcast transmissions, it can select only licensed carriers (or prioritize the selection of licensed carriers). The SL WTRU can select multiple unlicensed and / or licensed carriers to take into account the number of PSFCH resources configured for the carrier (i.e., select multiple carriers or carriers with at least a threshold number of PSFCH resources).

[0105] An embodiment of TX WTRU operation on multiple carriers will now be described. In SL, particularly in unicast, unlicensed carriers may be used only for certain traffic types or situations (e.g., large volumes of traffic without strict timing requirements). Configuring DRX groups using traditional DRX group mechanisms and having RX WTRU monitor SL for all carriers would be power inefficient. Accordingly, the following embodiments can provide a more efficient option.

[0106] In the first example embodiment, the WTRU performs an initial transmission to the first carrier (anchor carrier) and performs subsequent transmissions to other carriers only after a positive response to the first transmission.

[0107] refer to Figure 3 An example method 300 for TX WTRU operation on multiple carriers is illustrated. The SL TX WTRU can establish a unicast link 305 with a peer WTRU (RX WTRU) and configure 310 multiple carriers to be used for communication with the RX WTRU. In one example, the SL TX WTRU selects the licensed carrier with the lowest CBR as the anchor carrier and sends an indication of the anchor carrier (e.g., in PC5-RRC) to the RX WTRU. The SL TX WTRU selects 315 SL DRX configurations (e.g., DRX period, on duration, inactivity timer, etc.) and sends the DRX configuration to the RX WTRU.

[0108] When data for a transmission to the RX WTRU arrives, and if the inactive timer at the RX WTRU at 320 is not running, the SL TX WTRU may perform a first data transmission to the RX WTRU on the anchor carrier during the RX WTRU's active period, including as part of the transmission (e.g., in the sidechain control information (SCI)) an indication of one or more carriers expected to be used during that active period. Upon receiving a HARQ ACK from the RX WTRU of the first transmission, the TXWTRU initiates a subsequent transmission on the carrier indicated in the first transmission at 330, and resets the inactive timer after the transmissions on both anchor and non-anchor carriers.

[0109] When data for transmission to the RX WTRU arrives, and if the inactive timer at the 320 RX WTRU is running, the TX WTRU can perform 335 data transmission on all carriers indicated by the last carrier transmission indication on the anchor carrier.

[0110] In some embodiments, when licensed and unlicensed carriers are available, the WTRU determines the permitted carrier(s)(s) for the transmission. In a family of solutions, the WTRU can perform transmissions on multiple carriers by considering licensed and unlicensed carriers in different ways, possibly associated with one or more L2 IDs. Transmission-related WTRU actions may include determining any one or a combination of the following: (i) whether data can be transmitted on a carrier; (ii) the set / number of carriers to be used for the relevant set of LCH, L2 ID, or transmission; (iii) whether to prioritize one type of carrier over another when determining on which carrier to transmit; (iv) whether to include a carrier of a given type in the set of carriers to be used for the relevant set of LCH, L2 ID, or transmission; and / or (v) when / whether to perform retransmissions on carriers different from those used for the transmission.

[0111] Taking into account the type of carrier during transmission (e.g., licensed versus unlicensed) may include any of the following when performing the above determination: (i) performing the determination in a different manner (e.g., using different conditions herein) when (one or more) carriers are licensed compared to unlicensed carriers; (ii) taking into account the type (licensed or unlicensed) of the currently selected carrier when performing the determination (e.g., based on some conditions herein being met); and / or (iii) possibly using the conditions herein to perform the determination while using different conditions or different factors when examining the conditions for performing the determination.

[0112] In one embodiment, the TX WTRU can select SL resources (or be provided with SL grants) on licensed or unlicensed carriers. The WTRU can determine whether a transmission can be made on a licensed or unlicensed carrier based on the rules / conditions herein. This can be implemented via a Logical Channel Prioritization (LCP) strategy or process. For example, the WTRU can exclude certain Logical Channels (LCHs) or transmissions from a carrier or the grant associated with the carrier.

[0113] A WTRU can be configured with certain conditions to allow or restrict certain transmissions on a carrier. These conditions can be used to determine, for example, whether the WTRU can perform a transmission on a licensed or unlicensed carrier. These conditions can also be used to determine, for example, whether two related transmissions can be made on licensed / unlicensed carriers, on the same / different carrier types, and / or on carriers with the same / similar configurations relative to the resource pool or carrier characteristics.

[0114] The conditions associated with the data to be transmitted on the carrier can be related to any of the following: bearer configuration, QoS, transmission mode, broadcast type of transmission, MCR, enabled / disabled HARQ feedback, and / or time-based conditions, as described herein.

[0115] Conditions related to bearer configuration may include: (i) whether the bearer or logical channel is explicitly configured for a certain behavior; (ii) how the WTRU receives its bearer configuration (e.g., pre-configured, SIB, or dedicated RRC signaling); and / or (iii) whether the bearer is a Uu bearer or an SL bearer; and / or whether the bearer is the default bearer.

[0116] QoS conditions may include any conditions associated with parameters relating to (potentially specific bearer) QoS, such as priority, reliability, bit rate (e.g., MBR, GBR), and / or priority bit rate (PBR) of LCH.

[0117] Transmission mode conditions can include whether the transmission is periodic or a one-time transmission.

[0118] The broadcast type of the transmission can include any conditions associated with whether the WTRU is transmitting unicast / multicast / broadcast, such as: the WTRU has at least one established SLRB for specific broadcast, the WTRU's transmission is specific broadcast, and / or the amount of data available for transmission for specific broadcast is above a threshold, etc.

[0119] Conditions related to MCR may include those associated with the value of MCR (e.g., compared to a threshold), whether MCR is configured, or differences in MCR between two transports / bearers.

[0120] The conditions for enabling / disabling HARQ feedback may include whether the LCH has enabled / disabled HARQ feedback, whether the transmission has enabled / disabled HARQ feedback, and / or whether the WTRU is configured with HARQ resources (e.g., PSFCH, PUCCH, etc.).

[0121] Time-based conditions can include the elapsed time since an event (such as an event associated with another condition) occurred, for example: the time since a consistent LBT failure; the time since the CBR was above / below a threshold; and / or the time since the last transmission, which may be associated with another condition.

[0122] Conditions associated with the carrier itself may be conditions related to the following: (i) the configuration of the resource pool; (ii) the DRX behavior of (one or more) RX WTRUs on the carrier; (iii) LBT failure; (iv) CBR; (v) CR; (vi) RSSI; and / or (vii) the number of carriers selected, as described in the examples below.

[0123] The configuration of a resource pool can cover any factors related to the PHY channel configured for that resource pool / carrier, such as whether a PHY channel (e.g., PSFCH) is configured or whether the amount / density of the PSFCH is configured.

[0124] The DRX behavior of one or more RX WTRUs on the carrier has DRX-related conditions, including whether the RX WTRU is in DRX on the carrier and / or in DRX mode for the carrier.

[0125] Conditions associated with an LBT failure may include: whether an LBT failure has been declared, potentially within a time period, or potentially on a carrier or one or more sets of RBs associated with the carrier; and / or the number of times, potentially consecutive, in which an LBT failure has occurred, potentially on a carrier or one or more sets of RBs associated with the carrier.

[0126] Conditions associated with CBR may include: CBR being above or below a threshold; CBR increasing / decreasing by a threshold amount; and / or the CBR of one carrier being above / below the CBR of another carrier, potentially by the configured amount.

[0127] Conditions related to CR may include: CR being above or below a threshold; CR increasing / decreasing by a threshold amount; and / or the CR of one carrier being above / below the CR of another carrier, possibly by the configured threshold amount.

[0128] Conditions related to RSSI may include: RSSI being above or below a threshold; RSSI increasing / decreasing by a threshold amount; and / or the RSSI of one carrier being above / below the CR of another carrier, possibly by a configured threshold amount.

[0129] Conditions related to the number of carriers selected may include: the number of unlicensed / licensed carriers selected is above / below a threshold; at least one licensed / unlicensed carrier has been selected; and / or the total number of carriers selected is above / below a threshold.

[0130] Some example implementations can be based on carrier limitations. For example, the WTRU can be configured with a threshold priority for data. If the number of licensed carriers selected by the WTRU is above a threshold, the WTRU can restrict data transmission on licensed carriers to above-threshold (higher priority) data transmissions. For example, the WTRU can be configured with a threshold PBR. If the number of unlicensed carriers selected by the WTRU is above a threshold, the WTRU can restrict data transmission on unlicensed carriers from logical channels with PBRs above the threshold. As another example, if the number of licensed carriers selected by the WTRU is above a threshold, the WTRU can restrict data transmission on licensed carriers that enable HARQ feedback for it.

[0131] In one example embodiment, if the WTRU has selected at least one licensed carrier, the WTRU may restrict the execution of data configured with MCR for itself on the licensed carrier. In another example, if the WTRU has selected at least one licensed carrier, the WTRU may restrict the execution of broadcast data on the licensed carrier that enables HARQ feedback for itself, wherein multiple HARQ feedback resources are configured for different WTRUs in the group.

[0132] In some embodiments, the WTRU can be configured with a threshold priority. For data with a priority higher than the threshold (higher priority), if at least one unlicensed carrier is selected, the WTRU can exclude the transmission of such data on a carrier in the last X seconds (where X can be configured by the network) where, for example, LBT failures, consistent LBT failures, and / or the number of LBT failures exceeds a threshold, such data has occurred.

[0133] In another example, the WTRU can perform periodic transmissions only on licensed frequency bands and can be allowed to perform one-off (i.e., single) transmissions on licensed or unlicensed carriers.

[0134] According to some embodiments, the WTRU performs an initial unicast transmission in the DRX on the anchor carrier. In one solution, while the RX WTRU is in the DRX, the TX WTRU may perform a first transmission on a specific carrier, and then may perform subsequent transmissions on multiple carriers, possibly to the same RX WTRU, possibly within a maximum time after the first transmission.

[0135] A TX WTRU can restrict the first transmission to a specific carrier (e.g., an anchor carrier). In some examples, the anchor carrier can be predefined or (pre)configured. For example, each TX WTRU configured for a transmission to an L2 ID can have an anchor carrier, possibly associated with the L2 ID. For instance, if a TX WTRU performs the first transmission to an L2 destination ID, the WTRU can perform the transmission on the anchor carrier associated with the L2 ID. In another example, the anchor carrier can be selected by either a TX WTRU or an RX WTRU, and configured between the two WTRUs (e.g., via PC5-RRC signaling). For example, a TX WTRU can perform anchor carrier selection based on one or a combination of the following factors: -SL measurement results (e.g., CBR, CR, RSRP, RSSI, etc.). For example, the TX WTRU can be configured with a threshold CBR and / or a threshold CR and / or a threshold RSRP, and can select an anchor carrier from carriers whose corresponding measurement results are above / below the threshold. The TX WTRU can select an anchor carrier with the lowest CBR, lowest CR, highest SL RSRP, lowest RSSI, etc. - Licensed / Unlicensed Basis. For example, a TX WTRU can select an anchor carrier only from among licensed carriers. -LBT Fault Status / Statistics. For example, the TX WTRU can select a carrier with the fewest LBT faults and no pending consistent LBT faults (possibly within a certain time period) as the anchor carrier. - Carrier configuration. For example, the TX WTRU can select an anchor carrier from carriers that have some characteristics associated with its (resource pool) configuration, such as carriers configured with PSFCH resources or carriers configured with corresponding PUCCH resources.

[0136] In some embodiments, the first transmission to the anchor carrier may be time-limited. Specifically, the TXWTRU may limit the first transmission to the on-time duration of the peer WTRU in the DRX. Specifically, the TX WTRU may limit the first transmission to the active time of the RX WTRU.

[0137] In various embodiments, the first transmission to the anchor carrier may be limited by physical layer characteristics such as MCS, enabled / disabled HARQ feedback, number of resources, transmit power, etc. For example, the WTRU may be configured with maximum / minimum values ​​for such physical layer characteristics to be used when performing the first transmission.

[0138] Alternatively, the first transmission to the anchor carrier may have predefined or predetermined unlicensed transmission characteristics. For example, the first transmission may use a maximum / minimum channel access priority class (CAPC). For example, the first transmission may be performed using multi-slot resources in unlicensed spectrum.

[0139] Whether a WTRU is executing a first transfer can be determined by the state of a timer. This timer can be controlled by a previous transfer and / or a corresponding positive response to a previous transfer. For example, the TX WTRU can restart an inactive timer during a transfer to the RX WTRU. As long as the inactive timer is running, the TX WTRU can execute a transfer corresponding to the conditions associated with a subsequent transfer. If the inactive timer has expired, the TX WTRU can execute a transfer corresponding to the conditions of the first transfer.

[0140] Additionally, the first transmission that may be performed on the anchor carrier may provide information relating to subsequent transmissions, including: (i) one or more carriers in which subsequent transmissions may be performed; (ii) inactivity time (i.e., time associated with actions related to subsequent transmissions); (iii) whether the initial transmission will be followed by a subsequent transmission; and / or (iv) information relating to subsequent transmissions.

[0141] Information regarding whether the initial transmission will be followed by a subsequent transmission can be specified: for example, if the initial transmission is not followed by a subsequent transmission, the next transmission performed by the TX WTRU is considered the first transmission and is performed using the features associated with the first transmission described herein. Alternatively, for example, if the initial transmission is followed by a subsequent transmission, the next transmission is performed using the features associated with the subsequent transmission (provided it occurs during inactivity). Information related to the subsequent transmission can be included in the MAC CE, MAC header, SCI, or RRC message included in the initial transmission.

[0142] Below is an example of a WTRU performing subsequent transmissions based on information included in the first transmission. In one example, after the initial transmission, the WTRU can use features associated with subsequent transmissions to perform them. These features may have already been provided to the peer WTRU. For example, the WTRU could perform subsequent transmissions on any of the carriers that were instructed to be used by the peer WTRU in the initial transmission.

[0143] The TX WTRU can change the characteristics of a subsequent transmission during the transmission of that subsequent transmission. For example, the TX WTRU can change the carrier by including the carrier for the additional subsequent transmission in the message sent to the TX WTRU during the transmission.

[0144] The TX WTRU can initiate subsequent transmissions or change the characteristics of subsequent transmissions after a response from the RX WTRU to a message containing this characteristic (or to the initial transmission). For example, the TX WTRU can start transmissions on a carrier other than the anchor carrier only after receiving an affirmative response to the initial transmission.

[0145] In some embodiments, the WTRU is restricted to the anchor carrier and / or certain transmissions to be used as the first transmission. The WTRU may restrict certain transmissions to the anchor carrier regardless of the DRX configuration. For example, the WTRU may: (i) perform PC5-S transmissions only on the anchor carrier; (ii) perform PC5-RRC transmissions only on the anchor carrier; (iii) perform discovery transmissions only on the anchor carrier; (iv) perform initial DCR transmissions only on the anchor carrier; and / or (v) use data-associated conditions (described herein) to determine whether to restrict such data transmissions to the anchor carrier.

[0146] An embodiment of resource selection for multiple carriers with licensed and unlicensed carriers will now be described. In one example embodiment, the WTRU jointly selects initial and backup resources on unlicensed and licensed carriers, respectively, when performing some transmissions for a certain QoS.

[0147] refer to Figure 4 An example method 400 for multi-carrier resource selection with licensed and unlicensed carriers is shown. The SL TX WTRU can be configured 405 to have multiple carriers on both licensed and unlicensed carriers for one or more bearers to the destination, the one or more bearers being configured to allow or disallow backup resource selection.

[0148] When data arrives for a bearer that allows backup resource selection, the WTRU performs a joint resource selection (reselection) procedure 410 on both licensed and unlicensed carriers, such that at time t1, a first available resource is selected on an unlicensed carrier, and at time t2 (later than t1, depending on the amount of the WTRU), a second available resource is selected on a licensed carrier, with t1 and t2 falling within the resource selection window. The WTRU may perform a Level Bypass (LBT) procedure 415 for the transmission on the first resource, and if the LBT fails 420, data is transmitted 425 on the second resource. Otherwise, the WTRU transmits data 430 on the first resource and includes information related to the second resource in the transmission.

[0149] According to some embodiments, resource selection can be performed jointly across multiple carriers. In one solution, the WTRU can perform a joint resource selection process across multiple carriers because the WTRU can select two or more resources across two or more carriers. For example, the WTRU can select a first resource on a first carrier and a second resource on a second carrier. The second resource can be used when transmission on the first resource cannot be performed (e.g., due to an LBT failure).

[0150] In various embodiments, conditions for joint resource selection across multiple carriers can be applied. For example, the WTRU may perform joint resource selection based on one or more of the following conditions: (i) QoS or carrier configuration; (ii) carrier type / availability; (iii) measurements on the carrier; and / or (iv) the capabilities of the RX WTRU.

[0151] When applying conditions for QoS or carrier configuration, WTRU can execute it when the QoS of the data available for transmission allows joint resource selection (e.g., the priority of the data available for transmission is above a threshold or the data available for transmission is on an LCH configured with enabled joint resource selection).

[0152] The conditions for joint resource selection can depend on the carrier type of the available or selected carrier. For example, the WTRU can perform joint resource selection when the selected carrier for the (first) transmission of a transport block (TB) is an unlicensed carrier. In one example, the WTRU can perform joint resource selection when a second transmission is performed on a licensed carrier.

[0153] Conditions for joint resource selection can rely on measurements on the carrier itself (CBR, CR, RSRP, RSSI, LBT fault statistics, etc.), or all available carriers, or the selected carriers. For example, a WTRU can perform joint resource selection when the RSSI of all / selected / specific carriers (potentially unlicensed) is above a threshold. In another example, a WTRU can perform joint resource selection when the CBR of all / selected / specific carriers (potentially licensed) is below a threshold. In yet another example, a WTRU can perform joint resource selection when one or more (consistent) LBT faults on all / selected / specific unlicensed carriers exceed a threshold over a time period. Finally, the ability of a peer WTRU to support joint resource selection performed by a TXWTRU can also be based on conditions for joint resource selection.

[0154] The considerations for resource selection are disclosed. In various embodiments, the WTRU can be configured with conditions regarding the resources selected in each of the carriers. Specifically, the WTRU can be configured with conditions regarding resource size. In one example, the WTRU can select two resources of the same size. In another example, the difference in resource size should be less than / greater than a configured threshold. The size of the second resource (or the size difference between the first and second resources) can further depend on conditions associated with the carrier used or the data QoS.

[0155] The conditions associated with the carrier used to select the first resource may include, for example, the (maximum) size of the second resource configured based on measurements of the first resource (e.g., RSSI, CBR, CR, etc.) or a metric based on the occupancy rate of unlicensed channels used when selecting the first resource (e.g., the number of LBT failures, etc.). In one example, the (maximum) size of the second resource may depend on the frequency difference between the carriers of the first and second carriers.

[0156] Conditions associated with data QoS may include, for example, configuring the size difference between the first and second resources based on the priority of the highest priority LCH available for transmission that has triggered resource selection.

[0157] The WTRU can be further configured with timing conditions for the first and second resources. These conditions can specify a minimum / maximum time difference between the first and second resources, and can specify an allowable time window for both the first and second resources. Specifically, when using sensing results to select two resources, the WTRU should select the available resource that satisfies the conditions of the first resource. For example, the PHY layer can provide all available resources to the MAC layer, and the MAC layer can select resources that satisfy certain timing conditions disclosed herein. For example, the WTRU can determine the timing of the resource based on WTRU capabilities, data QoS / priority / packet delay budget (PDB), channel access priority class (CAPC) (or other similar LBT requirements), HARQ round-trip time (RTT), and / or whether HARQ feedback is enabled / disabled, the type of carrier associated with the first / second resource (e.g., licensed or unlicensed), and / or measurements of the first and / or second carriers. Examples are as follows: -WTRU capability can be used to determine the minimum time difference between the first and second resources; - QoS / priority / PDB of the data. For example, both the first and second resources should be within the time window defined by T2 (i.e., the PDB associated with the data that triggered the resource selection); - The data's CAPC (or other similar LBT requirements). For example, the minimum time difference between the first and second resources can be determined by the data's CAPC. Specifically, the second resource should allow the WTRU to perform LBT on the first carrier, and the WTRU can only perform transmission on the second resource associated with the second carrier if the LBT fails. The time required to determine an LBT failure can depend on the data's CAPC, LBT requirements, etc. - HARQ RTT and / or whether HARQ feedback is enabled / disabled. For example, the minimum time difference between the first and second resources can depend on factors that determine the HARQ RTT, such as PSFCH configuration, whether HARQ feedback is enabled / disabled, etc. - The type of carrier associated with the first / second resource (e.g., licensed or unlicensed). For example, depending on whether the second carrier is licensed or unlicensed, the WTRU can use different values ​​for T2 (derived from the PDB); and / or - Measurement results of the first and / or second carriers. For example, depending on the CBR of the second carrier, the WTRU can use different values ​​of T2 (derived from the PDB). For example, the RSSI of the first carrier can be used to determine the minimum / maximum time difference between resources in the first and second carriers.

[0158] The transmission behavior associated with two carriers according to various embodiments will now be described. In one example, the first resource may be selected on an unlicensed carrier, and the second resource may be selected on either a licensed or unlicensed carrier. The use of the first and / or second resources, and the content of the transmissions on the first and / or second resources, may depend on the LBT state during the transmission on the first resource.

[0159] In an example of an LBT failure on the first resource, the WTRU can perform an LBT on the first resource associated with the first carrier. If the LBT fails, the WTRU can transmit the same transport block (TB) on a second resource. Alternatively, the WTRU can create a new TB for the transmission on the second resource. Whether to transmit the same / different TB on the second resource can depend on the timing and / or size of the resource. Specifically, if the WTRU selects a second resource that occurs at least "X" timeslots after the first resource, the WTRU can perform a transmission of a new TB on the second resource. The WTRU can transmit a conventional SCI on the second resource. Alternatively, the WTRU can indicate (e.g., in the SCI) that the LBT failed on the first resource. Alternatively, the WTRU can include a message in the second transmission containing information about the LBT failure associated with the first resource (e.g., in the MAC CE). For example, the WTRU can indicate the LBT sensing time, RSSI, etc., in such a message.

[0160] In a solution where the LBT succeeds on the first resource, the WTRU may not perform a transfer on the second resource. The WTRU may send an indication of the time / frequency location of the second resource during the transfer on the first resource (e.g., in the SCI). Specifically, the WTRU may indicate the availability of the second resource in the SCI. Alternatively or additionally, the WTRU may decide to use the second resource for a second TB of transfer. The WTRU may indicate the occupancy rate of the second resource during the transfer on the first resource (e.g., in the SCI). The WTRU may be configured with conditions regarding whether to utilize the second resource if the LBT / transfer is successful on the first resource. For example, such conditions may be based on one or a combination of the following: (1) QoS of the data available for transmission. For example, if the WTRU has data with a priority above a threshold that can be used for transmission (after transmission is performed on the first resource), the WTRU can use the second resource for transmission of the new TB. (2) Availability of control information or inter-WTRU coordination information. In one example, if the WTRU has inter-UE coordination (IUC) information, the WTRU can use the second resource to transmit the IUC information. In another example, if the WTRU has pending CQI information for transmission, the WTRU can use the second resource for the transmission of the IUC information. In yet another example, the WTRU can use the second resource to transmit any pending control information intended for the peer WTRU as appropriate. (3) Buffer status. In one example, if the buffer occupancy of the WTRU is above a threshold (possibly for a specific logical channel), the WTRU can use the second resource. (4) Prioritized Bit Rate (PBR). In one example, if the WTRU has at least one LCH where Bj>0, the WTRU can use the second resource for the transmission of a new TB. (5) Availability of authorization. As an example, if the WTRU does not have other authorizations (possibly within a specific time window), it can use the second resource for the transfer of a new TB.

[0161] An embodiment of carrier-specific SL radio link failure (RLF) based on HARQ counting will now be described. Conventional SL radio link failures (RLFs) are designed for a single carrier. One problem with HARQ-based counting in unlicensed carriers is that existing mechanisms cannot distinguish whether the HARQ DTX at the RX WTRU is due to a decoding failure or an LBT failure. Using licensed carriers for information related to the HARQ DTX counts of one or more unlicensed carriers can help address this problem. According to an example embodiment, the WTRU resets / updates the carrier-specific SL-RLF HARQ DRX counter upon receiving a message (e.g., a MAC CE reset) from the RX WTRU.

[0162] refer to Figure 5An example method 500 for determining a carrier-specific SL RLF (SL Response Level LF) of one or more unlicensed carriers based on feedback information in licensed carriers is shown. The SL TXWTRU can establish a unicast link 505 with a peer WTRU and select multiple licensed and / or unlicensed carriers for communication. Independent (i.e., per-carrier separate) counting of HARQ DTXs is performed 510 on each carrier (licensed and unlicensed). A message (e.g., MACCE) indicating received information (e.g., whether a TB was received for an unlicensed carrier) is received from the RX WTRU on a licensed carrier. Upon receiving the message, the WTRU can modify 520 the consecutive number of HARQ DTXs on the indicated carriers. For example, the TX WTRU can reset the consecutive number of HARQ DTXs or subtract a value from the current count of consecutive HARQ DTXs (e.g., indicated in the MAC CE) based on information in the received message. If the number of consecutive HARQDTX on carrier 525 reaches a threshold, the WTRU can give carrier-specific SL RLF indication 530 to the network for that carrier.

[0163] In various embodiments, the WTRU transmits / receives unlicensed carrier information on licensed carriers. In one family of solutions, the WTRU can receive / transmit LBT-related or channel access-related information concerning unlicensed carriers on licensed carriers (SL). Specifically, the WTRU can receive information on licensed carriers related to LBT failures, buffer states, channel occupancy time (COT) information, etc., representing information related to access or transmission on unlicensed carriers. Similarly, based on certain triggers related to channel access on unlicensed carriers, the WTRU can transmit information related to access on unlicensed carriers in SL messages on licensed carriers. The WTRU receiving such information can use it to update counters, timers, resource allocations, and / or modify channel access on unlicensed or licensed spectrum.

[0164] The information mentioned above related to unlicensed spectrum may include any one or a combination of the following: (1) LBT status. As an example, the WTRU may transmit a message on a licensed carrier indicating an LBT fault, a consistent LBT fault, or similar information associated with one or more unlicensed carriers. (2) HARQ Feedback Failure Status. In various examples, the WTRU can transmit a message on a licensed carrier indicating that it is unable to transmit HARQ ACK / NACK on unlicensed spectrum due to an LBT failure. As an example, the WTRU can transmit a message on a licensed carrier when it is unable to access the channel to send HARQ feedback on unlicensed spectrum. In another example, the WTRU can transmit a message on a licensed carrier after a number of consecutive LBT failures (configured values) of “X” associated with the transmission of HARQ feedback. In one example, the WTRU can indicate the number of consecutive LBT failures associated with HARQ feedback in the message. (3) Buffer status information. According to one example, the WTRU may transmit the following message on a licensed carrier: the message indicates the priority / CAPC / quantity / L2 destination ID of the data that can be used for transmission on an unlicensed carrier (and has not yet been transmitted). (4) Channel occupancy measurement results. In some examples, the WTRU may transmit a message containing a measurement result of the channel occupancy of unlicensed spectrum, such as RSSI (possibly per RB set), CR, CBR, the ratio of time periods during which SCIs from other WTRUs can be detected, etc. In one example, the WTRU may perform a measurement of the channel indicating the ratio of time periods during which RSSI is above a threshold even if no SCI is detected (i.e., an indication that the channel is occupied by WiFi transmission). (5) Channel Occupied Time (COT) Information. In one example, the WTRU may transmit a message when it receives / detects COT information received on an unlicensed carrier and the content of the COT information (e.g., COT length, CAPC, L2 destination ID, etc.).

[0165] According to various embodiments, the WTRU can use received LBT fault information to manage SL RLF detection. In one solution, the WTRU can use messages from a peer WTRU on licensed spectrum to update the HARQ DTX count for SL RLF on unlicensed spectrum. For example, upon receiving a message indicating an unlicensed carrier on a licensed carrier, the WTRU can reset the number of consecutive HARQ DTX counters for the SL RLF for that carrier. In one example, upon receiving a message indicating an unlicensed carrier on a licensed carrier, the WTRU can subtract at most a (pre)configured amount from the number of consecutive HARQ DTX counters for the SL RLF for that carrier. In one example, upon receiving a message indicating an unlicensed carrier and a value on a licensed carrier, the WTRU can subtract at most the received value from the number of consecutive HARQ DTX counters for the SL RLF for that carrier. In one example, when a message indicating the enabling / disabling / pausing / resuming of HARQ DTX counting for SL RLF is received on a licensed carrier, the WTRU can enable / disable / pause / resume the HARQ DTX counting for SL RLF on the indicated unlicensed carrier.

[0166] In some embodiments, the WTRU uses the received COT / BSR information for scheduling. In one family of solutions, the WTRU can use the received COT / BSR information to schedule transmissions on unlicensed spectrum. In one solution, the WTRU can use COT information received from the peer WTRU on a licensed carrier to perform resource selection. Specifically, the WTRU can use information related to the COT duration to select resources falling within the COT.

[0167] In another solution, the WTRU can use buffer state information received from the peer WTRU on the licensed carrier to determine COT information. Specifically, the WTRU can determine the COT duration based on the amount of data indicated in the buffer state from the peer WTRU. Specifically, if the buffer state is above a threshold, the WTRU can use the corresponding maximum COT duration. In another example, the WTRU can determine a set of L2 destination IDs (e.g., destinations that allow COT sharing) based on the L2 IDs associated with pending data in the buffer state information received from the peer WTRU on the licensed spectrum. Specifically, if the received message has an SL RSRP above a threshold, the WTRU can include the L2 IDs associated with the buffer state provided by the peer WTRU in the message.

[0168] In another solution, the WTRU can use buffer status information received on a licensed carrier to determine Logical Channel Prioritization (LCP) behavior during transmissions on unlicensed spectrum. For example, if the BSR information indicates data associated with a specific priority, the WTRU receiving the BSR can include the data in a logical channel associated with a priority that is the same / higher / lower than the specific priority.

[0169] In another solution, the WTRU can use buffer state information received on the licensed carrier to determine the CAPC for channel access in order to create a shared COT. Specifically, the WTRU can use the priority of data in its own buffer or the priority of data in the peer WTRU's BSR (i.e., received in a message on the licensed spectrum) to determine the CAPC for channel access. For example, if the BSR information indicates data associated with a specific priority (potentially greater than the priority associated with any data in the transmitting WTRU's buffer), the WTRU can use the CAPC associated with the peer WTRU's BSR information instead of the WTRU's own information.

[0170] An embodiment of an SL RLF in a multi-carrier system with licensed and / or unlicensed carriers will now be described. A traditional SL RLF based on HARQ feedback is designed for a single carrier. For multi-carrier systems, the SL RLF can be per-carrier and / or per-link, and this can depend on the correlation between carriers. According to one example embodiment, the WTRU triggers an SL-RLF, releases a unicast link, and notifies the network when resource selection cannot find at least one licensed / unlicensed carrier that meets the CBR threshold. In another example embodiment, the WTRU determines a carrier-specific RLF for a licensed or unlicensed carrier in a multi-carrier SL with the peer WTRU based on the number of consecutive DTX counts for a specific carrier exceeding a threshold DTX count, and reselects a new carrier excluding carriers previously determined in the case of a carrier-specific RLF. The TXWTRU can release the multi-carrier link with the RX WTRU only if no carriers remain that were not determined in the case of a carrier-specific RLF.

[0171] refer to Figure 6 An example method 600 for determining carrier-specific SL RLF and / or link failures based on configured CBR thresholds is illustrated. The SL TX WTRU can be configured 605 with a first CBR threshold for licensed carriers and a second CBR threshold for unlicensed carriers, and configured with a time period for avoiding carrier selection after a carrier-specific SL RLF. The TXWTRU establishes a 610 unicast link with the peer WTRU and selects multiple licensed and / or unlicensed carriers for communication.

[0172] When a carrier-specific SL RLF occurs on a single carrier, carrier selection (reselection) 615 can be triggered, selecting multiple SL carriers in licensed bands where their CBR is below a first threshold and multiple carriers in unlicensed bands where their CBR is below a second threshold, wherein the time interval between the triggering of carrier selection (reselection) and the last carrier-specific SL RLF for that unicast link exceeds a (pre)configured time interval threshold. If 620, the SL TX WTRU is unable to select at least one carrier supported by the RX WTRU, then 630 SL-RLF is triggered, releasing the unicast link and notifying the network. Otherwise, the SL TX WTRU selects multiple carriers 625 and continues unicast link operation using the selected carriers.

[0173] In various solutions, a per-carrier SL RLF can be triggered, referred to herein as a carrier-specific SL RLF. In one solution, a WTRU operating across multiple carriers can monitor / detect / trigger a carrier-specific SL RLF. Specifically, a per-carrier SL RLF can be triggered, where the WTRU maintains a counter for each carrier that counts the number of consecutive HARQ DTXs received on a given carrier, with the counter incrementing / resetting independently based on HARQ feedback received from the RX WTRU. When the number of consecutive HARQ DTXs on a carrier reaches its maximum value, the WTRU triggers an SL-RLF for that carrier (but not other carriers). In various embodiments, a carrier-specific SL RLF does not immediately result in the release of the unicast link, as the WTRU can continue operating the unicast link on another carrier.

[0174] refer to Figure 7A method 700 for determining a carrier-specific SL RLF based on HARQ DTX is shown. The TX WTRU can use multiple SL carriers (e.g., licensed and / or unlicensed carriers) to establish a unicast link with the RX WTRU 705. The TX WTRU transmits information 710 to the RX WTRU using at least a first SL carrier from the multiple SL carriers. The TX WTRU counts 715 the number of consecutive HARQ DTXs detected on the first SL carrier until the number exceeds a configured threshold 720. At this point, a carrier-specific SL RLF is determined for the first SL carrier, and the TX WTRU initiates a SL carrier reselection process 725. If 730, no SL carrier remains among the multiple carriers determined without a carrier-specific RLF, the TX WTRU releases the unicast link with the RX WTRU 735. Otherwise 730, a second SL carrier is selected from the multiple carriers 740, and the TX WTRU instructs the RX WTRU on the carrier-specific RLF of the first carrier 745, and maintains the unicast link with the RX WTRU 750. In some configurations, at step 745, the TX WTRU may additionally indicate the selected second SL carrier to the RX WTRU.

[0175] In some embodiments, the WTRU configured to perform carrier-specific SL RLF monitoring can be configured with different values ​​for the maximum number of consecutive HARQ DTXs. For example, the WTRU can apply a first value for licensed carriers and a second value for unlicensed carriers.

[0176] In some embodiments, the WTRU may trigger a carrier-specific SL RLF after receiving an indication of DTX or carrier-specific SL RLF from the peer WTRU (e.g., received in another carrier).

[0177] Actions taken when a carrier-specific SL RLF is triggered. The WTRU may perform any one or a combination of the following actions when a carrier-specific SL RLF is triggered: (1) The carrier is suspended from use. In one example, the carrier determined by the RLF is considered no longer available as the selected carrier. Alternatively, the carrier can still be considered as the selected carrier, but the WTRU cannot select / receive any licenses on the carrier. (2) Initiating a carrier disable timer associated with selecting (reselecting) a carrier or transmitting on a carrier. In one example, the WTRU may initiate a timer associated with a failed carrier. Although the timer is running and has not expired, the WTRU cannot select a carrier during the carrier selection process. The WTRU may initiate the carrier disable timer after receiving an indication from the peer WTRU (received on another carrier) or due to carrier-specific SL RLF on the carrier. In various embodiments, the WTRU may be configured with different carrier disable timers for licensed and unlicensed spectrum. (3) Trigger carrier reselection. For example... Figure 7 As discussed in step 725, the WTRU can initiate a carrier reselection process. The WTRU can be configured with conditions relating to when a carrier-specific SL-RLLF triggers carrier reselection. For example, carrier reselection can be performed if the carrier that triggered the SL-RLLF has a CBR below a threshold, if the number of remaining (selected) carriers (which may have a CBR below a threshold) falls below a threshold number of carriers, if the conditions relating to the number of selected licensed / unlicensed carriers discussed herein are not met, and / or if the carrier that triggered the SL-RLLF has the lowest CBR of all selected carriers. (4) Notify the peer WTRU of the SL-RLF on the carrier by transmitting a message on another carrier.

[0178] In one solution, the WTRU can trigger the link's own SL-RLF after a carrier selection (reselection) failure. Specifically, a carrier-specific SL RLF can trigger carrier selection (reselection). Other events (e.g., changes in CBR) can also trigger carrier selection (reselection). During carrier reselection, the WTRU may not select any carrier that recently (i.e., based on the value of the disable timer) triggered a carrier-specific SL RLF. The WTRU can further determine whether it can use a carrier based on a CBR threshold, wherein: (i) the CBR threshold used for carrier selection (reselection) after a carrier-specific SL RLF may differ from the CBR threshold after carrier selection (reselection) for other reasons; (ii) the CBR thresholds for licensed and unlicensed carriers during carrier selection (reselection) may be different; (iii) the number of carriers to be selected after a carrier-specific SL RLF may be different from the number of carriers to be selected for normal carrier selection (reselection); and / or (iv) after a carrier-specific SL RLF, the WTRU may reselect only the failed carrier, while other carriers are maintained. During carrier selection (reselection) for other reasons, the WTRU can perform a full carrier reselection process.

[0179] SL RLF is triggered based on counts across multiple carriers. In one solution, the WTRU can be configured to perform HARQ DTX counting commonly across some / all carriers. For example, a subset of carriers can be configured as the relevant carriers at the SL WTRU. In this case, the SL WTRU can count HARQ DTX commonly across those relevant carriers. For example, the relevant carriers can be explicitly configured (e.g., in RRC signaling) or implicitly determined (e.g., based on pool configuration or PSFCH configuration). For example, carriers that allow PSFCH transmission across carriers can be considered as relevant carriers from the HARQ DTX counts determined for the SLRLF.

[0180] In another solution, the WTRU can count HARQ DTX across multiple carriers in different ways. Specifically, the WTRU can perform any of the following when counting HARQ DTX across multiple carriers: (1) The WTRU can treat multiple HARQ DTXs as a single instance (or increment the counter by only 1). The WTRU can perform this behavior based on conditions such as the relative timing with respect to the PSFCH resources, the relative frequency between carriers, whether the PSFCH resources are configured for cross-carrier HARQ feedback, or whether both PSFCH resources can be used to report HARQ feedback for a single transmission. Specifically, if two PSFCH resources on different carriers are within x times of each other, the HARQ DTXs associated with both resources are counted only once. (2) WTRU can be configured with different values ​​for the maximum number of HARQ DTX to trigger SL RLF based on the number of carriers that have a common count across them and / or whether cross-carrier HARQ feedback is configured and the specific configuration. (3) The WTRU may reset the counter for the number of consecutive HARQ DTXs only when the PSFCH is received on multiple carriers (or subsets) or related carriers. For example, the counter may be reset only if the WTRU successfully decodes the PSFCH on two of the N carriers on which it is performing a common count.

[0181] When an SL RLF is triggered for a set of carriers while counting is being performed jointly, the WTRU may stop: (i) using all carriers for a period of time; (ii) using only the carriers in which most of the HARQ DTXs are counted; and / or (iii) using different carriers in the set for different amounts of time based on the number of consecutive HARQ DTXs counted on that specific carrier.

[0182] Although the features and elements have been described above in specific combinations, those skilled in the art will appreciate that each feature or element may be used individually or in any combination with other features and elements. Furthermore, the methods described herein can be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as internal hard disks and removable disks), magnetic-optical media, and optical media (such as CD-ROMs and digital multifunction discs (DVDs)). The processor associated with the software can be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A method for a wireless transmit and receive unit (WTRU), the method comprising: Establish a unicast link with the peer WTRU that allows the use of multiple sidechain (SL) carriers; Data is transmitted to the peer WTRU on at least the first SL carrier of the plurality of SL carriers; A carrier-specific SL radio link failure (RLF) of the first SL carrier is determined based on the number of detected consecutive Hybrid Automatic Repeat Request (HARQ) Discontinuous Transmissions (DTX) on the first SL carrier exceeding a threshold HARQ DTX count. Based on the determined carrier-specific SL RLF of the first SL carrier, an SL carrier reselection process is performed to select a second SL carrier from the plurality of SL carriers, excluding SL carriers determined under the carrier-specific SL RLF; and In the absence of a carrier-specific SL RLF, an instruction to transmit the carrier-specific RLF of the first SL carrier to the peer WTRU on one of the plurality of SL carriers.

2. The method of claim 1, wherein if the SL carrier reselection process fails due to all carriers having carrier-specific SL RLFs, the method further comprises: Release the unicast link with the peer WTRU.

3. The method of claim 1 or 2, wherein the unicast link includes a vehicle-to-everything (V2X) carrier aggregation (CA) sidechain.

4. The method of any one of claims 1 to 3, wherein the plurality of SL carriers includes carriers in the licensed spectrum.

5. The method of any one of claims 1 to 4, wherein the indication of the carrier-specific RLF of the first SL carrier is transmitted using a PC5-Radio Resource Control (RRC) message.

6. A wireless transmit and receive unit (WTRU), comprising: A transceiver and a processor communicating with the transceiver, the transceiver and the processor being configured to: Establish a unicast link with the peer WTRU that allows the use of multiple sidechain (SL) carriers; Data is transmitted to the peer WTRU on at least the first SL carrier of the plurality of SL carriers; A carrier-specific SL radio link failure (RLF) of the first SL carrier is determined based on the number of detected consecutive Hybrid Automatic Repeat Request (HARQ) Discontinuous Transmissions (DTX) on the first SL carrier exceeding a threshold HARQ DTX count. Based on the determined carrier-specific SL RLF of the first SL carrier, an SL carrier reselection process is performed to select a second SL carrier from the plurality of SL carriers, excluding SL carriers determined under the carrier-specific SL RLF; and In the absence of a carrier-specific SL RLF, an instruction to transmit the carrier-specific RLF of the first SL carrier to the peer WTRU on one of the plurality of SL carriers.

7. The WTRU of claim 6, wherein if the SL carrier reselection process fails due to all carriers having carrier-specific SL RLFs, the processor and transceiver are further configured to: Release the unicast link with the peer WTRU.

8. The WTRU of claim 6 or 7, wherein the unicast link includes a vehicle-to-everything (V2X) carrier aggregation (CA) sidechain.

9. The WTRU of any one of claims 6 to 8, wherein the plurality of SL carriers includes carriers in the licensed spectrum.

10. The WTRU of any one of claims 6 to 9, wherein the indication of the carrier-specific RLF of the first SL carrier is transmitted using a PC5-Radio Resource Control (RRC) message.

11. A method for a wireless transmit-receive unit (WTRU), the method comprising: On the PC5 link, a radio resource control (RRC) configuration signaling is sent to the peer WTRU to establish a multi-carrier vehicle-to-everything (V2X) sidechain (SL) communication with the peer WTRU using multiple SL carriers in the licensed spectrum. Monitor Hybrid Automatic Repeat Request (HARQ) feedback from the peer WTRU to detect multiple consecutive discontinuous transmissions (DTX) on the first SL carrier of the peer WTRU for transmitting data. The carrier-specific SL RLF of the first SL carrier is determined based on the number of consecutive HARQ DTX detected on the first SL carrier exceeding the configured HARQ DTX counting threshold. Based on the determined carrier-specific SL RLF of the first SL carrier, determine whether any SL carrier among the plurality of SL carriers not determined in the case of the carrier-specific SL RLF is available; and Given that an available SL carrier is determined, the available SL carrier is selected as the second SL carrier, and multi-carrier V2X SL communication with the peer WTRU continues, while the SL RLF of the first SL carrier is indicated to the peer WTRU; or If no available SL carrier is determined, release the PC5 link with the peer WTRU.

12. The method of claim 11, wherein the HARQ feedback from the peer WTRU is monitored on the physical measurement feedback channel (PSFCH) from the peer WTRU.

13. A method for a receiving (Rx) wireless transmit and receive unit (WTRU), the method comprising: Establish a unicast link with the transmit (Tx) WTRU and receive configuration information that allows the use of multiple sidechain (SL) carriers; Data is received from the Tx WTRU on at least the first SL carrier among the plurality of SL carriers; Send an indication to the Tx WTRU of the Hybrid Automatic Repeat Request (HARQ) feedback related to the first SL carrier; The carrier-specific SL radio link failure (RLF) indication of the first SL carrier is received from the Tx WTRU on a second SL carrier among the plurality of SL carriers, based at least in part on the transmitted HARQ feedback associated with the first carrier; and The unicast link with the TxWTRU is continued using at least a second SL carrier that does not have a carrier-specific SL RLF from among the plurality of SL carriers.

14. The method of claim 13, further comprising: Once a carrier-specific SL RLF indication has been received for all of the plurality of SL carriers, the unicast link with the TxWTRU is released.

15. The method of claim 13 or 14, wherein the unicast link includes a vehicle-to-everything (V2X) carrier aggregation (CA) sidechain.

16. The method of any one of claims 13 to 15, wherein the plurality of SL carriers includes carriers in a licensed spectrum.

17. The method of any one of claims 13 to 15, wherein the plurality of SL carriers comprises at least one licensed carrier and at least one unlicensed carrier.

18. The method of any one of claims 13 to 17, wherein the indication of HARQ feedback in relation to the first SL carrier is transmitted in the Physical Sidechain Feedback Channel (PSFC).

19. The method of any one of claims 13 to 18, wherein the indication of the carrier-specific RLF of the first SL carrier is received in a PC5-Radio Resource Control (RRC) message.

Images