JP2025531636A - SL RLF in multi-carrier including licensed and unlicensed - Google Patents

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 transmit 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 a number of detected consecutive hybrid automatic repeat request (HARQ) discontinuous transmissions (DTXs) 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

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.

Multicarrier is specified for the new radio (NR) sidelink (SL) in ^3rd generation partnership (3GPP) Release 18. 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 Rel18 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.

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 the uplink and downlink (i.e., the 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 carriers only. In SL multi-carrier, whether a problem on one carrier warrants a link-wide SL RLF determination may depend on the carriers themselves and/or, in some cases, whether they are licensed/unlicensed.

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.

In SL, especially unicast, unlicensed carriers may only be used for certain traffic types or situations (e.g., high volume traffic without strict timing requirements). Configuring DRX groups using legacy DRX group mechanisms and having RX UEs monitor SL for all carriers would be power inefficient.

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

Legacy SL RLF based on HARQ feedback is designed for single carrier only. In the multi-carrier case, SL RLF may be based 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.

In accordance with 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.

In one example, an SL TX WTRU may be configured with one or more thresholds, such as a prioritized bit rate, a buffer status threshold, a CBR threshold, etc., for determining whether to enable transmission on an unlicensed carrier for an SL radio bearer (SLRB). 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 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 several licensed and several unlicensed carriers for the destination; and (iv) transmitting data toward the L2 destination ID on each of the selected carriers.

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 buffer status associated with one or more SL radio bearers for which unlicensed operation is allowed, and/or 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 the 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.

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 acknowledgment of the first transmission.

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.

In one example, once the transmitted data arrives at the RX WTRU and 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 carrier and non-anchor carriers.

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.

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

In one example, an SL TX WTRU is configured with one or more bearers for transmission to a destination that is configured to enable multiple carriers on both licensed and unlicensed carriers and that either enable or disable backup resource selection. When data arrives for a bearer that enables backup resource selection, the TX WTRU may perform a joint resource (re)selection procedure on both licensed and unlicensed carriers.

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, 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.

According to an additional aspect of the present disclosure, a method is disclosed in which a WTRU resets carrier-specific SL-RLF HARQ DRX counters upon receiving a message (e.g., a reset MAC CE) from an RX WTRU.

In one example, an SL TX WTRU establishes a unicast link with a peer WTRU (i.e., an 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 from the RX WTRU indicating one or more unlicensed carriers. The TX WTRU modifies the number of consecutive HARQ DTXs on the indicated carrier(s). 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.

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 has not had a carrier-specific RLF within a given period, for example.

In one example, the SL TX WTRU is configured with a first CBR threshold for licensed carriers and a second CBR threshold for unlicensed carriers. The TX WTRU is also configured with a time period for avoiding carrier selection after a carrier-specific SL RLF. The SL TX WTRU establishes a unicast link with 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, and the TX WTRU selects some carriers on the licensed bands that have a CBR lower than the first threshold and some carriers on the unlicensed bands that are below 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.

In another solution, 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 carrier-specific RLF. The TX WTRU may provide an indication of SL RLF for the first carrier and/or the selected second SL carrier.

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 has not been 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.

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:
FIG. 1 is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented. 1B is a system diagram illustrating an exemplary wireless transmit/receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A, according to one embodiment. 1B is a system diagram illustrating an exemplary radio access network (RAN) and an exemplary core network (CN) that may be used within the communication system illustrated in FIG. 1A, according to one embodiment. 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. 1 is a flow diagram illustrating a method for selecting a carrier from among licensed and unlicensed carriers, according to one embodiment. 1 is a flow diagram illustrating a method of TX WTRU operation on multiple carriers according to one embodiment. 1 is a flow diagram illustrating a method of resource selection for multi-carrier having licensed and unlicensed carriers, according to one embodiment. 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; 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; 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;

FIG. 1A is a diagram illustrating an exemplary communications system 100 in which one or more disclosed embodiments may be implemented. Communications system 100 may be a multiple-access system that provides content, such as voice, data, video, messaging, broadcasts, etc., to multiple wireless users. Communications system 100 may enable multiple wireless users to access such content through the 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, and filter bank multicarrier (FBMC).

As shown in FIG. 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, and 102d, any of which may be referred to as a station (STA), may be configured to transmit and/or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, mobile phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots, or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearables, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and/or other wireless devices operating in industrial and/or automated processing chain contexts), consumer electronics devices, devices operating in commercial and/or industrial wireless networks, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be referred to interchangeably as a UE.

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 base stations 114a, 114b are each depicted as a single element, it will be understood that base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

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 cells (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, beamforming may be used to transmit and/or receive signals in desired spatial directions.

The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d via 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).

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 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).

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).

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

