LBT failure in unlicensed sidelink

Abstract

Methods, systems, and computer readable media are disclosed for performing operations including detecting a Listen Before Talk (LBT) failure on a channel of a sidelink interface for communicating with a second UE, where a first UE and the second UE are served by a base station; and in response to detecting the LBT failure on the channel, performing a recovery procedure, the recovery procedure including reporting LBT failure information to at least one of the base station or the second UE.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. Provisional Application No. 63 / 395,373, filed on August 5, 2022, entitled “LBT FAILURE IN SIDELINK UNLICENSED,” which is incorporated herein by reference in its entirety. Background Art

[0003] Wireless communication networks provide integrated communication platforms and telecommunication services to wireless user devices. Example telecommunication services include telephone, data (e.g., voice, audio and / or video data), messaging, Internet access and / or other services. Wireless communication networks have wireless access nodes that exchange wireless signals with wireless user devices using wireless network protocols (such as protocols described in various telecommunication standards promulgated by the Third Generation Partnership Project (3GPP)). Example wireless communication networks include time division multiple access (TDMA) networks, frequency division multiple access (FDMA) networks, orthogonal frequency division multiple access (OFDMA) networks, long term evolution (LTE) and fifth generation new radio (5G NR). Wireless communication networks use technologies such as OFDM, multiple input multiple output (MIMO), advanced channel coding, massive MIMO, beamforming and / or other features to facilitate mobile broadband services.

[0004] In some wireless communication networks, a user equipment (UE) can communicate with another UE without routing the communication through a network node using so-called sidelink communication. A transmitting UE that wants to initiate a sidelink communication can determine available resources (e.g., sidelink resources) and can select a subset of these resources based on a resource allocation scheme to communicate with a receiving UE. Existing protocols support sidelink communications using mode 1 and mode 2 resource allocation schemes. In the mode 1 resource allocation scheme (also referred to as "mode 1"), resources are allocated by a network node to UEs within coverage. In the mode 2 resource allocation scheme (also referred to as "mode 2"), the transmitting UE selects sidelink resources (e.g., sidelink transmission resources). Summary of the invention

[0005] The present disclosure describes methods and systems for handling listen-before-talk (LBT) failures in an unlicensed side link. The disclosed methods and systems are designed to take into account the characteristics of the side link and are therefore different from existing LBT failure handling mechanisms (e.g., for interfaces other than the side link). The disclosed methods and systems support handling LBT failures in all radio resource control (RRC) states, including idle, inactive, and out-of-coverage (OOC) states. In addition, the disclosed methods and systems support handling LBT failures in both mode 1 and mode 2 resource allocation schemes. Still further, the disclosed methods and systems support handling LBT failures by destination (e.g., by destination UE).

[0006] According to one aspect of the present disclosure, a method performed by a user equipment (UE) is disclosed. The method involves: detecting a listen-before-talk (LBT) failure on a channel of a side link interface for communicating with a second UE, wherein the first UE and the second UE are served by a base station; and in response to detecting the LBT failure on the channel, performing a recovery process, the recovery process including reporting LBT failure information to at least one of the base station or the second UE.

[0007] The previously described implementations can be implemented using: a computer-implemented method; a non-transitory computer-readable medium storing computer-readable instructions to perform the computer-implemented method; and a computer system including a computer memory interoperably coupled to a hardware processor configured to perform the computer-implemented method or instructions stored on the non-transitory computer-readable medium. These and other implementations may optionally include one or more of the following features.

[0008] In some embodiments, detecting the LBT failure on the channel includes detecting a threshold number of LBT failure instances on the channel before an LBT failure detection timer expires, wherein the LBT failure detection timer is restarted when an LBT failure instance is detected.

[0009] In some specific implementations, performing the recovery process includes: declaring a radio link failure of the channel; triggering an upper layer of the first UE to run a keep-alive check; and in response to determining that the first UE is in a connected state, reporting the LBT failure information to the base station.

[0010] In some specific implementations, performing the recovery process includes: selecting at least one new component carrier from multiple component carriers used for carrier aggregation that is different from the initial component carrier on which the LBT failure was detected; and reporting the LBT failure information to the second UE via the at least one new component carrier.

[0011] In some specific implementations, performing the recovery process includes: in response to determining that the UE is not in a connected state, entering the connected state for failure information reporting; and reporting the LBT failure information to the base station via the Uu interface.

[0012] In some embodiments, the channel is a first channel, and performing the recovery process includes: starting a timer for reporting the failure information via an exception resource pool of the side link interface; attempting to perform LBT on a second channel using the exception resource pool; if the LBT succeeds before the timer expires, stopping the timer; and if the LBT is unsuccessful before the timer expires, declaring a radio link failure of the first channel.

[0013] In some specific implementations, the method also includes: generating a message, the message including the LBT failure information, the message also including at least one of the following items: (i) carrier information, (ii) transmission type, (iii) measurement results of the side link interface, (iv) measurement results of the Uu interface, or (iv) playback type.

[0014] In some implementations, the transmission type includes SL-SSB, PSFCH, PSCCH, SL DRB, SL-SRB0, SL-SRB1, SL-SRB2, SL-SRB3, or SL-SRB4.

[0015] In some implementations, the play type includes broadcast, multicast, or unicast.

[0016] In some implementations, the message is one of: a cause value field in a PC5 RRC message, a sidelink MAC-CE, a UuMAC-CE, or a Uu RRC message.

[0017] In some implementations, the sidelink MAC-CE is assigned the highest priority CAPC.

[0018] In some implementations, during the sidelink LCP procedure, the sidelink MAC-CE has priority between the data of the SCCH and the CSI reporting MAC-CE.

[0019] In some implementations, during the Uu LCP procedure, the Uu MAC-CE has priority between the LBT failure MAC-CE and the MAC-CE for the prioritized SL-BSR.

[0020] In some specific implementations, reporting the LBT failure information to at least one of the base station or the second UE includes: reporting the LBT failure information to both the base station and the second UE.

[0021] The details of one or more embodiments of these systems and methods are set forth in the following drawings and description. Other features, objects, and advantages of these systems and methods will be apparent from the description and drawings, and from the claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] Figure 1 An example communication system including sidelink communications according to some implementations is illustrated.

[0023] Figure 2 A flow chart for handling LBT failures in an unlicensed side link according to some implementations is illustrated.

[0024] Figure 3A and Figure 3B Example scenarios are illustrated in which an RX UE determines whether an LBT failure has occurred according to some specific implementations.

[0025] Figure 4 Flowcharts illustrating example methods according to some implementations are shown.

[0026] Figure 5 A user equipment (UE) according to some implementations is illustrated.

[0027] Figure 6 An access node according to some implementations is shown.

[0028] Like reference numbers and designations in the various drawings indicate like elements. DETAILED DESCRIPTION

