SL RLF in multi-carrier, licensed and unlicensed

Abstract

A sidelink (SL) wireless transmit / receive unit (WTRU) may be configured to establish a unicast link with a peer WTRU that enables the use of multiple SL carriers, and transmits 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 number of detected consecutive hybrid automatic repeat request (HARQ) discontinuous transmissions (DTX) exceeding a threshold HARQ DTX count, and performs an SL carrier reselection procedure to select a second SL carrier, excluding the SL carrier determined using the carrier-specific SL RLF. The WTRU transmits an indication of the carrier-specific RLF of the first SL carrier to the peer WTRU on one of the multiple SL carriers that does not have a carrier-specific SL RLF. If no SL carriers remain available, the WTRU releases the unicast link with the peer WTRU. Additional embodiments are disclosed.

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of U.S. Provisional Patent Application No. 63 / 531,227, filed August 7, 2023, the contents of which are incorporated herein by reference. [Background technology]

[0002] Multi-carrier is a third generation partnership (3 rd In Release 18 of the 3GPP (3rd Generation Partnership) standard, multicarrier is specified for the new radio (NR) sidelink (SL). While multicarrier is expected to use long term evolution (LTE) as a baseline, some differences may be considered to address unicast transmission in NR. In addition, unlicensed operation for SL is also specified, and these two features are not expected to interact. Specifically, for Rel. 18 user equipment (UE), multicarrier operation is considered for licensed carriers. Furthermore, unlicensed operation is being considered for a single carrier only. However, it is expected that future releases will require support for UEs operating on a combination of licensed and unlicensed carriers.

[0003] Several areas specific to sidelink (SL) communications are being considered for operating 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). Carrier selection based on priority and channel busy ratio (CBR) may not be appropriate when a mix of licensed and unlicensed carriers exists. Specifically, licensed and unlicensed carriers cannot be considered equal in terms of resource usage, QoS maintenance, and access. DRX for SL is currently designed for single carriers only. Multi-carrier DRX exists for uplink and downlink (i.e., Uu interface) based on DRX groups. However, defining DRX groups has the limitation that, in the context of multi-carrier licensed / unlicensed in SL, the receiving (RX) UE would need to monitor all carriers configured for transmission by the transmitting (TX) UE, which may not be ideal from a power consumption perspective, especially if some of these carriers are in the unlicensed band. Hybrid Automatic Repeat Request (HARQ)-based RLF determination is also designed for single carrier only. With SL multi-carrier, whether a problem on one carrier warrants SL RLF determination for the entire link may depend on the carriers themselves and / or possibly whether they are licensed / unlicensed.

[0004] Carrier selection in LTE / NR for licensed carriers treats all carriers equally and considers only CBR. However, unlicensed carriers are clearly not applicable to certain types of traffic, and a CBR-based approach to carrier selection alone may result in selecting 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 amounts of traffic without strict timing requirements). Configuring DRX groups using the legacy DRX group mechanism and having RX UEs monitor SL for all carriers would be power inefficient.

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

[0007] The legacy SL RLF based on HARQ feedback is designed for single carrier only. In the multi-carrier case, the SL RLF may be on a per-carrier and / or per-link basis, which may depend on the interrelationship between carriers. A solution for multi-carrier sidelinks using licensed and / or unlicensed carriers is needed. Summary of the Invention

[0008] According to certain aspects of the present disclosure, one or more of the aforementioned problems may be addressed by a UE, herein interchangeably referred to as a wireless transmit receive unit (WTRU), selecting at least one unlicensed carrier for multi-carrier transmission based on the QoS of the data and / or the amount of available data and / or the CBR on the licensed carriers.

[0009] In one example, the SL TX WTRU may be configured with one or more thresholds for determining whether to enable transmission on an unlicensed carrier for an SL radio bearer (SLRB), e.g., a prioritized bit rate, a buffer status threshold, a CBR threshold, etc. For each destination L2 ID configured for transmission over both licensed and unlicensed, the method may include (i) establishing one or more SL radio bearers for transmission to the L2 ID based on established QoS flows, (ii) determining whether to select at least one unlicensed carrier based on one or more configured parameters in the SL radio bearer and / or a buffer status associated with the one or more SL radio bearers for which unlicensed operation is allowed and / or a maximum CBR on any of the selected licensed carriers, (iii) selecting a number of licensed carriers and a number of unlicensed carriers for the destination, and (iv) transmitting data toward 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 in the SL radio bearer, and / or a buffer status associated with one or more SL radio bearers for which unlicensed operation is allowed, and / or a maximum CBR on any of the selected licensed carriers may include, for example, whether the SL radio bearer (SLRB) is configured with a prioritized bit rate greater than a threshold, whether a buffer status associated with one or more SLRBs is greater than a threshold for a configured period of time, and / or whether the minimum CBR of any selected licensed carrier is greater than a CBR threshold.

[0011] According to another aspect, the WTRU performs an initial transmission on a first carrier (anchor carrier) and only performs subsequent transmissions on other carriers following an acknowledgement of the first transmission.

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

[0013] In one example, when the transmitted data arrives at 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 time. The TX WTRU includes as part of the transmission (e.g., in the sidelink control information (SCI)) an indication of the carrier intended to be used during this active period. Upon receiving a HARQ ACK from the first transmission, the TX WTRU begins subsequent transmissions on the carrier indicated in the first transmission and resets the inactivity timer after transmissions on the anchor and non-anchor carriers.

[0014] In another example, when data arrives for transmission to the RX WTRU and the inactivity timer in the RX WTRU is running, the TX WTRU performs data transmission on all carriers indicated by the last carrier transmission indicator on the anchor carrier.

[0015] According to further aspects of the present disclosure, when performing several transmissions for a particular QoS, the WTRU may jointly select initial and backup resources on the unlicensed and licensed carriers, respectively.

[0016] In one example, the SL TX WTRU is configured with one or more bearers for transmission to a destination that is configured to enable multi-carrier on both licensed and unlicensed carriers and backup resource selection or not. When data arrives for a bearer that enables backup resource selection, the TX WTRU may perform a joint resource (re)selection procedure on the licensed and unlicensed carriers.

[0017] In one example, the joint resource (re)selection procedure includes selecting a first available resource on an unlicensed carrier at time t1 and selecting a second available resource on a licensed carrier at time t2, which is later than t1, where t1 and t2 are within a resource selection window. The TX WTRU performs listen-before-talk (LBT) for transmission 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 the present disclosure, a method is disclosed for a WTRU to reset a carrier-specific SL-RLF HARQ DRX counter upon receiving a message (eg, a reset MAC CE) from a RX WTRU.

[0019] In one example, the SL TX WTRU establishes a unicast link with a peer WTRU (i.e., the RX WTRU) and selects multiple licensed and / or unlicensed carriers for communication. The TX WTRU performs independent (i.e., separate counters per carrier) counting of hybrid automatic repeat request (HARQ) discontinuous transmissions (DTXs) ​​on each carrier (licensed and unlicensed). The TX WTRU receives a message (e.g., a MAC CE) on a licensed carrier indicating one or more unlicensed carriers from the RX WTRU. The TX WTRU modifies the number of consecutive HARQ DTXs on the indicated carrier. For example, the TX WTRU resets the count of the number of consecutive HARQ DTXs or subtracts a value (e.g., indicated in the MAC CE) from the current consecutive HARQ DTX count. If the number of consecutive HARQ DTXs on a carrier reaches a threshold, the WTRU may indicate a carrier-specific SL radio link failure (RLF) for that carrier to the network.