In one embodiment, the base station 114a and the WTRUs 102a, 102b, and 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, and 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, and 102c may be characterized by transmissions sent to and from multiple types of radio access technologies and/or multiple types of base stations (e.g., eNBs and gNBs).

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

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 establish a picocell or femtocell using a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.). As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 through the CN 106.

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, and 102d. The data may have various quality of service (QoS) requirements, such as different throughput, latency, error tolerance, reliability, data throughput, and mobility requirements. The CN 106 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, 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 wireless technology, the CN 106 may also communicate with another RAN (not shown) employing GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi wireless technology.

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 that 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 networks 112 may include another CN connected to one or more RANs that may use the same RAT as the RAN 104 or a different RAT.

Some or all of the WTRUs 102a, 102b, 102c, and 102d in the communications system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, and 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 the base station 114a, which may employ a cellular-based wireless technology, and the base station 114b, which may employ IEEE 802 wireless technology.

FIG. 1B is a system diagram illustrating an exemplary 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.

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 a transceiver 120, which may be coupled to a 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.

The transmit/receive element 122 may be configured to transmit or receive signals to or from a base station (e.g., base station 114a) via 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 signals, UV signals, 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 signals 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.

Although the transmit/receive element 122 is depicted in FIG. 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.

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 NR and IEEE 802.11, for example.

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. In addition, 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).

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.

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) via 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 any suitable location-determination method while remaining consistent with an embodiment.

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, accelerometer, Hall effect sensor, magnetometer, orientation sensor, proximity sensor, temperature sensor, time sensor, geolocation sensor, altimeter, light sensor, touch sensor, magnetometer, barometer, gesture sensor, biometric sensor, humidity sensor, etc.

The WTRU 102 may include a full-duplex radio for transmitting and receiving some or all signals (e.g., associated with a particular subframe in both the UL (e.g., for transmission) and DL (e.g., for reception)) simultaneously and/or together. The full-duplex radio may include an interference management unit for reducing and/or substantially eliminating 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 for transmitting and receiving some or all signals (e.g., associated with a particular subframe in either the UL (e.g., for transmission) or DL (e.g., for reception)).

FIG. 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, and 102c over the air interface 116. The RAN 104 may also communicate with the CN 106.

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 one 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.

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 each other via an X2 interface.

The CN 106 shown in FIG. 1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (PGW) 166. 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.

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 attachment 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) employing other radio technologies such as GSM and/or WCDMA.

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 handovers, 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.

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

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. Additionally, 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.

Although the WTRUs are illustrated in Figures 1A-1D as wireless terminals, it is contemplated that in certain representative embodiments, such terminals may use a wired communications interface (e.g., temporarily or permanently) with a communications network.

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

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 the BSS 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 from a STA 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, 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.

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.

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.

A Very High Throughput (VHT) STA may support channels that are 20 MHz, 40 MHz, 80 MHz, and/or 160 MHz wide. A 40 MHz and/or 80 MHz channel may be formed by combining multiple 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. In the case of an 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 the Medium Access Control (MAC).

Sub-1 GHz operating modes are supported by 802.11af and 802.11ah. The 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 a representative embodiment, 802.11ah may support meter-type control/machine-type communications (MTC), such as MTC devices, in macro coverage areas. An MTC device may have limited capabilities, including support for (e.g., only) certain and/or limited bandwidths. An MTC device may include a battery with an above-threshold battery life (e.g., to maintain a very long battery life).