[0029] In Release 18 of the 3rd Generation Partnership Project (3GPP) technical standards, one of the areas of research and development is a sidelink interface operating in an unlicensed spectrum (also referred to as an "unlicensed side link"). In particular, the research and development includes a channel access mechanism, a sidelink resource reservation process, a physical channel design framework, and a sidelink physical channel structure and process for an unlicensed side link. An advantage of the unlicensed side link is that it can meet the demand for growing wireless data services. Additionally, the unlicensed side link can achieve better latency (e.g., quality of service [QoS]) from the perspective of the user equipment (UE) than can be achieved through Uu interference. In addition, some use cases and device types may particularly benefit from the unlicensed side link. Example use cases include home networks, personal networks, industrial networks, etc., and example device types include Internet of Things (IoT) devices, wearable devices, relay devices, etc.

[0030] Like other communications in the unlicensed spectrum, the unlicensed sidelink uses a listen-before-talk (LBT) mechanism to access the channel. In the Mode 1 resource allocation scheme, the transmitting UE (TX UE) receives downlink control information (DCI, e.g., Format 3-0) on a licensed downlink (DL) carrier. The DCI schedules sidelink transmissions on the unlicensed carrier. After receiving the DCI, the TXUE performs LBT to transmit information to the receiving UE (RX UE) via the unlicensed carrier. In Mode 2RA, the TX UE utilizes LBT to perform specified sensing and reservation-based mechanisms before transmitting information to the RXUE. However, LBT may fail in either mode for various reasons.

[0031] The present disclosure describes methods and systems for handling LBT failures in unlicensed side links. The disclosed methods and systems are designed to take into account the characteristics of the side link and are therefore different from existing LBT failure handling mechanisms (e.g., for interfaces other than the side link). The disclosed methods and systems support handling LBT failures in all radio resource control (RRC) states, including idle, inactive, and out of coverage (OOC) states. In addition, the disclosed methods and systems support handling LBT failures in both mode 1 and mode 2 resource allocation schemes. Still further, the disclosed methods and systems support handling LBT failures by destination (e.g., by destination UE).

[0032] Figure 1 An example communication system 100 including sidelink communication according to some implementations is illustrated. Note that Figure 1 The system is just one example of a possible system, and features of the present disclosure may be implemented in other wireless communication systems.

[0033] The following description is provided for an example communication system operating in conjunction with a fifth generation (5G) network provided by the 3GPP technical specifications. However, the example implementation is not limited in this regard, and the described examples may be applied to other networks that may benefit from the principles described herein, such as 3GPP Long Term Evolution (LTE) networks, Wi-Fi, etc. In addition, other types of communication standards are also possible, including future 3GPP systems (e.g., sixth generation (6G)), etc. Although various aspects may be described herein using terms typically associated with 5G NR, various aspects of the present disclosure may be applied to other systems, such as 4G and / or systems after 5G (e.g., 6G).

[0034] As shown, the communication system 100 includes a plurality of user equipments. More specifically, the communication system 100 includes two UEs 105 (UE 105-1 and UE 105-2 are collectively referred to as "UE 105" or "UEs 105"), two base stations 110 (base stations 110-1 and base stations 110-2 are collectively referred to as "base stations 110" or "base stations 110"), two cells 115 (cells 115-1 and cells 115-2 are collectively referred to as "cells 115" or "cells 115"), and one or more servers 135 in a core network (CN) 140 connected to the Internet 145.

[0035] In some implementations, UE 105 may communicate directly with base station 110 via links 120 (links 120-1 and 120-2 are collectively referred to as "a link 120" or "links 120"), which utilize a direct interface with the base station (referred to as a "Uu interface"). Each of links 120 may represent one or more channels. Links 120 are illustrated as air interfaces that implement communication coupling and may conform to cellular communication protocols, such as 3GPP LTE protocols, advanced long term evolution (LTE-A) protocols, LTE-based unlicensed spectrum access (LTE-U), 5G protocols, NR protocols, NR-based unlicensed spectrum access (NR-U) protocols, and / or any other communication protocols discussed herein.

[0036] As shown, some user equipments may be able to communicate directly with each other, for example, without intermediate infrastructure equipment (such as base station 110-1). In this example, UE 105-1 may communicate directly with UE 105-2. Similarly, UE 105-2 may communicate directly with UE 105-1. This peer-to-peer communication may utilize a "side link" interface such as a PC5 interface. In some specific implementations, the PC5 interface supports direct cellular communication between user equipments (e.g., between UE 105), while the Uu interface supports cellular communication with infrastructure equipment (such as a base station). For example, UE 105 may use the PC5 interface for radio resource control (RRC) signaling exchange between UEs. The PC5 / Uu interface is used only as an example, and PC5 as used herein may represent various other possible wireless communication technologies that allow direct side link communication between user equipments, while Uu may represent cellular communication performed between user equipments and infrastructure equipment (such as a base station).

[0037] In order to transmit / receive data to / from one or more base stations 110 or UE 105, UE 105 may include a transmitter / receiver (or alternatively, a transceiver), a memory, one or more processors, and / or other similar components that enable UE 105 to operate according to one or more wireless communication protocols and / or one or more cellular communication protocols. UE 105 may have multiple antenna elements that enable UE 105 to maintain multiple links 120 and / or side links 125 to transmit / receive data to / from multiple base stations 110 and / or multiple UEs 105. For example, as Figure 1 As shown, UE 105 - 1 may be connected to base station 110 - 1 via link 120 and simultaneously connected to UE 105 - 2 via side link 125 .

[0038] In some implementations, one or more sidelink radio bearers may be established on the sidelink 125. The sidelink radio bearers may include signaling radio bearers (SL-SRBs) and / or data radio bearers (SL-DRBs). The signaling radio bearers may be of different types, including SL-SRB0, SL-SRB1, SL-SRB2, SL-SRB3, and SL-SRB4.

[0039] The PC5 interface may alternatively be referred to as a sidelink interface and may include one or more logical channels, including but not limited to a physical sidelink control channel (PSCCH), a physical sidelink shared channel (PSSCH), a physical sidelink discovery channel (PSDCH), a physical sidelink broadcast channel (PSBCH), a physical sidelink feedback channel (PSFCH), and / or any other similar communication channel. The PSFCH carries feedback related to the success or failure reception of the sidelink transmission. The PSSCH may be scheduled by the sidelink control information (SCI) carried in the sidelink PSCCH. In some examples, the sidelink interface may operate on an unlicensed spectrum (e.g., in an unlicensed 5 GHz (GHz) and 6 GHz band) or a (licensed) shared spectrum.