[0020] According to still further aspects of the present disclosure, the WTRU may trigger a sidelink (SL) radio link failure (RLF), release the unicast multi-carrier link, and notify the network and / or the RX WTRU when the resource selection fails to find at least one licensed / unlicensed carrier that meets a channel busy ratio (CBR) threshold or that did not have a carrier-specific RLF within a given period, for example.

[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 to avoid carrier selection after a carrier-specific SL RLF. The SL TX WTRU establishes a unicast link with a 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 (re)selection is triggered, causing the TX WTRU to select some carriers on the licensed band that have a CBR lower than the first threshold and some carriers on the unlicensed band that are less than the second threshold, and the time period between the triggering of carrier (re)selection and the last carrier-specific SL RLF on the unicast link exceeds the (pre-)configured time period threshold.

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

[0023] According to certain aspects, when the TX WTRU is unable to select at least one carrier that is supported by the RX WTRU and / or that is not determined using a carrier-specific RLF, 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 some carriers and continues operation of the unicast link using the selected carriers. Additional embodiments are disclosed. [Brief explanation of the drawings]

[0024] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings, in which like reference numerals indicate similar elements and in which: [Figure 1A] 1 is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] 1B is a system diagram illustrating an exemplary wireless transmit / receive unit (WTRU) that may be used within the communication system illustrated in FIG. 1A, according to one embodiment. [Figure 1C] 1A is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communication system illustrated in FIG. 1A, according to one embodiment. [Figure 1D] 1B is a system diagram illustrating a further exemplary RAN and a further exemplary CN that may be used within the communication system illustrated in FIG. 1A, according to one embodiment. [Figure 2] 1 is a flow diagram illustrating a method for selecting a carrier from among licensed and unlicensed carriers, according to one embodiment. [Figure 3] 10 is a flow diagram illustrating a method of TX WTRU operation on multiple carriers, according to one embodiment. [Figure 4] 1 is a flow diagram illustrating a method of resource selection for multi-carrier having licensed and unlicensed carriers, according to one embodiment. [Figure 5] FIG. 1 is a flow diagram illustrating a method for carrier-specific sidelink radio link failure (RLF) based HARQ counting for multi-carrier having licensed and unlicensed carriers, according to one embodiment. [Figure 6] FIG. 10 is a flow diagram illustrating a method for handling sidelink RLF in a multi-carrier environment having licensed and unlicensed carriers according to one embodiment; [Figure 7]FIG. 10 is a flow diagram illustrating a method for determining carrier-specific sidelink RLF based on HARQ counting for multiple carriers according to one embodiment; DETAILED DESCRIPTION OF THE INVENTION

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

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

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

[0028] The base station 114a may be part of the RAN 104, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The 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 a cell (not shown). These frequencies may be licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide wireless service coverage for a specific geographic area, which may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In one embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and may utilize multiple transceivers per sector of the cell, for example, using beamforming to transmit and / or receive signals in desired spatial directions.

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

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

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

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

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

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

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

[0036] The RAN 104 may communicate with the CN 106, which may be any type of network configured to provide voice, data, application, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have various quality of service (QoS) requirements, such as different throughput, latency, error tolerance, reliability, data throughput, mobility, etc. The CN 106 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions such as user authentication. Although not shown in FIG. 1A , it will be understood that the RAN 104 and / or CN 106 may communicate directly or indirectly with other RANs that use the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which may utilize NR radio technology, the CN 106 may also communicate with another RAN (not shown) employing GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

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

[0038] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links.) For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with a base station 114a, which may employ a cellular-based wireless technology, and a base station 114b, which may employ an IEEE 802.2 wireless technology.

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

[0040] The 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. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. While FIG. 1B depicts the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

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

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

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

[0045] The processor 118 may receive power from the power source 134 and may be configured to distribute and / or control the power to other components in the WTRU 102. The power source 134 may be any suitable device for providing power to the WTRU 102. For example, the power source 134 may include one or more dry batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, 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) regarding 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) over the air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be appreciated that the WTRU 102 may obtain location information by way of any suitable location-determination method while remaining consistent with an embodiment.

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

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

[0049] 1C is a system diagram illustrating the RAN 104 and the CN 106, according to one embodiment. As noted above, the RAN 104 may employ E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also communicate with the CN 106.

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

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

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

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

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

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

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

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

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

[0059] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) of the BSS and one or more stations (STAs) associated with the AP. The AP may have access to or interface with a distribution system (DS) or another type of wired / wireless network that carries traffic within and / or outside the BSS. Traffic originating outside the BSS to a STA may arrive through the AP and be delivered to the STA. Traffic originating at a STA and destined for a destination outside the BSS may be sent to the AP to be delivered to the respective destination. Traffic between STAs within a BSS may be transmitted, for example, through the AP, where the source STA may send traffic to the AP, and the AP may deliver the traffic to the destination STA. Traffic between STAs within a BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent between (e.g., directly between) a source STA and a destination STA using a direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and STAs within or using the IBSS (e.g., all of the STAs) may communicate directly with each other. The IBSS mode of communication may be referred to herein as an "ad hoc" communication mode.

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

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

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