WLAN systems that may support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that may be designated as a primary channel. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be configured and/or restricted by the STA from among all STAs operating in the BSS that support the minimum bandwidth operating mode. In an 802.11ah embodiment, the primary channel may be 1 MHz wide for STAs (e.g., MTC-type devices) that support (e.g., only) 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 may depend on the status of the primary channel. For example, if the primary channel is busy due to a STA transmitting to the AP (that only supports 1 MHz mode of operation), all of the available frequency bands may be considered busy even if most of the available frequency bands are idle.

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

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

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 one embodiment, the gNBs 180a, 180b, and 180c may implement MIMO technology. For example, the gNBs 180a, 180b may utilize beamforming to transmit signals to and/or receive signals from the gNBs 180a, 180b, and 180c. Thus, the gNB 180a may, for example, transmit and/or receive wireless signals to and from the WTRU 102a using 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 an unlicensed spectrum, while the remaining component carriers may be on a 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 gNB 180a and the gNB 180b (and/or the gNB 180c).

WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using transmissions associated with scalable numerology. For example, OFDM symbol spacing and/or OFDM subcarrier spacing may vary for different transmissions, different cells, and/or different portions of the wireless transmission spectrum. WTRUs 102a, 102b, 102c may communicate with 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).

The gNBs 180a, 180b, and 180c may be configured to communicate with the WTRUs 102a, 102b, and 102c in a standalone configuration and/or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, and 102c may communicate with the gNBs 180a, 180b, and 180c without accessing another RAN (e.g., eNodeBs 160a, 160b, and 160c). In a standalone configuration, the WTRUs 102a, 102b, and 102c may utilize one or more of the gNBs 180a, 180b, and 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, and 102c may communicate with the gNBs 180a, 180b, and 180c using signals in unlicensed bands. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate with and connect to a gNB 180a, 180b, 180c while also communicating with and connecting to another RAN, such as an eNodeB 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement a DC principle 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, and 160c may act as mobility anchors for the WTRUs 102a, 102b, and 102c, and the gNBs 180a, 180b, and 180c may provide additional coverage and/or throughput for serving the WTRUs 102a, 102b, and 102c.

Each of 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 (UPF) 184a, 184b, routing of control plane information to Access and Mobility Management Functions (AMF) 182a, 182b, etc. As shown in FIG. 1D, gNBs 180a, 180b, 180c may communicate with each other via an Xn interface.

CN 106 shown in FIG. 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 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.

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 specific 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 being utilized by 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) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and/or non-3GPP access technologies, such as WiFi.

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.

The UPFs 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via the 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 policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering DL packets, and providing mobility anchoring.

The CN 106 may facilitate communications 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 serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and/or wireless networks owned and/or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to the 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.

With reference to Figures 1A-1D and the corresponding descriptions 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.

The emulation device 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 device may be directly coupled to another device for the purpose of testing and/or performing tests using over-the-air wireless communication.

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.

Disclosed herein is a solution for multi-carrier operation by SL WTRUs, 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 may equally apply to multi-carrier 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 may also be applicable to operation across multiple bandwidth portions, multiple RB sets, etc.

Next, embodiments for selecting a carrier 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.

In one exemplary 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.

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 an 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 established QoS flows 210. The TX WTRU then determines 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 215. Based on the determination 215, the TX WTRU may select 220 some licensed carriers and some unlicensed carriers for the destination. The TX WTRU may then transmit 225 data toward the L2 destination ID on each of the selected carriers.

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 the 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, 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.

The carrier (re)selection behavior may be similar to legacy LTE V2X. Specifically, the SL WTRU may perform 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 for transmission 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.

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 of, or a 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).

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 when it is unlicensed; taking into account the type of currently selected carrier (licensed vs. 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.

Conditions for (re)selecting a licensed carrier and/or an 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.

Bearer configuration conditions may include whether the bearer or logical channel is explicitly configured for a certain 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 an SL bearer, and/or whether the bearer is a default bearer.

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

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, etc.

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.

Conditions related to the 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.

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.).

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.

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.