[0040] In one example, the sidelink interface implements vehicle-to-everything (V2X) communications. V2X communications may, for example, follow the 3GPP Cellular V2X (C-V2X) specification, or follow one or more other or subsequent standards, whereby vehicles and other devices and network entities may communicate. V2X communications may utilize both long-range (e.g., cellular) communications and short-range to medium-range (e.g., non-cellular) communications. V2X communications with cellular capabilities may be referred to as cellular V2X (C-V2X) communications. C-V2X systems may use various cellular radio access technologies (RATs), such as 4G LTE or 5G NR RAT (or RATs after 5G, e.g., 6G RAT). Certain LTE standards available in V2X systems may be referred to as LTE-Vehicle (LTE-V) standards. As used herein in the context of a V2X system, and as defined above, the term "user equipment" may generally refer to a device associated with a mobile participant or traffic participant in a V2X system, e.g., a mobile (capable of moving) communication device such as a vehicle, a pedestrian user equipment (PUE) device, and a roadside unit (RSU).

[0041] In some implementations, the UEs 105 may be physical hardware devices that can run one or more applications, can access network services via one or more radio links 120 with corresponding base stations 110 (also referred to as "serving" base stations), and can communicate with each other via side links 125. The links 120 may allow the UEs 105 to send and receive data from the base stations 110 providing the links 120. The side links 125 may allow the UEs 105 to send and receive data with each other. The side links 125 between the UEs 105 may include one or more channels for transmitting information from the UE 105-1 to the UE 105-2 (or vice versa) and / or between the UE 105 and a UE-type RSU (or vice versa).

[0042] In some implementations, base stations 110 can communicate with each other over a backhaul connection 130, and can communicate with one or more servers 135 within CN 140 over another backhaul connection 133. The backhaul connection can be a wired and / or wireless connection.

[0043] In some implementations, UE 105 is configured to use a resource pool for sidelink communications. The sidelink resource pool may be divided into multiple time slots, frequency channels, and frequency subchannels. In some examples, UE 105 is synchronized and performs sidelink transmissions aligned with time slot boundaries. It may be desirable for the UE to select several time slots and subchannels for transmission of a transport block. In some examples, the UE may use different subchannels to transmit a transport block across multiple time slots within its own resource selection window.

[0044] In some implementations, the base station 110 may configure a special exception resource pool for the UE 105. The special exception resource pool includes resources that the UE 105 can use in special exception situations such as radio link failure (RLF). The special exception resource pool may include resources selected based on random resource allocation.

[0045] In some implementations, the communication system 100 supports different broadcast types, including unicast, broadcast, and groupcast (or multicast) communications. Unicast refers to direct communication between two UEs. Broadcast refers to communication broadcasted by a single UE to multiple other UEs. Groupcast refers to communication transmitted from a single UE to a set of UEs that meet a certain condition (e.g., as members of a specific group).

[0046] In some implementations, UE 105 is configured to implement an LBT failure recovery procedure for the side link. For the purposes of this disclosure, a UE that is initiating communication with another UE is referred to as a TX UE, and a UE that is receiving the communication is referred to as an RX UE. For example, UE 105-1 may be a TX UE, and UE 105-2 may be an RX UE. In addition, although Figure 1 It is illustrated that a single TX UE communicates with a single RX UE, but the TX UE may communicate with more than one RX UE via a side link.

[0047] Figure 2 A workflow 200 for LBT failure recovery according to some specific implementations is illustrated. The workflow 200 may be implemented by a TX UE that is transmitting (or scheduled to transmit) a sidelink communication to an RX UE. The RX UE and the TX UE are served by a common base station (e.g., base station 110). The workflow 200 may be implemented by a TX UE operating in any RRC state including idle, inactive, connected, or OOC. In addition, the workflow 200 may be implemented by a TX UE that is using a mode 1 resource allocation scheme or a mode 2 resource allocation scheme.

[0048] Workflow 200 begins at step 202. At step 202, the TX UE detects an LBT failure. In one example, the TX UE determines that an LBT failure occurs after detecting a threshold number of LBT failure instances, possibly within a threshold amount of time. The threshold number of failure instances and / or the threshold amount of time may be received from a serving base station in a sidelink-specific LBT configuration. For purposes of LBT failure detection, the sidelink-specific LBT configuration may include a counter (e.g., LBT_COUNTER) and / or a timer (e.g., LBT_TIMER) per destination. In one example, detecting a sidelink LBT failure is performed by a medium access control (MAC) layer of the TX UE.

[0049] Figure 3A and Figure 3B An example scenario is illustrated in which a TX UE determines whether an LBT failure has occurred according to some specific implementations. When the TX UE starts monitoring for LBT failure, the TX UE starts an LBT failure detection timer. Figure 3A In the scenario 300 of FIG. 3 , the TX UE detects a first instance of an LBT failure at time T1. In response to detecting the failure instance, the TX UE resets the LBT failure detection timer and increases the value of the LBT failure counter by 1. Then, at time T2, the TX UE detects a second instance of an LBT failure. Here, as at T1, the TX UE resets the LBT failure detection timer and increases the value of the LBT failure counter by 1. At time T3, the TX UE detects a third instance of an LBT failure. Here, as at T1 and T2, the TX UE resets the LBT failure detection timer and increases the value of the LBT failure counter by 1. However, in this example, the counter has now exceeded a predetermined threshold. In response to determining that the counter has exceeded the predetermined threshold, the TX UE determines that an LBT failure has occurred.

[0050] exist Figure 3B In the scenario 320 of FIG. 3 , the TX UE detects a first instance of an LBT failure at time T1. In response to detecting the instance, the TX UE resets the LBT failure detection timer and increases the value of the LBT failure counter by 1. However, in this scenario, the TX UE does not detect another LBT failure instance until the timer expires. Therefore, the TX UE determines that no LBT failure has occurred and resets the value of the LBT failure counter to zero.

[0051] Return to Figure 2 In response to detecting that an LBT failure has occurred, the TX UE performs one or more recovery procedures of a plurality of recovery procedures, as shown in step 204. The recovery procedure involves sending LBT failure information to the RX UE and / or the serving base station. The LBT failure information enables the reconstruction of a side link channel on which the TX UE can transmit data to the RX UE. The LBT failure information and the signaling carrying the failure information will be described in more detail below.

[0052] In the first recovery process "Recovery Process 1", the TX UE announces a side link radio link failure (RLF). In this process, the TX UE announces an RLF on the side link in response to detecting an LBT failure on the side link channel. Then, the TX UE triggers the upper layer to run a keep-alive check, which is a mechanism running in the PC5 signaling protocol stack called PC5-S. The keep-alive check will check whether the link between the two UEs is still feasible. Under this mechanism, the TX UE will periodically send PC5-S signaling to check whether the RX UE can respond, so that the TX UE can determine whether the RX UE is operating (active). Then, if the TX UE is in the RRC connected state, the TX UE reports the failure information to the serving base station. If the TX UE is not in the RRC connected state, the TX UE first switches to the RRC connected state to report the failure information. As described in more detail below, the failure information may be sent in a Uu RRC message or in a MAC-CE. In one example, the failure information may be reported in a failure cause message created for the side link LBT failure. The TX UE may apply the first recovery procedure in either Mode 1 or Mode 2 resource allocation schemes and in all RRC states.