[0063] Sub-1 GHz operating modes are supported by 802.11af and 802.11ah. Channel operating bandwidths and carriers 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 representative embodiments, 802.11ah may support meter-type control / machine-type communications (MTC), such as MTC devices, in macro coverage areas. MTC devices may have limited capabilities, including support for certain and / or limited bandwidths (e.g., only supporting these). An MTC device may include a battery with a battery life above a threshold (eg, 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 a 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 configured and / or limited by the STAs among all STAs operating in the BSS that support the minimum bandwidth operating mode. In an 802.11ah embodiment, the primary channel can be 1 MHz wide for STAs (e.g., MTC-type devices) that support (e.g., only) the 1 MHz mode, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Allocation Vector (NAV) configuration can depend on the status of the primary channel. For example, if a STA (that only supports 1 MHz mode of operation) transmitting to an AP has a busy primary channel, all of the available frequency bands may be considered busy even if most of the available frequency bands are idle.

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

[0066] 1D is a system diagram illustrating the RAN 104 and the CN 106, according to one embodiment. As noted above, the RAN 104 may employ NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also communicate with the CN 106.

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

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

[0069] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c without accessing another RAN (e.g., eNodeBs 160a, 160b, 160c, etc.). In a standalone configuration, the WTRUs 102a, 102b, 102c may utilize one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in unlicensed bands. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate with and connect to gNBs 180a, 180b, 180c while also communicating with and connecting to another RAN, such as eNodeBs 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNodeBs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNodeBs 160a, 160b, 160c may act as mobility anchors for the WTRUs 102a, 102b, 102c, and the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

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

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

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

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

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

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

[0076] 1A-1D and the corresponding description thereof, one or more or all of the functions described herein with respect to one or more of the WTRUs 102a-102d, base stations 114a-114b, eNodeBs 160a-160c, MME 162, SGW 164, PGW 166, gNBs 180a-180c, AMFs 182a-182b, UPFs 184a-184b, SMFs 183a-183b, DNs 185a-185b, and / or any other devices described herein may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more or all of the functions described herein. For example, the emulation devices may be used to test other devices and / or simulate network and / or WTRU functions.

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

[0078] One or more emulation devices may perform one or more functions, inclusive, while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be utilized in test scenarios in a test lab and / or in an undeployed (e.g., test) wired and / or wireless communication network to implement testing of one or more components. One or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (which may include, e.g., one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0079] Disclosed herein is a solution for multi-carrier operation by a SL WTRU, where the carriers can be licensed (i.e., access is via legacy SL) or unlicensed (i.e., access requires LBT-like operation). However, the solution can be extended to consider carriers with different characteristics, separate from the access mechanism. In many cases, the solution can be applied equally to multi-carriers across multiple licensed carriers, where there may be some differences in the configuration or characteristics of such carriers. Finally, instead of considering multiple carriers, the solution can also be applied to operation across multiple bandwidth portions, multiple RB sets, etc.

[0080] Next, embodiments for carrier selection from among licensed and unlicensed carriers are described. As mentioned earlier, carrier selection in LTE / NR for licensed carriers treats all carriers equally and considers only channel busy ratio (CBR). However, unlicensed carriers are clearly not applicable to certain types of traffic, and a CBR-based approach to carrier selection alone may result in selecting a set of carriers that may not meet QoS requirements.

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

[0082] Referring to FIG. 2, an example method 200 for selecting a carrier from among licensed and unlicensed carriers is shown. The SL TX WTRU may be configured with one or more thresholds (e.g., prioritized bit rate (PBR), buffer status threshold, CBR threshold, etc.) for determining whether to allow transmission on an unlicensed carrier for SLRB 205. For each destination L2 ID configured for transmission on both licensed and unlicensed carriers, the WTRU may establish one or more SL radio bearers for transmission to the L2 ID based on the established QoS flows 210. The TX WTRU then determines 215 whether to select at least one unlicensed carrier based on one or more configured parameters in the SL radio bearer and / or buffer status associated with one or more SL radio bearers for which unlicensed operation is allowed and / or the maximum CBR on any of the selected licensed carriers. Based on the determination 215, the TX WTRU selects 220 some licensed carriers and some unlicensed carriers for the destination. The TX WTRU may then transmit 225 data on each of the selected carriers toward the L2 destination ID.

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

[0084] The carrier (re)selection behavior may be similar to legacy LTE V2X. Specifically, the SL WTRU may do any of the following: (i) for each HARQ process, trigger carrier (re)selection based on certain conditions related to resource (re)selection, (ii) for each L2 destination ID, select several carriers to transmit on from the carriers configured for each L2 destination ID, (iii) for each HARQ process, select resources independently on each carrier, (iv) for a given grant on a carrier, perform a logical channel prioritization (LCP) procedure taking into account the L2 destinations allowed on the carrier, and / or (v) transmit medium access control (MAC) packet data units (MPDUs) on the carrier.

[0085] Carrier (Re)Selection Condition Considerations for Licensed or Unlicensed Carriers. In one family of solutions, the WTRU may perform carrier (re)selection by separately considering licensed and unlicensed carriers. WTRU actions related to carrier (re)selection may include any one or combination of determining: (i) the number of carriers to select; (ii) the number of carriers of a given type to select; (iii) whether the selected carriers include carriers of a given type; (iv) when / whether to trigger carrier (re)selection; (v) whether to select carriers of one type before another; and / or (vi) whether to prioritize carriers of one type (e.g., licensed) over carriers of another type (e.g., unlicensed).

[0086] Taking into account the type of carrier (e.g., licensed vs. unlicensed) during carrier (re)selection may include any of the following when making the above determination: making the determination differently (e.g., using different conditions herein) when the carrier is licensed compared to unlicensed; taking into account the type of currently selected carrier (licensed or unlicensed) when making the determination (e.g., based on certain conditions herein being met); and / or making the determination using different conditions or different factors, possibly using the conditions herein, when checking the conditions to make the determination.

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

[0088] The conditions for the bearer configuration may include whether the bearer or logical channel is explicitly configured for some behavior, how the WTRU receives the 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 a SL bearer, and / or whether the bearer is a default bearer.

[0089] The conditions for the configuration of a resource pool may encompass any factors related to the PHY channels configured for that resource pool / carrier, such as whether a PHY channel (e.g., physical sidelink feedback channel (PSFCH)) is configured or the amount / density of the configured PSFCH.

[0090] The QoS considerations may relate to any conditions associated with parameters related to the QoS of a particular bearer, such as logical channel (LCH) priority, reliability, maximum bit rate (MBR) or guaranteed bit rate (GBR), and / or prioritized bit rate, as the case may be.

[0091] The cast type may include any conditions associated with whether the WTRU is transmitting by unicast / groupcast / broadcast such that at least one sidelink radio bearer (SLRB) is established for a particular type of cast, the WTRU's transmission is for a particular cast, and / or the amount of data available for transmission for a particular cast is above a threshold.

[0092] Conditions related to modulation coding rate (MCR) may include any condition related to the value of the MCR (e.g., compared to a threshold), whether the MCR is configured, or the difference in MCR between two transmissions / bearers.

[0093] Conditions related to HARQ feedback enablement / disablement may include whether the LCH has HARQ feedback enabled / disabled, whether the transmission has HARQ feedback enabled / disabled, and / or whether the WTRU is configured with HARQ resources (e.g., PSFCH, physical uplink control channel (PUCCH), etc.).

[0094] Conditions related to LBT failure may include whether an LBT failure is declared, possibly over a period of time, possibly on a carrier or one or more resource block (RB) sets associated with the carrier, and / or the number of times, possibly consecutively, that an LBT failure has occurred, possibly on a carrier or one or more RB sets associated with the carrier.

[0095] Conditions related to channel busy ratio (CBR) may include the CBR being above or below a threshold, the CBR increasing / decreasing by a threshold amount, and / or the CBR of one carrier being above / below the CBR of another carrier, possibly by a 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 CR of one carrier being above / below the CR of another carrier, possibly by a configured amount.

[0097] Conditions related to a received signal strength indicator (RSSI) may include the RSSI being above or below a threshold, the 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 a particular embodiment, the WTRU determines whether to select at least one (or a configured number) of carriers of a certain type. In one solution, the WTRU may determine whether to select one (or a configured number, or a configured percentage of the total number available) of licensed / unlicensed carriers during carrier selection based on one or more of the conditions described above. For example, a SL WTRU may be configured with a threshold buffer status, possibly associated with one or more of its established sidelink radio bearers (SLRBs). During carrier selection, the WTRU may be allowed to select at least one (or at least N, where N may be pre-configured) unlicensed carriers if the buffer status at the time of carrier selection trigger is above a threshold.

[0099] In one example, the WTRU may trigger carrier (re)selection if the buffer status is below a threshold, possibly for a specified period of time, and the WTRU last selected (or is currently using) at least one (at least N) unlicensed carrier. Similarly, the WTRU may trigger carrier (re)selection if the buffer status is above a threshold, possibly for a period of time, and the WTRU last selected (or is not currently using) an unlicensed carrier, or last selected (or is currently using) fewer than N unlicensed carriers.

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

[0101] In an example embodiment, an SL WTRU may be configured with an indication in the SLRB configuration of whether a particular bearer allows selection of one or more unlicensed carriers. If the WTRU has such an SLRB established, the WTRU may select at least one (at least N) unlicensed carrier. 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 carrier. For example, an SL WTRU may be configured with an indication in the SLRB configuration of a preferred carrier type. The WTRU may select at least one unlicensed / licensed carrier if all / a configured number / zero of the SLRB configurations indicate that unlicensed / licensed is preferred.

[0102] In another example embodiment, a SL WTRU may be configured with a threshold guaranteed bit rate (GBR), prioritized bit rate (PBR), maximum bit rate (MBR), or similar QoS parameter related to data rate. If the WTRU has established SLRBs whose (possibly total) configured value of the QoS profile exceeds a threshold, the WTRU may select at least one (at least N) unlicensed carrier.

[0103] As another example, the SL WTRU may be configured with an RSSI threshold, or alternatively, a similar threshold related to measuring the amount of WiFi activity on unlicensed carriers. Such a threshold may be configured per SLRB. If the number of unlicensed carriers with measured RSSI below the threshold exceeds a carrier count threshold, the WTRU may select at least one (at least N) unlicensed carrier.

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

[0105] Next, an embodiment of TX WTRU operation on multiple carriers will be described. In SL, especially in unicast, unlicensed carriers may only be used for certain traffic types or situations (e.g., large amounts of traffic without strict timing requirements). Configuring DRX groups using the legacy DRX group mechanism and having the RX WTRU monitor SL for all carriers is power inefficient. Therefore, the following embodiment may provide a more efficient option.

[0106] In a first exemplary embodiment, the WTRU performs an initial transmission on a first carrier (anchor carrier) and only performs subsequent transmissions on other carriers following an acknowledgement of the first transmission.

[0107] 3, an example method 300 for TX WTRU operation on multiple carriers is shown. The SL TX WTRU may establish a unicast link with a peer WTRU (RX WTRU) 305 and configure 310 several 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 to the RX WTRU (e.g., in PC5-RRC). The SL TX WTRU selects 315 an SL DRX configuration (e.g., DRX cycle, on duration, inactivity time, etc.) and sends the DRX configuration to the RX WTRU.

[0108] If the inactivity timer at the RX WTRU is not running when data arrives for transmission to the RX WTRU 320, the SL TX WTRU may perform a first data transmission to the RX WTRU on the anchor carrier during the RX WTRU's active time 325 and may include as part of the transmission (e.g., in the sidelink control information (SCI)) an indication of the carrier intended to be used during this active period. Upon receiving a HARQ ACK for the first transmission from the RX WTRU, the TX WTRU begins subsequent transmissions on the carrier indicated in the first transmission 330 and resets the inactivity timer after transmissions on the anchor and non-anchor carriers.

[0109] If the inactivity timer in the RX WTRU is running when data arrives for transmission to the RX WTRU 320, the TX WTRU may perform data transmission 335 on all carriers indicated by the last carrier transmission indicator on the anchor carrier.

[0110] In a particular embodiment, the WTRU determines the allowed carrier for transmission when licensed and unlicensed carriers are available. In one family of solutions, the WTRU may perform transmissions on multiple carriers, possibly associated with one or more L2 IDs, by considering licensed and unlicensed carriers separately. WTRU actions related to transmissions may include any one or combination of determining: (i) whether data may be transmitted on a carrier; (ii) the set / number of carriers to use for the LCH, L2 ID, or associated set of transmissions; (iii) whether to prioritize one type of carrier over another type of carrier when determining which carrier to transmit on; (iv) whether to include a given type of carrier in the set of carriers to use for the LCH, L2 ID, or associated set of transmissions; and / or (v) when / whether to perform retransmissions on a different carrier compared to the transmission.

[0111] Taking into account the type of carrier (e.g., licensed or unlicensed) during transmission may include any of the following when making the above determination: (i) making the determination differently (using different conditions herein) when the carrier is licensed compared to unlicensed; (ii) taking into account the type of currently selected carrier (licensed or unlicensed) when making the determination (e.g., based on certain conditions herein being met); and / or (iii) making the determination using different conditions or different factors when checking the conditions to make the determination, possibly using the conditions herein.

[0112] In one embodiment, the TX WTRU may select SL resources (or be given an SL grant) on a licensed or unlicensed carrier. The WTRU may determine whether a transmission may occur on a licensed or unlicensed carrier based on the rules / conditions herein. This may be achieved via a logical channel prioritization (LCP) policy or procedure. For example, the WTRU may exclude certain logical channels (LCHs) or transmissions from being performed on a carrier or on a grant associated with the carrier.

[0113] A WTRU may be configured with certain conditions for enabling transmission on a carrier or for restricting certain transmissions. Such conditions may be used, for example, to determine whether a WTRU can perform transmissions on a licensed or unlicensed carrier. Such conditions may be used, for example, to determine whether two related transmissions can occur on licensed / unlicensed, on the same / different carrier type, and / or on carriers with the same / similar configuration in terms of resource pool or carrier characteristics.

[0114] The conditions associated with the data to be transmitted on the carrier may relate to bearer configuration, QoS, transmission pattern, cast type of transmission, MCR, enable / disable HARQ feedback, and / or any of the time-based conditions described herein.

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

[0116] The QoS conditions may include any conditions associated with parameters related to the QoS of a particular bearer, such as priority, reliability, bit rate (e.g., MBR, GBR), and / or prioritized bit rate (PBR) of the LCH.

[0117] The transmission pattern conditions may include whether the transmission is periodic or a one-shot transmission.

[0118] The cast type of the transmission may include any conditions associated with whether the WTRU is transmitting unicast / groupcast / broadcast, such as the WTRU having at least one SLRB established for the particular cast, the WTRU's transmission being for the particular cast, and / or the amount of data available for transmission for the particular cast being above a threshold.

[0119] MCR-related conditions may include conditions related to the value of the MCR (e.g., compared to a threshold), whether the MCR is configured, or the difference in MCR between two transmissions / bearers.

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

[0121] Time-based conditions may include the time elapsed since the occurrence of an event, such as an event associated with another condition, e.g., time since consistent LBT failure, time since CBR has risen / fallen above a threshold, possibly associated with another condition, and / or time since last transmission.

[0122] Conditions related to the carrier itself may be conditions related to (i) the resource pool configuration, (ii) the DRX behavior of the RX WTRU on that carrier, (iii) LBT failure, (iv) CBR, (v) CR, (vi) RSSI, and / or (vii) the number of selected carriers, as described in the example below.

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

[0124] The DRX behavior of the RX WTRU on that carrier, with conditions related to DRX, including whether the RX WTRU is in a DRX state on that carrier and / or the DRX pattern for that carrier.

[0125] Conditions related to LBT failure may include whether an LBT failure is declared, possibly over a period of time, possibly on a carrier or one or more RB sets associated with the carrier, and / or the number of times, possibly consecutively, that an LBT failure has occurred, possibly on a carrier or one or more RB sets associated with the carrier.

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

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

[0128] RSSI-related conditions may include RSSI being above or below a threshold, RSSI increasing / decreasing by a threshold amount, and / or 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 selected carriers may include the number of selected unlicensed / licensed carriers being above / below a threshold, at least one licensed / unlicensed carrier being selected, and / or the total number of selected carriers being above / below a threshold.

[0130] Certain example embodiments may be based on carrier restriction. For example, a WTRU may be configured with a threshold priority of data. If the number of licensed carriers selected by the WTRU is above the threshold, the WTRU may restrict data transmissions above a threshold (higher priority) to be performed on licensed carriers. For example, a WTRU may be configured with a threshold PBR. If the number of unlicensed carriers selected by the WTRU is above the threshold, the WTRU may restrict data from logical channels with PBR above the threshold to be performed on unlicensed carriers. As another example, if the number of licensed carriers selected by the WTRU is above the threshold, the WTRU may restrict data transmissions with HARQ feedback enabled to be performed on licensed carriers.

[0131] In one example embodiment, if the WTRU selects at least one licensed carrier, the WTRU may restrict MCR-configured data to be executed on the licensed carriers. In another example, if the WTRU selects at least one licensed carrier, the WTRU may restrict broadcast data to be executed on the licensed carriers where HARQ feedback is enabled and multiple HARQ feedback resources are configured for different WTRUs in the group.

[0132] In a particular embodiment, the WTRU may be configured with a threshold priority, and if at least one unlicensed carrier is selected for data above the threshold priority (higher priority), the WTRU may exclude transmission of such data on carriers on which, for example, LBT failures, consistent LBT failures, and / or the number of LBT failures exceeds a threshold, etc., occurred within the last X seconds (X may be configurable by the network).

[0133] In another example, a WTRU may perform periodic transmissions only on licensed bands and may be allowed to perform one-shot (ie, single) transmissions on either licensed or unlicensed carriers.

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

[0135] The TX WTRU may restrict its first transmission to a particular carrier (e.g., an anchor carrier). In a particular example, the anchor carrier may be predefined or (pre-)configured. For example, each TX WTRU configured for transmission to an L2 ID may possibly have an anchor carrier associated with the L2 ID. For example, when a TX WTRU performs a first transmission to an L2 destination ID, the WTRU may transmit on the anchor carrier associated with the L2 ID. In another example, the anchor carrier may be selected by the TX WTRU or the RX WTRU and configured between the two WTRUs (e.g., via PC5-RRC signaling). For example, the TX WTRU may perform anchor carrier selection based on one or a combination of the following factors: SL measurements (e.g., CBR, CR, RSRP, RSSI, etc.). For example, the TX WTRU may be configured with a threshold CBR and / or threshold CR and / or threshold RSRP and may select the anchor carrier from among the carriers whose corresponding measurements are above / below the threshold. The TX WTRU may select the anchor carrier as the carrier with the lowest CBR, lowest CR, largest SL RSRP, lowest RSSI, etc. Licensed / unlicensed basis. For example, the TX WTRU may select the anchor carrier from among only licensed carriers. LBT failure status / statistics. For example, the TX WTRU may select as the anchor carrier the carrier with the fewest LBT failures, possibly the carrier with consistent LBT failures pending over a period of time, etc. Carrier configuration. For example, the TX WTRU may select an anchor carrier from among 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 certain embodiments, in some cases, the first transmission to the anchor carrier may be limited in time. Specifically, the TX WTRU may limit the first transmission to the on duration of the peer WTRU in DRX. Specifically, the TX WTRU may limit the first transmission to the active time of the RX WTRU.

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

[0138] Alternatively, in some cases, 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 the unlicensed spectrum.

[0139] Whether the WTRU is performing the first transmission may be determined by the status of a timer. Such a timer may be controlled by a previous transmission and / or a corresponding acknowledgment for the previous transmission. For example, the TX WTRU may restart an inactivity timer upon transmission to the RX WTRU. As long as the inactivity timer is running, the TX WTRU may perform a transmission corresponding to the condition associated with the subsequent transmission. If the inactivity timer expires, the TX WTRU may perform a transmission corresponding to the condition for the first transmission.

[0140] Additionally, the first transmission, possibly performed on an anchor carrier, may provide information regarding the subsequent transmission, including (i) the carrier on which the subsequent transmission may be performed, (ii) an inactivity time (i.e., time associated with an action related to the subsequent transmission), (iii) whether the initial transmission is followed by a subsequent transmission, and / or (iv) information regarding the subsequent transmission.

[0141] The information on whether the initial transmission is followed by a subsequent transmission may specify, for example, that if the initial transmission is not followed by a subsequent transmission, the next transmission by the TX WTRU is considered the first transmission and is made using the characteristics herein associated with the first transmission. Alternatively, for example, if the initial transmission is followed by a subsequent transmission, the next transmission (as long as it occurs within the inactivity time) is performed using the characteristics associated with the subsequent transmission. The information regarding the subsequent transmission may be included in a MAC CE, MAC header, SCI, or RRC message included in the initial transmission.

[0142] An example follows in which a WTRU performs a subsequent transmission based on information included in a first transmission. In one example, following the initial transmission, the WTRU may perform the subsequent transmission using characteristics associated with the subsequent transmission. Such characteristics may have been provided to the peer WTRU. For example, the WTRU may perform the subsequent transmission on any of the carriers indicated to the peer WTRU in the initial transmission.

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

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

[0145] In some embodiments, the WTRU restricts certain transmissions to the anchor carrier and / or 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 conditions associated with the data (described herein) to determine whether to restrict such data transmissions to the anchor carrier.

[0146] Next, an embodiment for resource selection for multi-carrier with licensed and unlicensed carriers will be described. In one exemplary embodiment, when a WTRU performs several transmissions for a particular QoS, it jointly selects initial and backup resources on the unlicensed and licensed carriers, respectively.

[0147] 4, an example method 400 for multi-carrier resource selection using licensed and unlicensed carriers is shown. The SL TX WTRU may be configured 405 with multi-carrier across both licensed and unlicensed carriers, with one or more bearers for transmission to a destination that is configured to enable or not enable backup resource selection.

[0148] When data arrives for a bearer that enables backup resource selection, the WTRU performs a joint resource (re)selection procedure on the licensed and unlicensed carriers such that a first available resource is selected on the unlicensed carrier at time t1 and a second available resource is selected on the licensed carrier at time t2 that is later (by an amount up to the WTRU) than t1, where t1 and t2 are within a resource selection window 410. The WTRU may perform an LBT for transmission on the first resource 415, and if the LBT fails 420, transmits the data on the second resource 425. Otherwise, the WTRU transmits the data on the first resource 430 and includes information about the second resource in the transmission.

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

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

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

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

[0153] The conditions for joint resource selection may depend on measurements (CBR, CR, RSRP, RSSI, LBT failure statistics, etc.) for the carrier itself, or for all available carriers, or for a selected carrier. For example, the WTRU may perform joint resource selection when the RSSI of all / selected / specific, possibly unlicensed, carriers is above a threshold. In another example, the WTRU may perform joint resource selection when the CBR of all / selected / specific, possibly licensed, carriers is below a threshold. In another example, the WTRU may perform joint resource selection when (consistent) LBT failures on all / selected / specific unlicensed carriers exceed a threshold for a certain period of time. Finally, the ability of peer WTRUs to support joint resource selection by the TX WTRU may also be a condition for joint resource selection.

[0154] Considerations for resource selection are disclosed. In various embodiments, the WTRU may be configured with conditions regarding the resources selected on each of the carriers. Specifically, the WTRU may be configured with conditions regarding resource size. In one example, the WTRU may select two resources of the same size. In one example, the difference in resource size should be smaller / larger than a configured threshold. The size of the second resource (or the size difference between the first and second resources) may 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, configuring the (maximum) size of the second resource based on a measurement value of the first resource (e.g., RSSI, CBR, CR, etc.) or based on a measure of occupancy of an unlicensed channel used when selecting the first resource (e.g., number of LBT failures, etc.). In one example, the (maximum) size of the second resource may depend on a carrier frequency difference between the first carrier and the second carrier.

[0156] The conditions associated with the data QoS may include, for example, that the size difference between the first resource and the second resource may be configured based on the priority of the highest priority LCH having data available for transmission that triggered the resource selection.

[0157] The WTRU may further be configured with conditions regarding the timing of the first resource and the second resource. Such conditions may specify a minimum / maximum time difference between the first resource and the second resource and may specify an allowable time window for both the first resource and the second resource. Specifically, when using the sensing result to select two resources, the WTRU should select an available resource that meets the condition for the first resource. For example, the PHY layer may provide all available resources to the MAC layer, and the MAC layer may select a resource that meets certain time conditions disclosed herein. For example, the WTRU may determine the timing of the resources based on the WTRU capabilities, the data QoS / priority / packet delay budget (PDB), the channel access priority class (CAPC) (or other similar LBT requirements), the HARQ round trip time (RTT), and / or whether HARQ feedback is enabled / disabled, the type of carrier (e.g., licensed or unlicensed) associated with the first / second resource, and / or measurements of the first and / or second carrier. An example is as follows: The WTRU capabilities may be used to determine the minimum time difference between the first resource and the second resource. - QoS / priority / PDB of the data. For example, the first and second resources should both be within the time window defined by T2 (i.e., the PDB associated with the data that triggered the resource selection). The data CAPC (or other similar LBT requirements), e.g., the minimum time difference between the first resource and the second resource, may be determined by the data CAPC. Specifically, the second resource should enable the WTRU to perform LBT on the first carrier, and only when the LBT fails can the WTRU perform transmission on the second resource associated with the second carrier. The time required to determine an LBT failure may depend on the data CAPC, the LBT requirements, etc. HARQ RTT and / or whether HARQ feedback is enabled / disabled. For example, the minimum time difference between the first resource and the second resource may depend on factors that determine the HARQ RTT, such as the 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, the WTRU may use different values ​​of T2 (derived from the PDB) depending on whether the second carrier is licensed or unlicensed. And / or Measurements of the first and / or second carrier. For example, the WTRU may use different values ​​of T2 (derived from the PDB) depending on the CBR of the second carrier. For example, the RSSI of the first carrier may be used to determine the minimum / maximum time difference between resources on the first and second carrier.

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

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

[0160] If the LBT is successful on the first resource, in one solution, the WTRU may not perform transmission on the second resource if the LBT is successful on the first resource. The WTRU may send an indication of the first resource together with an indication of the time / frequency location of the second resource (e.g., in the SCI) when transmitting. 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 transmission of the second TB. The WTRU may indicate the occupancy of the second resource (e.g., in the SCI) when transmitting on the first resource. The WTRU may be configured with a condition regarding whether to utilize the second resource if the LBT / transmission is successful on the first resource. For example, such a condition may be based on one or a combination of the following: (1) QoS of data available for transmission. For example, if the WTRU has data available for transmission (after performing transmission on the first resource) with priority above a threshold, the WTRU may use the second resource for transmission of a new TB. (2) Availability of control information or inter-WTRU coordination information. In one example, if a WTRU has inter-UE coordination (IUC) information, the WTRU may use the second resource to transmit the IUC information. In one example, if the WTRU has CQI information pending for transmission, the WTRU may use the second resource for transmission of the IUC information. In another example, the WTRU may use the second resource to opportunistically transmit any pending control information intended for a peer WTRU. (3) Buffer Status: In one example, if the WTRU's buffer occupancy is above a threshold, possibly for a particular logical channel, the WTRU may use the second resource. (4) Prioritized Bit Rate (PBR): In one example, if the WTRU has at least one LCH with Bj>0, the WTRU may use the second resource for transmission of the new TB. (5) Availability of Grants: As an example, the WTRU may use a second resource for transmission of a new TB, possibly if it does not have another grant within a certain time window.

[0161] Next, an embodiment for carrier-specific SL Radio Link Failure (RLF) based HARQ counting will be described. Legacy SL Radio Link Failure (RLF) is designed for a single carrier. One problem with HARQ-based counting in unauthorized situations is that existing mechanisms cannot distinguish whether HARQ DTX is due to a decoding failure or an LBT failure at the RX WTRU. Using the authorized carrier for information about the HARQ DTX count of unauthorized carriers can help solve 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 reset MAC CE) received from the RX WTRU.