Conditions related to channel occupancy ratio (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.

Conditions related to 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.

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, an 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.

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 certain 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.

In one example, an 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/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, an SL WTRU may be configured with a CBR/CR threshold associated with carrier reselection. Specifically, if the CBR/CR of one/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 a threshold, e.g., for a period of time, and the WTRU is currently using an unlicensed carrier, the WTRU may trigger a carrier reselection.

In one exemplary 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 preferred carrier types. 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.

In another exemplary embodiment, an 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 with a configured value (possibly total) of the QoS profile above a threshold, the WTRU may select at least one (at least N) unlicensed carrier.

As another example, an 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.

In some embodiments, an 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 (or prioritize its selection of) only licensed carriers. An 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.

Next, an embodiment of TX WTRU operation on multiple carriers is described. In SL, especially 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.

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 acknowledgment of the first transmission.

Referring to FIG. 3, an example method 300 for TX WTRU operation on multiple carriers is shown. The SL TX WTRU establishes a unicast link with a peer WTRU (RX WTRU) 305 and may 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.

If the inactivity timer in the RX WTRU is not running when data arrives for transmission to the RX WTRU 320, the SL TX WTRU performs 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 a subsequent transmission on the carrier indicated in the first transmission 330 and resets the inactivity timer after transmissions on the anchor carrier and non-anchor carriers.

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 on all carriers indicated by the last carrier transmission indicator on the anchor carrier 335.

In a particular embodiment, the WTRU determines the permitted 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 of, or a combination of, (i) determining whether data can 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/if to perform retransmissions on a different carrier compared to the transmission.

Taking into account the type of carrier (e.g., licensed vs. unauthorized) 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 when it is unauthorized; (ii) taking into account the type of currently selected carrier (licensed or unauthorized) 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.

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.

The WTRU may be configured with certain conditions for enabling transmissions on a carrier or for restricting certain transmissions. Such conditions may be used, for example, to determine whether the 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 carriers, on the same/different carrier types, and/or on carriers with the same/similar configuration in terms of resource pool or carrier characteristics.

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

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

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

Transmission pattern conditions may include whether the transmission is periodic or a one-shot transmission.

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.

Conditions related to the MCR 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.

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.).

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 rose above/below a threshold, possibly associated with another condition, and/or time since last transmission.

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

The configuration of a resource pool may include 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 the configured PSFCH.

The DRX behavior of the RX WTRU on that carrier, with any DRX-related conditions, including whether the RX WTRU is in DRX state on that carrier and/or the DRX pattern for that carrier.

Conditions related to LBT failure may include whether an LBT failure has been 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.

CBR-related conditions 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.

Conditions related to 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 CR of another carrier, possibly by a configured threshold amount.

RSSI-related conditions 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 threshold amount.

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.

Certain example embodiments may be based on carrier restriction. For example, the 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 the threshold (higher priority) to be performed on the licensed carriers. For example, the 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 the 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 valid HARQ feedback to be performed on the licensed carriers.

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

In a particular embodiment, the WTRU may be configured with a threshold priority. 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 where, for example, LBT failures, consistent LBT failures, and/or the number of LBT failures exceeds a threshold, etc., and occurred within the last X seconds (X may be configurable by the network).

In another example, the WTRU may perform periodic transmissions only on licensed bands and may be allowed to perform one-shot (i.e., single) transmissions on either licensed or unlicensed carriers.

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, and then perform subsequent transmissions, possibly to the same RX WTRU, possibly to multiple carriers within a maximum time after the first transmission.

The TX WTRU may restrict its first transmission to a particular carrier (e.g., an anchor carrier). In certain examples, 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 the TX WTRU performs a first transmission to an L2 destination ID, the WTRU may perform transmission 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 the 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 thresholds. 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 the anchor carrier from among the carriers that have some properties associated with its (resource pool) configuration, such as carriers configured with PSFCH resources or carriers configured with corresponding PUCCH resources.

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.

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.

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.

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.

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., a 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.

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 to be the first transmission and is performed using the characteristics described 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.

An example follows in which a WTRU performs a subsequent transmission based on information included in a first transmission. In one example, following an 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.

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

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

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 (as described herein) to determine whether to restrict such data transmissions to the anchor carrier.

Next, an embodiment for resource selection for a multi-carrier having licensed and unlicensed carriers is described. In one exemplary embodiment, when performing several transmissions for a particular QoS, the WTRU jointly selects initial and backup resources on the unlicensed and licensed carriers, respectively.