[0053] In the second recovery process "Recovery Process 2", the TX UE reports the failure information to the RX UE. The TX UE may apply the second recovery process in a scenario where PC5 carrier aggregation (CA) is configured. In this process, in response to detecting an LBT failure, the TX UE reports the failure information to the RX UE via a PC5 carrier different from the PC5 carrier in which the LBT failure was detected. Upon receiving the failure information, the RX UE may negotiate with the TX UE on the PC5 RRC reconfiguration. The reconfiguration includes reconfiguration of the TX resource pool, the RX resource pool, the transmission power, and other parameters. The TX UE may apply this process in a mode 1 or mode 2 resource allocation scheme and in all RRC states.

[0054] In the third recovery process "Recovery Process 3", the TX UE reports failure information to the serving base station. Unlike recovery process 1, the TX UE in this process does not declare a side link RLF in response to detecting a side link LBT failure. Instead, the TX UE reports failure information to the serving base station without declaring a side link RLF. If the TX UE is not in the RRC connected state, the TX UE may request to enter the RRC connected state for failure information reporting. The TX UE may apply this recovery process in a mode 1 or mode 2 resource allocation scheme. However, if the TX UE is OOC, the TX UE does not apply this recovery process.

[0055] In the fourth recovery process "Recovery Process 4", the TX UE uses the exception resource pool to report the failure information. The exception resource pool can be time-division multiplexed with the normal resource pool. In this process, the TX UE starts a timer for recovery via the exception resource pool. Then, the TX UE performs LBT to send the failure information to the RX UE via the exception resource pool. If the LBT is successful, the TX UE stops the timer. Then, the RX UE can negotiate PC5 RRC reconfiguration with the TX UE upon receiving the failure information. The TX UE can apply this process in mode 1 or mode 2 resource allocation schemes and in all RRC states. Conversely, if the timer expires before the LBT succeeds on the exception resource pool, the TX UE performs the first recovery process.

[0056] In some implementations, the serving base station may configure the TX UE to perform a combination of recovery process 2, recovery process 3, and recovery process 4. For example, the base station may configure the TX UE to report failure information to both the RX UE and the base station (e.g., using recovery processes 2 and 3). The serving base station may configure the TX UE with the process to be performed via pre-configuration, configuration in a system information block (SIB), or Uu configuration.

[0057] In some implementations, signaling of failure information to the RX UE may be sent in a PC5 RRC message or in a sidelink MAC-CE (e.g., in recovery procedures 2, 4). The sidelink MAC-CE may have a fixed logical channel ID (LCID). In some examples, the signaling may include at least one of the following: (i) carrier information, (ii) transmission type (sidelink synchronization signal block (SL-SSB), PSFCH, PSCCH, SL-DRB, SL-SRB0 / 1 / 2 / 3 / 4), or (iii) the play type (e.g., broadcast, multicast, unicast) of the sidelink channel where the LBT failure was detected. Additionally and / or alternatively, the signaling may include available PC5 measurement results and / or Uu measurement results.

[0058] In some implementations, during the Logical Channel Prioritization (LCP) process, the priority of the MAC-CE is between the data of the Sidelink Control Channel (SCCH) and the Channel State Information (CSI) of the Reporting MAC-CE. For example, the priority during the LCP process is: SCCH>LBT Failure MAC-CE>CSI of the Reporting MAC-CE>Data from the Sidelink Service Logical Channel (STCH). In some implementations, the LBT Failure MAC-CE is assigned the highest priority Channel Access Priority Category (CAPC), where the CAPC is used to determine the priority of communications accessing an unlicensed channel.

[0059] In some specific implementations, the signaling of the failure information to the base station (e.g., in recovery process 1, 3) may be sent in a Uu RRC message or a MAC-CE with a fixed LCID. In an example, the failure information may be sent in a new cause value (e.g., LBT failure) in the Uu RRC message SidelinkUEInformationNR. The MAC-CE may include at least one of the following: (i) carrier information, (ii) transmission type (e.g., SL-SSB, PSFCH, PSCCH, SL-DRB, SL-SRB0 / 1 / 2 / 3 / 4), or (iii) play type (e.g., broadcast, multicast, unicast). During the Uu LCP process, the priority of the sidelink LBT failure MAC-CE is between the LBT failure MAC-CE and the MAC-CE for the prioritized SL buffer status report (BSR). In an example, the Uu LCP process described in 3GPP TS 38.321V16.5.0 may be modified so that the priority (from high to low) is as follows:

[0060] -C-RNTI MAC-CE or data from UL-CCCH;

[0061] -Configuration Authorization Confirmation MAC-CE or MAC-CE for Beam Failure Report (BFR) or multiple-entry Configuration Authorization Confirmation MAC-CE;

[0062] -Sidelink configuration authorization confirmation MAC-CE;

[0063] -LBT failed MAC-CE;

[0064] -Sidelink LBT failure MAC-CE;

[0065] - MAC-CE for SL-BSR prioritization according to clause 5.22.1.6;

[0066] - MAC-CE for BSR, except for BSR included for padding;

[0067] - Single entry Power Headroom Report (PHR) MAC-CE or multiple entry PHR MAC-CE;

[0068] - MAC-CE for the number of desired protection symbols;

[0069] - MAC-CE for preemptive BSR;

[0070] - MAC-CE for SL-BSRs, except for SL-BSRs prioritized according to clause 5.22.1.6 and SL-BSRs included for padding;