[0162] Referring to FIG. 5, an example method 500 for determining a carrier-specific SL RLF for an unlicensed carrier based on feedback information on a licensed carrier is shown. An SL TX WTRU establishes a unicast link with a peer WTRU 505 and may select multiple licensed and / or unlicensed carriers for communication. Independent counting of HARQ DTX (i.e., a separate counter per carrier) is performed on each carrier (licensed and unlicensed) 510. A message (e.g., a MAC CE) indicating reception information on one or more unlicensed carriers, e.g., whether a TB has been received for an unlicensed carrier, is received from the RX WTRU on the licensed carrier 515. Upon receiving the message, the WTRU may modify the consecutive number of HARQ DTXs on the indicated carrier(s) 520. For example, the TX WTRU may reset the consecutive number of HARQ DTXs or subtract a value (e.g., indicated in the MAC CE) from the current count of consecutive HARQ DTXs based on the information in the received message. If the number of consecutive HARQ DTXs on a carrier reaches a threshold 525, the WTRU may indicate 530 a carrier-specific SL RLF for that carrier to the network.

[0163] In various embodiments, the WTRU transmits / receives unlicensed carrier information on a licensed carrier. In one family of solutions, the WTRU may receive / transmit LBT-related information or channel access-related information for an SL unlicensed carrier on an SL licensed carrier. Specifically, the WTRU may receive information on an LBT failure, buffer status, channel occupancy time (COT) information, etc., on a licensed carrier, which represents information about access or transmission related to the unlicensed carrier. Similarly, based on certain triggers related to channel access on an unlicensed carrier, the WTRU may transmit information about access on the unlicensed carrier in an SL message on the licensed carrier. A WTRU receiving such information may use the information to update counters, timers, resource allocations, and / or modify channel access on unlicensed or licensed spectrum.