Referring to FIG. 4, an example method 400 for multi-carrier resource selection using licensed and unlicensed carriers is shown. An SL TX WTRU may be configured 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 405.

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, which is later than t1 (by the amount up to the WTRU), such that t1 and t2 are within the resource selection window 410. The WTRU may perform LBT for transmission on the first resource 415, and if 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.

According to some embodiments, resource selection may be performed jointly on multiple carriers. 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).

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

When applying conditions for QoS or carrier configuration, the WTRU may perform joint resource selection when the QoS of the data available for transmission allows joint resource selection, for example, 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.

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.

The conditions for joint resource selection may depend on measurements (CBR, CR, RSRP, RSSI, LBT failure statistics, etc.) for the carrier itself, 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.

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 or data QoS used.

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 measurements of the first resource (e.g., RSSI, CBR, CR, etc.) or based on a measure of unlicensed channel occupancy 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 the carrier frequency difference between the first carrier and the second carrier.

Conditions associated with 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.

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 of 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 QoS/priority/packet delay budget (PDB) of the data, 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.
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, e.g., 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 CAPC (or other similar LBT requirements) of the data, e.g., the minimum time difference between the first resource and the second resource, may be determined by the CAPC of the data. 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 CAPC of the data, 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 a different value 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 a different value 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.

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 resources, as well as the content of the transmission on the first and/or second resources, may depend on the LBT status during transmission on the first resource.

In one 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 a 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.

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 indicator for the first resource together with an indicator 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 a transmission on the first resource) with priority above a threshold, the WTRU may use the second resource for transmission of the new TB.
(2) Availability of control information or inter-WTRU coordination information. In one example, if the WTRU has inter-UE coordination (IUC) information, the WTRU 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 transmitting 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.

Next, an embodiment for carrier-specific SL Radio Link Failure (RLF) based HARQ counting is described. Legacy SL Radio Link Failure (RLF) is designed for a single carrier. One problem with unlicensed HARQ-based counting is that existing mechanisms cannot distinguish whether a HARQ DTX is due to a decoding failure or an LBT failure in the RX WTRU. Using the licensed carrier for information regarding the HARQ DTX count of the unlicensed carrier 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.