[0071] - Data from any logical channel, except data from the uplink common control channel (UL-

[0072] In addition to CCCH data;

[0073] -MAC-CE for recommended bit rate query;

[0074] - MAC-CE for the BSR included for padding;

[0075] - MAC-CE for SL-BSR included for padding.

[0076] Figure 4 A flowchart of an example method 400 according to some specific implementations is illustrated. For clarity of presentation, the following description generally describes the method 400 in the context of other figures in this specification. For example, the method 400 may be performed by Figure 1 UE 105 of the present invention is executed. It should be understood that method 400 can be performed by any suitable system, environment, software, hardware or a combination of systems, environments, software and hardware as appropriate. In some specific implementations, the steps of method 400 can be executed in parallel, in combination, in a loop or in any order. In some specific implementations, method 400 is executed by the first UE.

[0077] At step 402, method 400 involves detecting a listen-before-talk (LBT) failure on a channel of a sidelink interface used for communicating with a second UE, wherein the first UE and the second UE are served by a base station.

[0078] At step 404, method 400 involves, in response to detecting the LBT failure on the channel, performing a recovery process, the recovery process including reporting LBT failure information to at least one of the base station or the second UE.

[0079] In some embodiments, detecting the LBT failure on the channel includes detecting a threshold number of LBT failure instances on the channel before an LBT failure detection timer expires, wherein the LBT failure detection timer is restarted when an LBT failure instance is detected.

[0080] In some specific implementations, performing the recovery process includes: declaring a radio link failure of the channel; triggering an upper layer of the first UE to run a keep-alive check; and in response to determining that the first UE is in a connected state, reporting the LBT failure information to the base station.

[0081] In some specific implementations, performing the recovery process includes: selecting at least one new component carrier from multiple component carriers used for carrier aggregation that is different from the initial component carrier on which the LBT failure was detected; and reporting the LBT failure information to the second UE via the at least one new component carrier.

[0082] In some specific implementations, performing the recovery process includes: in response to determining that the UE is not in a connected state, entering the connected state for failure information reporting; and reporting the LBT failure information to the base station via the Uu interface.

[0083] In some embodiments, the channel is a first channel, and performing the recovery process includes: starting a timer for reporting the failure information via an exception resource pool of the side link interface; attempting to perform LBT on a second channel using the exception resource pool; if the LBT succeeds before the timer expires, stopping the timer; and if the LBT is unsuccessful before the timer expires, declaring a radio link failure of the first channel.

[0084] In some specific implementations, the method also includes: generating a message, the message including the LBT failure information, the message also including at least one of the following items: (i) carrier information, (ii) transmission type, (iii) measurement results of the side link interface, (iv) measurement results of the Uu interface, or (iv) playback type.

[0085] In some implementations, the transmission type includes SL-SSB, PSFCH, PSCCH, SL-DRB, SL-SRB0, SL-SRB1, SL-SRB2, SL-SRB3, or SL-SRB4.

[0086] In some implementations, the play type includes broadcast, multicast, or unicast.

[0087] In some implementations, the message is one of: a cause value field in a PC5 RRC message, a sidelink MAC-CE, a UuMAC-CE, or a Uu RRC message.

[0088] In some implementations, the sidelink MAC-CE is assigned the highest priority CAPC.

[0089] In some implementations, during the sidelink LCP procedure, the sidelink MAC-CE has priority between the data of the SCCH and the CSI reporting MAC-CE.

[0090] In some implementations, during the Uu LCP procedure, the Uu MAC-CE has priority between the LBT failure MAC-CE and the MAC-CE for the prioritized SL-BSR.

[0091] In some specific implementations, reporting the LBT failure information to at least one of the base station or the second UE includes: reporting the LBT failure information to both the base station and the second UE.

[0092] Figure 5 UE 500 according to some specific implementations is illustrated. UE 500 may be similar to Figure 1 UE 105 and is essentially interchangeable therewith.

[0093] UE 500 can be any mobile or non-mobile computing device, such as a mobile phone, a computer, a tablet, an industrial wireless sensor (e.g., a microphone, a pressure sensor, a thermometer, a motion sensor, an accelerometer, an inventory sensor, a voltage / current meter, etc.), a video device (e.g., a camera, a camcorder, etc.), a wearable device (e.g., a smart watch), or a loose IoT device.

[0094] UE 500 may include a processor 502, an RF interface circuit 504, a memory / storage device 506, a user interface 508, a sensor 510, a driver circuit 512, a power management integrated circuit (PMIC) 514, one or more antennas 516, and a battery 518. The components of UE 500 may be implemented as an integrated circuit (IC), a portion of an integrated circuit, a discrete electronic device or other module, logical component, hardware, software, firmware, or a combination thereof. Figure 5 The block diagram of UE 500 is intended to show a high-level view of some of the components of UE 500. However, some of the components shown may be omitted, additional components may be present, and different arrangements of the components shown may occur in other implementations.

[0095] Components of UE 500 may be coupled to various other components via one or more interconnects 520, which may represent any type of interface, input / output, bus (local, system, or extension), transmission line, trace, optical connection, etc., which allows various circuit components (on a common or different chip or chipset) to interact with each other.

[0096] The processor 502 may include processor circuits such as, for example, a baseband processor circuit (BB) 522A, a central processor unit circuit (CPU) 522B, and a graphics processor unit circuit (GPU) 522C. The processor 502 may include any type of circuit or processor circuit that executes or otherwise operates computer-executable instructions (such as program codes, software modules, or functional processes from the memory / storage device 506) to cause the UE 500 to perform operations as described herein.

[0097] In some specific implementations, the processor 502 is configured to perform operations that cause the UE to detect a listen-before-talk (LBT) failure on a channel of a sidelink interface used to communicate with a second UE, wherein the first UE and the second UE are served by a base station. In addition, the processor 502 is configured to perform operations that cause the UE to perform a recovery process in response to detecting the LBT failure on the channel, the recovery process including reporting LBT failure information to at least one of the base station or the second UE.

[0098] In some implementations, the baseband processor circuit 522A may access a communication protocol stack 524 in the memory / storage device 506 to communicate over a 3GPP compatible network. Typically, the baseband processor circuit 522A may access a communication protocol stack to: perform user plane functions at the physical (PHY) layer, the medium access control (MAC) layer, the radio link control (RLC) layer, the packet data convergence protocol (PDCP) layer, the service data adaptation protocol (SDAP) layer, and the PDU layer; and perform control plane functions at the PHY layer, the MAC layer, the RLC layer, the PDCP layer, the RRC layer, and the non-access layer. In some implementations, the PHY layer operations may be additionally / alternatively performed by components of the RF interface circuit 504. The baseband processor circuit 522A may generate or process a baseband signal or waveform that carries information in a 3GPP compatible network. In some implementations, the waveform used for NR can be based on cyclic prefix orthogonal frequency division multiplexing (OFDM) "CP-OFDM" in uplink or downlink, and discrete Fourier transform spread OFDM "DFT-S-OFDM" in uplink.

[0099] The memory / storage 506 may include one or more non-transitory computer-readable media including instructions (e.g., the communication protocol stack 524) that may be executed by one or more processors in the processor 502 to enable the UE 500 to perform various operations described herein. The memory / storage 506 includes any type of volatile or non-volatile memory that may be distributed throughout the UE 500. In some implementations, some of the memory / storage 506 may be located on the processor 502 itself (e.g., L1 cache and L2 cache), while other memory / storage 506 is located external to the processor 502 but may be accessed via a memory interface. The memory / storage 506 may include any suitable volatile or non-volatile memory, such as, but not limited to, dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, solid-state memory, or any other type of memory device technology.

[0100] The RF interface circuit 504 may include a transceiver circuit and a radio frequency front end module (RFEM), which allows the UE 500 to communicate with other devices through a radio access network. The RF interface circuit 504 may include various components arranged in a transmit path or a receive path. These components may include, for example, switches, mixers, amplifiers, filters, synthesizer circuits, control circuits, etc.

[0101] In the receive path, the RFEM may receive the radiated signal from the air interface via one or more antennas 516 and proceed to filter and amplify the signal (using a low noise amplifier). The signal may be provided to a transceiver's receiver, which down-converts the RF signal to a baseband signal, which is provided to a baseband processor of the processor 502.

[0102] In the transmit path, the transmitter of the transceiver up-converts the baseband signal received from the baseband processor and provides the RF signal to the RFEM. The RFEM may amplify the signal through a power amplifier before the RF signal is radiated across the air interface via the antenna 516. In various specific implementations, the RF interface circuit 504 may be configured to transmit / receive signals in a manner compatible with the NR access technology.

[0103] Antenna 516 may include antenna elements to convert electrical signals into radio waves to travel through the air and convert received radio waves into electrical signals. These antenna elements may be arranged into one or more antenna panels. Antenna 516 may have an antenna panel that is omnidirectional, directional, or a combination thereof to achieve beamforming and multiple-input / multiple-output communications. Antenna 516 may include a microstrip antenna, a printed antenna manufactured on the surface of one or more printed circuit boards, a patch antenna, a phased array antenna, etc. Antenna 516 may have one or more panels that are designed for a specific frequency band including a band in FR1 or FR2.

[0104] The user interface 508 includes various input / output (I / O) devices designed to enable a user to interact with the UE 500. The user interface 508 includes input device circuits and output device circuits. The input device circuit includes any physical or virtual components for accepting input, including in particular one or more physical or virtual buttons (e.g., reset button), physical keyboards, keypads, mice, touch pads, touch screens, microphones, scanners, headphones, etc. The output device circuit includes any physical or virtual components for displaying information or otherwise conveying information (such as sensor readings, actuator positions, or other similar information). The output device circuit may include any number or combination of audio or visual displays, including in particular one or more simple visual outputs / indicators (e.g., binary state indicators, such as light emitting diodes "LEDs" and multi-character visual outputs), or more complex outputs, such as display devices or touch screens (e.g., liquid crystal displays "LCDs", LED displays, quantum dot displays, projectors, etc.), where the output of characters, graphics, multimedia objects, etc. is generated or produced by the operation of the UE 500.

[0105] Sensor 510 may include a device, module, or subsystem whose purpose is to detect events or changes in its environment and to communicate information about the detected events (sensor data) to some other device, module, subsystem, etc. Examples of such sensors include, among others: an inertial measurement unit including an accelerometer, gyroscope, or magnetometer; a microelectromechanical system or nanoelectromechanical system including a three-axis accelerometer, three-axis gyroscope, or magnetometer; a liquid level sensor; a temperature sensor (e.g., a thermistor); a pressure sensor; an image capture device (e.g., a camera or a lensless aperture); a light detection and ranging sensor; a proximity sensor (e.g., an infrared radiation detector, etc.); a depth sensor; an ambient light sensor; an ultrasonic transceiver; a microphone or other similar audio capture device; and the like.

[0106] The driver circuit 512 may include software and hardware elements that operate to control a specific device embedded in, attached to, or otherwise communicatively coupled to the UE 500. The driver circuit 512 may include separate drivers to allow other components to interact with or control various input / output (I / O) devices that may be present in or connected to the UE 500. For example, the driver circuit 512 may include: a display driver for controlling and allowing access to a display device, a touch screen driver for controlling and allowing access to a touch screen interface, a sensor driver for obtaining sensor readings of the sensor 510 and controlling and allowing access to the sensor 510, a driver for obtaining an actuator position of an electromechanical component or controlling and allowing access to an electromechanical component, a camera driver for controlling and allowing access to an embedded image capture device, and an audio driver for controlling and allowing access to one or more audio devices.

[0107] The PMIC 514 may manage the power provided to various components of the UE 500. Specifically, with respect to the processor 502, the PMIC 514 may control power source selection, voltage scaling, battery charging, or DC-DC conversion.

[0108] In some implementations, the PMIC 514 may control or otherwise be part of various power saving mechanisms of the UE 500. The battery 518 may power the UE 500, but in some examples, the UE 500 may be installed and deployed in a fixed location and may have a power source coupled to the power grid. The battery 518 may be a lithium-ion battery, a metal-air battery (such as a zinc-air battery, an aluminum-air battery, a lithium-air battery, etc.). In some implementations, such as in vehicle-based applications, the battery 518 may be a typical lead-acid automotive battery.

[0109] Figure 6 An access node 600 (e.g., a base station or gNB) according to some implementations is illustrated. The access node 600 may be similar to Figure 1 The access node 600 may include a processor 602, an RF interface circuit 604, a core network (CN) interface circuit 606, a memory / storage device circuit 608, and one or more antennas 610.

[0110] The components of access node 600 may be coupled to various other components via one or more interconnects 612. Processor 602, RF interface circuitry 604, memory / storage circuitry 608 (including communication protocol stack 614), one or more antennas 610, and interconnects 612 may be similar to those of reference 1. Figure 5Like-named elements are shown and described.For example, processor 602 may include processor circuits such as, for example, baseband processor circuit (BB) 616A, central processor unit circuit (CPU) 616B, and graphics processor unit circuit (GPU) 616C.

[0111] The CN interface circuit 606 may provide a connection to a core network (e.g., a 5GC using a 5th generation core network (5GC) compatible network interface protocol such as a carrier Ethernet protocol or some other suitable protocol). Network connectivity may be provided to / from the access node 600 via optical fiber or wireless backhaul. The CN interface circuit 606 may include one or more dedicated processors or FPGAs for communicating using one or more of the aforementioned protocols. In some implementations, the CN interface circuit 606 may include multiple controllers for providing connectivity to other networks using the same or different protocols.

[0112] As used herein, the terms "access node", "access point", etc. may be described as equipment that provides radio baseband functionality for data and / or voice connections between a network and one or more users. These access nodes may be referred to as BS, gNB, RAN node, eNB, NodeB, RSU, TRxP or TRP, etc., and may include ground stations (e.g., terrestrial access points) or satellite stations that provide coverage within a geographic area (e.g., a cell). As used herein, the terms "NG RAN node", etc. may refer to an access node 600 (e.g., a gNB) operating in an NR or 5G system, and the terms "E-UTRAN node", etc. may refer to an access node 600 (e.g., an eNB) operating in an LTE or 4G system. According to various specific implementations, the access node 600 may be implemented as one or more of a dedicated physical device (such as a macrocell base station) and / or a low power (LP) base station for providing a femtocell, picocell or other similar cell with a smaller coverage area, smaller user capacity or higher bandwidth than a macrocell.

[0113] In some implementations, all or part of the access node 600 may be implemented as one or more software entities running on a server computer as part of a virtual network that may be referred to as a CRAN and / or a virtual baseband unit pool (vBBUP). In a V2X scenario, the access node 600 may be or act as a "road side unit". The term "road side unit" or "RSU" may refer to any traffic infrastructure entity used for V2X communications. The RSU may be implemented in or by a suitable RAN node or a stationed (or relatively stationed) UE, where an RSU implemented in or by a UE may be referred to as a "UE-type RSU", an RSU implemented in or by an eNB may be referred to as an "eNB-type RSU", an RSU implemented in or by a gNB may be referred to as a "gNB-type RSU", and so on.

[0114] For ease of description, various components may be described as performing one or more tasks. Such descriptions should be interpreted as including the phrase "configured to". The description of a component being configured to perform one or more tasks is expressly intended to not invoke 35 USC § 112 (f) interpretation of that component.

[0115] For one or more specific implementations, at least one of the components shown in one or more of the foregoing figures may be configured to perform one or more operations, techniques, processes, or methods described in the following example section. For example, the baseband circuit described above in conjunction with one or more of the foregoing figures may be configured to operate according to one or more of the examples described below. For another example, the circuits associated with the UE, base station, network element, etc. described above in conjunction with one or more of the foregoing figures may be configured to operate according to one or more of the examples shown in the example section below.

[0116] Example

[0117] In the following sections, additional exemplary embodiments are provided.

[0118] Embodiment 1 includes one or more processors of a first user equipment (UE), wherein the one or more processors are configured to perform operations, the operations comprising: detecting a listen-before-talk (LBT) failure on a channel of a side link interface used to communicate with a second UE, wherein the first UE and the second UE are served by a base station; and in response to detecting the LBT failure on the channel, performing a recovery process, the recovery process comprising reporting LBT failure information to at least one of the base station or the second UE.

[0119] Embodiment 2 is one or more processors according to embodiment 1, wherein detecting the LBT failure on the channel includes: detecting a threshold number of LBT failure instances on the channel before the LBT failure detection timer expires, wherein the LBT failure detection timer is restarted when the LBT failure instance is detected.

[0120] Embodiment 3 is one or more processors according to any one of embodiments 1 to 2, wherein executing the recovery process includes: declaring a radio link failure of the channel; triggering the upper layer of the first UE to run a keep-alive check; and in response to determining that the first UE is in a connected state, reporting the LBT failure information to the base station.

[0121] Embodiment 4 is one or more processors according to any one of embodiments 1 to 2, wherein executing the recovery process includes: selecting at least one new component carrier from multiple component carriers used for carrier aggregation that is different from the initial component carrier on which the LBT failure is detected; and reporting the LBT failure information to the second UE via the at least one new component carrier.

[0122] Embodiment 5 is one or more processors according to any one of Embodiments 1 to 2, wherein executing the recovery process includes: in response to determining that the UE is not in a connected state, entering the connected state for failure information reporting; and reporting the LBT failure information to the base station via the Uu interface.

[0123] Embodiment 6 is one or more processors according to any one of embodiments 1 to 2, wherein the channel is a first channel, and wherein executing the recovery process includes: starting a timer for reporting the failure information via an exception resource pool of the side link interface; attempting to perform LBT on a second channel using the exception resource pool; if the LBT succeeds before the timer expires, stopping the timer; and if the LBT is unsuccessful before the timer expires, declaring a radio link failure of the first channel.

[0124] Embodiment 7 is one or more processors according to any one of embodiments 1 to 6, and the operation also includes: generating a message, the message including the LBT failure information and at least one of the following items: (i) carrier information, (ii) transmission type, (iii) measurement results of the side link interface, (iv) measurement results of the Uu interface, or (iv) playback type.

[0125] Embodiment 8 is one or more processors according to embodiment 7, wherein the transmission type includes a sidelink synchronization signal block (SL-SSB), a physical sidelink feedback channel (PSFCH), a physical sidelink control channel (PSCCH), a sidelink data radio bearer (SL-DRB), a sidelink signaling radio bearer 0 (SL-SRB0), SL-SRB1, SL-SRB2, SL-SRB3 or SL-SRB4.

[0126] Embodiment 9 is one or more processors according to embodiment 7, wherein the play type includes broadcast, multicast, or unicast.

[0127] Embodiment 10 is one or more processors according to embodiment 7, wherein the message is one of the following: a PC5 radio resource control (RRC) message, a sidelink medium access control (MAC) control element (CE), a cause value field in a Uu MAC-CE or Uu RRC message.

[0128] Embodiment 11 is one or more processors according to embodiment 10, wherein the sidelink MAC-CE is assigned a highest priority channel access priority class (CAPC).

[0129] Embodiment 12 is one or more processors according to embodiment 10, wherein during a sidelink logical channel prioritization (LCP) process, the sidelink MAC-CE has a priority between data of a sidelink control channel (SCCH) and channel state information (CSI) reporting the MAC-CE.

[0130] Embodiment 13 is one or more processors according to embodiment 10, wherein during the Uu logical channel prioritization (LCP) process, the Uu MAC-CE has a priority between the LBT failure MAC-CE and the MAC-CE for prioritized SL buffer status report (SL-BSR).

[0131] Embodiment 14 is one or more processors according to any one of embodiments 1 to 13, wherein reporting LBT failure information to at least one of the base station or the second UE includes: reporting the LBT failure information to both the base station and the second UE.

[0132] Embodiment 15 may include a non-transitory computer storage medium encoded with instructions that, when executed by one or more computers, cause the one or more computers to perform operations according to any one of Embodiments 1-14.

[0133] Embodiment 16 may include a system comprising one or more computers and one or more storage devices, on which are stored operable instructions that, when executed by the one or more computers, cause the one or more computers to perform operations according to any one of Embodiments 1 to 14.

[0134] Embodiment 17 may include a method for performing the operations according to any one of Embodiments 1-14.

[0135] Embodiment 18 may include an apparatus comprising logic components, modules, or circuits for performing one or more elements of the operations described in or related to any of Embodiments 1 to 14, or any other operations or processes described herein.

[0136] Embodiment 19 may include methods, techniques or processes according to or related to the operations of any one of Embodiments 1 to 14, or portions or components thereof.

[0137] Embodiment 20 may include a device comprising: one or more processors and one or more computer-readable media, wherein the one or more computer-readable media include instructions that, when executed by the one or more processors, cause the one or more processors to perform operations according to any one of Embodiments 1 to 14 or methods, techniques, or processes related thereto, or portions thereof.

[0138] Embodiment 21 may include a signal as described or related to any one of embodiments 1 to 14, or a portion or component thereof.

[0139] Embodiment 22 may include a datagram, information element (IE), packet, frame, segment, PDU or message, or a portion or component thereof, as described or associated with any one of Embodiments 1 to 14, or otherwise described in the present disclosure.

[0140] Embodiment 23 may include a signal encoded with data as described or associated with any one of Embodiments 1 to 14, or a portion or component thereof, or otherwise described in this disclosure.

[0141] Embodiment 24 may include a signal encoded with a datagram, IE, packet, frame, segment, PDU or message as described or associated with any of Embodiments 1 to 14, or a portion or component thereof, or otherwise described in the present disclosure.

[0142] Embodiment 25 may include an electromagnetic signal carrying computer-readable instructions, wherein execution of these computer-readable instructions by one or more processors will cause the one or more processors to perform operations according to any one of Embodiments 1 to 14 or methods, techniques or processes related thereto, or portions thereof.

[0143] Embodiment 26 may include a computer program including instructions, wherein execution of the program by a processing element causes the processing element to perform operations according to any one of embodiments 1 to 14 or methods, techniques or processes related thereto, or portions thereof. The operations or actions performed by the instructions executed by the processing element may include operations according to any one of embodiments 1 to 14.

[0144] Embodiment 27 may include signals in a wireless network as shown and described herein.

[0145] Embodiment 28 may include a method of communicating in a wireless network as shown and described herein.

[0146] Embodiment 29 may include a system for providing wireless communication as shown and described herein. The operations or actions performed by the system may include operations according to any one of Embodiments 1 to 14.

[0147] Embodiment 30 may include an apparatus for providing wireless communication as shown and described herein. The operations or actions performed by the apparatus may include operations according to any one of Embodiments 1 to 14.

[0148] The operations of previously described embodiments 1 to 14 can be implemented using a computer-implemented method; a non-transitory computer-readable medium storing computer-readable instructions to perform the computer-implemented method; and a computer system comprising a computer memory interoperably coupled to a hardware processor, the hardware processor being configured to execute the computer-implemented method or instructions stored on the non-transitory computer-readable medium.

[0149] Unless explicitly stated otherwise, any of the above embodiments may be combined with any other embodiment (or combination of embodiments). The foregoing description of one or more specific implementations provides illustration and description, but is not intended to be exhaustive or to limit the scope of the specific implementations to the precise form disclosed. Modifications and variations are possible in view of the above teachings or may be obtained from the practice of various specific implementations.

[0150] Although the above specific implementations have been described in considerable detail, numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to include all such variations and modifications.

[0151] It is understood that the use of personally identifiable information should be subject to privacy policies and practices that are generally recognized to meet or exceed industry or government requirements for maintaining user privacy. Specifically, personally identifiable information data should be managed and processed to minimize the risk of unintentional or unauthorized access or use, and the nature of the authorized use should be clearly stated to users.

Claims

1. One or more processors of a first user equipment (UE), the one or more processors configured to perform operations comprising: detecting a listen-before-talk (LBT) failure on a channel of a sidelink interface used for communicating with a second UE, wherein the first UE and the second UE are served by a base station; as well as In response to detecting the LBT failure on the channel, performing a recovery process, the recovery process including reporting LBT failure information to at least one of the base station or the second UE.

2. The one or more processors of claim 1 , wherein detecting the LBT failure on the channel comprises: A threshold number of LBT failure instances on the channel are detected before an LBT failure detection timer expires, wherein the LBT failure detection timer is restarted when an LBT failure instance is detected.

3. One or more processors according to any one of claims 1 to 2, wherein performing the recovery process comprises: declaring a radio link failure for said channel; triggering an upper layer of the first UE to run a keep-alive check; as well as In response to determining that the first UE is in a connected state, reporting the LBT failure information to the base station.

4. The one or more processors of any one of claims 1 to 2, wherein performing the recovery process comprises: selecting at least one new component carrier from a plurality of component carriers for carrier aggregation that is different from an initial component carrier on which the LBT failure is detected; as well as The LBT failure information is reported to the second UE via the at least one new component carrier.

5. The one or more processors of any one of claims 1 to 2, wherein performing the recovery process comprises: In response to determining that the UE is not in a connected state, entering the connected state for failure information reporting; as well as Report the LBT failure information to the base station via the Uu interface.

6. The one or more processors of any one of claims 1 to 2, wherein the channel is a first channel, and wherein performing the recovery process comprises: Starting a timer for reporting the failure information via an exception resource pool of the side link interface; attempting to perform LBT on a second channel using the exception resource pool; If the LBT succeeds before the timer expires, stopping the timer; and If the LBT is unsuccessful before the timer expires, a radio link failure is declared for the first channel.

7. The one or more processors of any one of claims 1 to 6, the operations further comprising: A message is generated, the message including the LBT failure information and at least one of the following: (i) carrier information, (ii) transmission type, (iii) measurement results of the sidelink interface, (iv) measurement results of the Uu interface, or (iv) playback type.

8. One or more processors according to claim 7, wherein the transmission type comprises a sidelink synchronization signal block (SL-SSB), a physical sidelink feedback channel (PSFCH), a physical sidelink control channel (PSCCH), a sidelink data radio bearer (SL-DRB), a sidelink signaling radio bearer 0 (SL-SRB0), SL-SRB1, SL-SRB2, SL-SRB3 or SL-SRB4.

9. The one or more processors of claim 7, wherein the play type comprises broadcast, multicast, or unicast.

10. The one or more processors of claim 7, wherein the message is one of: a PC5 radio resource control (RRC) message, a sidelink medium access control (MAC) control element (CE), a Uu MAC-CE, or a cause value field in a Uu RRC message.

11. The one or more processors of claim 10, wherein the sidelink MAC-CE is assigned a highest priority channel access priority class (CAPC).

12. One or more processors according to claim 10, wherein during a sidelink logical channel prioritization (LCP) process, the sidelink MAC-CE has a priority between a channel state information (CSI) reporting MAC-CE and data of a sidelink control channel (SCCH).

13. The one or more processors of claim 10, wherein during a Uu Logical Channel Prioritization (LCP) procedure, the Uu MAC-CE has a priority between an LBT Failure MAC-CE and a MAC-CE for a prioritized SL Buffer Status Report (SL-BSR).

14. The one or more processors of any one of claims 1 to 13, wherein reporting LBT failure information to at least one of the base station or the second UE comprises: The LBT failure information is reported to both the base station and the second UE.

15. A non-transitory computer storage medium encoded with instructions that, when executed by one or more computers, cause the one or more computers to perform the operations of any one of claims 1 to 14.

16. A system, comprising one or more computers and one or more storage devices, wherein the one or more storage devices store operable instructions, which, when executed by the one or more computers, cause the one or more computers to perform the operations according to any one of claims 1 to 14.

17. A method for performing the operations according to any one of claims 1 to 14.

Images