[0164] The information related to the unlicensed spectrum referred to above may include one or a combination of any of the following: (1) LBT Status. As an example, the WTRU may transmit a message on a licensed carrier indicating an LBT failure, consistent LBT failure, or similar information associated with one or more unlicensed carriers. (2) HARQ Feedback Failure Status. In various examples, the WTRU may transmit a message on the licensed carrier indicating a failure to transmit a HARQ ACK / NACK on the unlicensed spectrum due to an LBT failure. As an example, the WTRU may transmit a message on the licensed carrier to send HARQ feedback on the unlicensed spectrum upon failing to access the channel. In another example, the WTRU may transmit a message on the licensed carrier after "X" (a configured value) consecutive LBT failures associated with transmitting HARQ feedback. In one example, the WTRU may indicate in the message the number of consecutive LBT failures associated with the HARQ feedback. (3) Buffer Status Information: According to one example, the WTRU may transmit a message on a licensed carrier indicating the priority / CAPC / amount / L2 destination ID of data available for transmission that can be sent (and has not yet been transmitted) on an unlicensed carrier. (4) Channel Occupancy Measurements. In some examples, the WTRU may transmit a message containing measurements of channel occupancy of the unlicensed spectrum, such as RSSI (possibly per RB set), CR, CBR, percentage of time during which SCI from other WTRUs may be detected, etc. In one example, the WTRU may perform measurements of the channel that indicate the percentage of time the RSSI is above a threshold (i.e., an indication that the channel is occupied by WiFi transmissions) without detecting SCI. (5) Channel Occupancy Time (COT) Information. In one example, upon receiving / detecting COT information received on an unlicensed carrier, the WTRU may send a message and the contents of the COT information (e.g., COT length, CAPC, L2 destination ID, etc.).