Referring to FIG. 5, an example method 500 for determining 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 DTXs (i.e., separate counters 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 on the licensed carrier from the RX WTRU 515. Upon receiving the message, the WTRU may modify the number of consecutive HARQ DTXs on the indicated carrier(s) 520. For example, the TX WTRU may reset the number of consecutive HARQ DTXs or subtract a value (e.g., indicated in a 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 a carrier-specific SL RLF for that carrier to the network 530.

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 the licensed carrier regarding LBT failure, buffer status, channel occupancy time (COT) information, etc., which represent information regarding access or transmission related to the unlicensed carrier. Similarly, based on certain triggers related to channel access on the unlicensed carrier, the WTRU may transmit information regarding 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 the unlicensed or licensed spectrum.

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, a 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 that it failed 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 the transmission of the 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, a 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 can be detected, etc. In one example, the WTRU may perform measurements of the channel indicating the percentage of time during which 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 transmit a message and the contents of the COT information (e.g., COT length, CAPC, L2 destination ID, etc.).

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 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 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 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 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 SL RLF, the WTRU may enable/disable/suspend/resume HARQ DTX counting for SL RLF on the indicated unlicensed carrier.

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 regarding the COT duration to select resources that fall within the COT.

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 the L2 IDs associated with the pending data in the buffer status information received from the peer WTRU on the licensed spectrum. Specifically, if the 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.

In another solution, the WTRU may use buffer status information received on the licensed carrier to determine logical channel prioritization (LCP) behavior during transmission over 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 a priority equal to, higher than, or lower than the particular priority.

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 a 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.

Next, an embodiment for SL RLF in a multi-carrier with licensed and/or unlicensed carriers is described. Legacy SL RLF based on HARQ feedback is designed for a single carrier. In the multi-carrier case, SL RLF may be per carrier and/or per link, which may depend on the interrelationship between the carriers. According to one exemplary embodiment, the WTRU triggers SL-RLF, releases the unicast link, and notifies the network when resource selection fails to find at least one licensed/unlicensed carrier that meets the CBR threshold. In another exemplary embodiment, the WTRU may determine carrier-specific RLFs of 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 reselect a new carrier excluding the carrier previously determined using the carrier-specific RLF, and 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.

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

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 CBR is below a first threshold and some carriers selected on unlicensed bands below a second threshold, and the duration between the carrier (re)selection trigger 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, 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.

In various solutions, the SL RLF may be triggered on a per-carrier basis, referred to herein as a carrier-specific SL RLF. In one solution, a WTRU operating with multiple carriers may monitor/detect/trigger a carrier-specific SL RLF. Specifically, the SL RLF may be triggered on a per-carrier basis, where the WTRU maintains a counter for each carrier that counts the number of consecutive HARQ DTXs received on a given carrier, and the counter is independently incremented/reset based on receiving 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, a 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.

Referring to FIG. 7, a method 700 for determining 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., using a licensed carrier and/or an unlicensed carrier 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 the number of consecutive HARQ DTXs detected on the first SL carrier until the number exceeds a configured threshold 720 715. At this point, 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 among the plurality of carriers that have not been determined using the carrier-specific RLF 730, the TX WTRU releases the unicast link with the RX WTRU 735. Otherwise 730, a second SL carrier is selected from the plurality of carriers 740, the TX WTRU indicates the carrier-specific RLF of the first carrier to the RX WTRU 745, and the unicast link with the RX WTRU is maintained 750. In a particular configuration, the TX WTRU may additionally indicate the selected second SL carrier to the RX WTRU in step 745.

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.

In some embodiments, the WTRU may trigger a carrier-specific SL RLF after receiving an indication of DTX or carrier-specific SL RLF from a peer WTRU, for example, received on another carrier.

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 prohibit 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 prohibit 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 prohibit timers for licensed and unlicensed spectrum.
(3) Trigger carrier reselection. As discussed in step 725 of Figure 7, the WTRU may initiate a carrier reselection procedure. 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 falls 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) Notify peer WTRUs of the SL-RLF on the carrier by sending a message on another carrier.

In one solution, the WTRU may trigger an SL-RLF on the link itself after a carrier (re)selection failure. Specifically, a carrier-specific SL RLF may trigger a carrier (re)selection. Other events (e.g., a change in CBR) may also trigger a 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 the CBR threshold, where (i) the CBR threshold used for carrier (re)selection after a carrier-specific SL RLF may be different 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 be different 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 the other carriers are maintained. During carrier (re)selection for other reasons, the WTRU may perform a full carrier reselection procedure.

SL RLF triggered based on counting across multiple carriers. In one solution, the WTRU may be configured to perform HARQ DTX counting commonly 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 commonly 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 pool configuration or PSFCH configuration). For example, a carrier that allows cross-carrier PSFCH transmission may be considered as an associated carrier from the perspective of HARQ DTX counting for SL RLF determination.

In another solution, the WTRU may count HARQ DTX differently across multiple carriers. Specifically, when counting 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 the counter by one). The WTRU may perform such behavior based on conditions associated with the relative timing of the PSFCH resources, the relative frequencies 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 will be 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, e.g., the counter is reset only if the WTRU successfully decodes the PSFCH on two of the N carriers for which common counting is performed.

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) stop using 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.

While features and elements are described above in particular combinations, those skilled in the art will understand that each feature or element may 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, and optical media such as magneto-optical media and 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 (19)

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. 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. The method of claim 1 or 2, wherein the unicast link includes a vehicle-to-everything (V2X) carrier aggregation (CA) sidelink. The method of any one of claims 1 to 3, wherein the plurality of SL carriers includes carriers in a licensed spectrum. A method according to 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. 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. 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. The WTRU of claim 6 or 7, wherein the unicast link includes a vehicle-to-everything (V2X) carrier aggregation (CA) sidelink. The WTRU of any one of claims 6 to 8, wherein the plurality of SL carriers include carriers in a licensed spectrum. 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. 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;
On condition that an available SL carrier is 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, on condition that an available SL carrier is not determined, releasing the PC5 link with the peer WTRU. 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. 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. 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. The method of claim 13 or 14, wherein the unicast link comprises a vehicle-to-everything (V2X) carrier aggregation (CA) sidelink. The method of any one of claims 13 to 15, wherein the plurality of SL carriers includes carriers in a licensed spectrum. A method according to 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. A 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). A method according to 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.