[0165] According to various embodiments, the WTRU may use the received LBT failure information to manage SL RLF detection. In one solution, the WTRU may use a message from a peer WTRU on the licensed spectrum to update the HARQ DTX count for the SL RLF on the unlicensed spectrum. For example, upon receiving a message on a licensed carrier indicating an unlicensed carrier, the TX WTRU may reset the number of consecutive HARQ DTX counters for the SL RLF on that carrier. In one example, upon receiving a message on a licensed carrier indicating an unlicensed carrier, the WTRU may subtract, up to a (pre-)configured amount, from the number of consecutive HARQ DTX counters for the SL RLF on that carrier. In one example, upon receiving a message on a licensed carrier indicating an unlicensed carrier and value, the WTRU may subtract, up to the received value, from the number of consecutive HARQ DTX counters for the SL RLF on that carrier. In one example, upon receiving a message on a licensed carrier indicating to enable / disable / suspend / resume HARQ DTX counting for the SL RLF, the WTRU may enable / disable / suspend / resume HARQ DTX counting for the SL RLF on the indicated unlicensed carrier.

[0166] In a particular embodiment, the WTRU uses the received COT / BSR information for scheduling. In one family of solutions, the WTRU may use the received COT / BSR information to schedule transmissions on unlicensed spectrum. In one solution, the WTRU may perform resource selection using COT information received on licensed carriers from peer WTRUs. Specifically, the WTRU may use information about the COT duration to select resources that fall within the COT.

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

[0168] In another solution, the WTRU may use buffer status information received on the licensed carrier to determine logical channel prioritization (LCP) behavior during transmission on the unlicensed spectrum. For example, if the BSR information indicates data associated with a particular priority, the WTRU receiving the BSR may include the data in a logical channel associated with the same / higher / lower priority than the particular priority.

[0169] In yet another solution, the WTRU may use buffer status information received on the licensed carrier to determine the CAPC to use to access the channel for creating the shared COT. Specifically, the WTRU may use either the priority of the data in its own buffer or the priority of the 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 particular priority (possibly higher than the priority associated with any data in the transmitting WTRU's buffer), the WTRU may use the CAPC associated with the peer WTRU's BSR information rather than its own information.

[0170] Next, an embodiment for SL RLF in multi-carrier with licensed and / or unlicensed carriers is described. The legacy SL RLF based on HARQ feedback is designed for a single carrier. In the multi-carrier case, the SL RLF may be per carrier and / or per link, which may depend on the reciprocity between the carriers. According to one example embodiment, the WTRU triggers the SL-RLF, releases the unicast link, and notifies the network when the resource selection fails to find at least one licensed / unlicensed carrier that meets the CBR threshold. In another example embodiment, the WTRU determines carrier-specific RLF for licensed or unlicensed carriers in a multi-carrier SL with a peer WTRU based on the number of consecutive DTX counts for a particular carrier exceeding a threshold DTX count, and reselects a new carrier excluding the carrier previously determined using the carrier-specific RLF; the TX WTRU may release the multi-carrier link with the RX WTRU only when there are no remaining carriers that have not been determined using the carrier-specific RLF.

[0171] 6, an example method 600 for determining a carrier-specific SL RLF and / or link failure based on configured CBR thresholds is shown. The SL TX WTRU may be configured 605 with a first CBR threshold for a licensed carrier and a second CBR threshold for an unlicensed carrier, as well as a time period for avoiding carrier selection after a carrier-specific SL RLF. The TX WTRU establishes 610 a unicast link with a peer WTRU and selects multiple licensed and / or unlicensed carriers for communication.

[0172] Upon a carrier-specific SL RLF occurring on a single carrier, carrier (re)selection 615 may be triggered, with some SL carriers selected on licensed bands whose CBRs are below a first threshold and some carriers selected on unlicensed bands below a second threshold, and the duration between the triggering of carrier (re)selection and the last carrier-specific SL RLF for this unicast link exceeds a (pre-)configured duration threshold. If the SL TX WTRU is unable to select at least one carrier supported by the RX WTRU 620, an SL-RLF is triggered 630, the unicast link is released, and the network is notified. Otherwise, the SL TX WTRU selects some carriers 625 and continues operation of the unicast link using the selected carriers.

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

[0174] Referring to FIG. 7, a method 700 for determining a carrier-specific SL RLF based on HARQ DTX is shown. The TX WTRU may establish a unicast link with the RX WTRU using multiple SL carriers, e.g., licensed and / or unlicensed carriers 705. The TX WTRU transmits information to the RX WTRU using at least a first SL carrier of the multiple SL carriers 710. 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 an SL carrier reselection procedure is initiated by the TX WTRU 725. If there are no remaining SL carriers of the multiple carriers that have not been determined using the carrier-specific RLF 730, the TX WTRU releases 735 the unicast link with the RX WTRU. If not 730, a second SL carrier is selected 740 from the plurality of carriers, and the TX WTRU indicates the carrier-specific RLF of the first carrier to the RX WTRU 745, and a unicast link with the RX WTRU is maintained 750. In one particular configuration, in step 745, the TX WTRU may additionally indicate the selected second SL carrier to the RX WTRU.

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

[0176] In some embodiments, a WTRU may trigger a carrier-specific SL RLF after receiving a DTX or an indication of a carrier-specific SL RLF from a peer WTRU, eg, received on another carrier.

[0177] Actions upon Triggering a Carrier-Specific SL RLF: The WTRU may perform any one or a combination of the following actions upon triggering a carrier-specific SL RLF. (1) Suspend use of the carrier. In one example, the RLF-determined carrier is no longer considered available as a selected carrier. Alternatively, the carrier may still be considered a selected carrier, but the WTRU may not select / receive any grants on the carrier. (2) Start a carrier inhibit timer associated with (re)selecting a carrier or transmitting on a carrier. In one example, the WTRU may start a timer associated with the failed carrier. While the timer is running and has not expired, the WTRU cannot select a carrier during the carrier selection procedure. The WTRU may start the carrier inhibit timer after receiving an indication from a peer WTRU (received on another carrier) or as a result of a carrier-specific SL RLF on the carrier. In various embodiments, the WTRU may be configured with different carrier inhibit timers for licensed and unlicensed spectrum. (3) Trigger Carrier Reselection. The WTRU may initiate a carrier reselection procedure as discussed in step 725 of FIG. 7. The WTRU may be configured with conditions related to when a carrier-specific SL RLF triggers carrier reselection. For example, carrier reselection may be performed if the carrier that triggered the SL-RLF has a CBR below a threshold, if the number of remaining (selected) carriers that may have a CBR below the threshold is below a threshold number of carriers, if the conditions discussed herein related to the number of selected licensed / unlicensed carriers are not met, and / or if the carrier that triggered the SL-RLF has the lowest CBR of all selected carriers. (4) Inform the peer WTRU of the SL-RLF on the carrier by sending a message on another carrier.

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

[0179] SL RLF triggered based on counting across multiple carriers. In one solution, the WTRU may be configured to perform HARQ DTX counting jointly across some / all carriers. For example, a subset of carriers may be configured as associated carriers in the SL WTRU. In such a case, the SL WTRU may count HARQ DTX jointly across those associated carriers. For example, the associated carriers may be explicitly configured (e.g., in RRC signaling) or may be implicitly determined (e.g., based on a pool configuration or PSFCH configuration). For example, a carrier that allows cross-carrier PSFCH transmission may be considered an associated carrier from the HARQ DTX counting point of view for SL RLF determination.

[0180] In another solution, the WTRU may count the HARQ DTX differently across multiple carriers. Specifically, when counting the HARQ DTX across multiple carriers, the WTRU may do one of the following: (1) The WTRU may consider multiple HARQ DTXs as a single instance (or increment a counter by 1). The WTRU may perform such behavior based on conditions associated with the relative timing of 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 slots of each other, the HARQ DTX associated with both resources is counted only once. (2) The WTRU may be configured with different values ​​of the maximum number of HARQ DTXs for triggering an SL RLF based on the number of carriers with a common count across carriers and / or whether cross-carrier HARQ feedback is configured, as well as 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 (or a subset) or associated carriers. For example, the counter is reset only if the WTRU successfully decodes the PSFCH on two of the N carriers for which common counting is performed.

[0181] When an SL RLF is triggered for a set of carriers on which counting is performed together, the WTRU may (i) stop using all carriers for a certain period of time, (ii) use only the carrier on which the majority of HARQ DTXs have been counted, and / or (iii) stop using different carriers in the set for different amounts of time, specifically based on the number of consecutive HARQ DTXs counted on that carrier.

[0182] While features and elements are described above in particular combinations, those skilled in the art will understand that each feature or element can be used alone or in any combination with the other features and elements. Additionally, the methods described herein may be implemented in a computer program, software, or firmware embodied 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, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. 1. A method for a wireless transmit / receive unit (WTRU), comprising: Establishing a unicast link with a peer WTRU that enables the use of multiple side link (SL) carriers; transmitting data to the peer WTRU on at least a first SL carrier of the plurality of SL carriers; determining a carrier-specific SL radio link failure (RLF) of the first SL carrier based on a number of consecutive hybrid automatic repeat request (HARQ) discontinuous transmissions (DTXs) ​​detected on the first SL carrier exceeding a threshold HARQ DTX count; performing an SL carrier reselection procedure to select a second SL carrier from the plurality of SL carriers, excluding the SL carrier determined using the carrier-specific SL RLF, based on the determined carrier-specific SL RLF of the first SL carrier; and transmitting, on one of the plurality of SL carriers that does not have a carrier-specific SL RLF, an indication of the carrier-specific RLF of the first SL carrier to the peer WTRU.

2. If the SL carrier reselection procedure fails because all carriers have carrier-specific SL RLF, the method further comprises: The method of claim 1 , further comprising releasing the unicast link with the peer WTRU.

3. 3. The method of claim 1, wherein the unicast link comprises a Vehicle-to-Everything (V2X) Carrier Aggregation (CA) sidelink.

4. The method of any one of claims 1 to 3, wherein the plurality of SL carriers comprises carriers in a 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 sent using a PC5 Radio Resource Control (RRC) message.

6. 1. A wireless transmit / receive unit (WTRU), comprising: a transceiver; and a processor in communication with the transceiver, wherein the transceiver and the processor: Establishing a unicast link with a peer WTRU that enables use of multiple (SL) carriers; transmitting data to the peer WTRU on at least a first SL carrier of the plurality of SL carriers; determining a carrier-specific SL radio link failure (RLF) of the first SL carrier based on a number of consecutive hybrid automatic repeat request (HARQ) discontinuous transmissions (DTXs) ​​detected on the first SL carrier exceeding a threshold HARQ DTX count; performing an SL carrier reselection procedure to select a second SL carrier from the plurality of SL carriers, excluding the SL carrier determined using the carrier-specific SL RLF, based on the determined carrier-specific SL RLF of the first SL carrier; The WTRU is configured to transmit, on one of the plurality of SL carriers that does not have a carrier-specific SL RLF, an indication of the carrier-specific RLF of the first SL carrier to the peer WTRU.

7. If the SL carrier reselection procedure fails due to all carriers having carrier-specific SL RLF, the processor and transceiver: The WTRU of claim 6 , further configured to release the unicast link with the peer WTRU.

8. 8. The WTRU of claim 6 or 7, wherein the unicast link comprises a Vehicle-to-Everything (V2X) Carrier Aggregation (CA) sidelink.

9. The WTRU of any one of claims 6 to 8, wherein the plurality of SL carriers comprises carriers in a 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 sent using a PC5 Radio Resource Control (RRC) message.

11. 1. A method for a wireless transmit / receive unit (WTRU), comprising: sending radio resource control (RRC) configuration signaling to a peer WTRU on a PC5 link to establish multi-carrier vehicle-to-everything (V2X) sidelink (SL) communication with the peer WTRU using multiple SL carriers in a licensed spectrum; monitoring hybrid automatic repeat request (HARQ) feedback from the peer WTRU to detect a number of consecutive discontinuous transmissions (DTX) on a first SL carrier used to transmit data to the peer WTRU; determining a carrier-specific SL RLF for the first SL carrier based on the detected number of consecutive HARQ DTXs on the first SL carrier exceeding a configured HARQ DTX count threshold; determining, based on the determined carrier-specific SL RLF of the first SL carrier, whether any SL carrier among the plurality of SL carriers that has not been determined using a carrier-specific SL RLF is available; Subject to an available SL carrier being determined, selecting the available SL carrier as a second SL carrier, continuing the multi-carrier V2X SL communication with the peer WTRU, and indicating the SL RLF of the first SL carrier to the peer WTRU; or and releasing the PC5 link with the peer WTRU on the condition that no available SL carrier is determined.

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

13. 1. A method for a receive (Rx) wireless transmit / receive unit (WTRU), comprising: Establishing a unicast link with a transmitting (Tx) WTRU and receiving configuration information that enables the use of multiple side link (SL) carriers; receiving data from the Tx WTRU on at least a first SL carrier of the plurality of SL carriers; sending, to the Tx WTRU, an indication of hybrid automatic repeat request (HARQ) feedback for the first SL carrier; receiving, from the Tx WTRU on a second SL carrier of the plurality of SL carriers, a carrier-specific SL Radio Link Failure (RLF) indication for the first SL carrier based at least in part on the sent HARQ feedback for the first carrier; continuing the unicast link with the Tx WTRU using at least a second SL carrier of the plurality of SL carriers that does not have a carrier-specific SL RLF.

14. The method of claim 13 , further comprising: releasing the unicast link with the Tx WTRU when a carrier-specific SL RLF indication is received for all of the plurality of SL carriers.

15. 15. The method of claim 13 or 14, wherein the unicast link comprises a Vehicle-to-Everything (V2X) Carrier Aggregation (CA) sidelink.

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

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

18. 18. The method according to any one of claims 13 to 17, wherein the indication of HARQ feedback for the first SL carrier is sent in a Physical Sidelink 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