Inter-UE coordination for beam based sidelink communication

Abstract

Systems and methods include transmitting, to a first user equipment (UE) from a second UE, an inter-UE coordination (IUC) request for resource allocation information for beam based sidelink communication; receiving, at the second UE from the first UE, the IUC information specifying a beam identifier and one or more available resources or non-available resources for the sidelink communication; and performing, by the second UE, a sidelink communication using the identified beam.

Description

INTER-UE COORDINATION FOR BEAM BASED SIDELINK COMMUNICATIONCLAIM OF PRIORITY

[0001] This application claims priority under 35 U.S.C. §119(e) to U.S. Patent Application Serial No. 63 / 605,423, filed on December 1, 2023, the entire contents of which are hereby incorporated by reference.BACKGROUND

[0002] Wireless communication networks provide integrated communication platforms and telecommunication services to wireless user devices. Example telecommunication services include telephony, data (e.g., voice, audio, and / or video data), messaging, and / or other services. The wireless communication networks have wireless access nodes that exchange wireless signals with the 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). The wireless communication networks facilitate mobile broadband service using technologies such as OFDM, multiple input multiple output (MIMO), advanced channel coding, massive MIMO, beamforming, and / or other features.SUMMARY

[0003] UEs coordinate with one another to determine which resources are to be used for SL-U communication between the UEs. In a first inter-UE coordination (IUC) scheme, a first UE sends coordination to a second UE. The coordination information sent from the first UE specifies the preferred or non-preferred resources for the second UE to transmit to the first UE. This is also called a proactive IUC scheme with respect to the first UE. In a second IUC scheme, a first UE sends coordination information that indicates the presence of expected or potential resource conflicts on the resources indicated by the sidelink control information (SCI) sent to the first UE by a second UE. The indication can be a single bit using a physical sidelink feedback channel (PSFCH) occasion.

[0004] In an aspect, a method includes transmitting, to a first user equipment (UE) from a second UE, a request for inter-UE coordination (IUC) information including resource allocation information for beam based sidelink communication. The method includes receiving, at the second UE from the first UE, the IUC information specifying a beam identifier and one or more available resources or non-available resources for the sidelink communication. The method includes performing, by the second UE, a sidelink communication using the identified beam.

[0005] In some implementations, the IUC information causes a physical layer in the second UE to exclude in resource selection or reselection the one or more available resources of the IUC information from candidate single-slot resources obtained during a resource selection procedure. In some implementations, at least one of the request for IUC information or the IUC information includes a transmitter beam identifier specifying a transmitter beam for transmitting a physical sidelink control channel (PSCCH) or a physical sidelink shared channel (PSSCH). In some implementations, at least one of the request for IUC information or the IUC information includes a receiver beam identifier specifying a receiving beam for receiving a PSCCH or a PSSCH.

[0006] In some implementations, at least one of the request for IUC information or the IUC information is transmitted in a medium access control (MAC) control element (CE). In some implementations, at least one of the request for IUC information or the IUC information is transmitted in sidelink control information (SCI) format 2. In some implementations, at least one of the request for IUC information is transmitted with beam indication message or a channel state information reference signal. In some implementations, the IUC information istransmitted with beam reporting information. In some implementations, the IUC information includes a field specifying a number of subchannels associated with a transmitter beam. In some implementations, the IUC information includes a field specifying one or more RB sets associated with a transmitter beam. In some implementations, the IUC information includes a field specifying one or more slots associated with a transmitter beam.

[0007] In some implementations, a sensing window is configured to have a length that enables multiple beam measurements for a slot. In some implementations, a sensing window for the first UE is configured to have a length that enables multiple beam measurements for a slot, and wherein the IUC information includes resources associated with a beam measurement by the first UE associated with a specified transmitter beam for the second UE. in some implementations, the sensing window is longer than 1100 milliseconds. In some implementations, the sensing window for the first UE is less than 100 milliseconds.

[0008] In some implementations, the method includes receiving, at the second UE, a set of all candidate single slot resources when a threshold number of identified candidate single slot resources does not exceed a threshold. In some implementations, the IUC information specifying the one or more available resources or non-available resources excludes a slot from the one or more available resources when the first UE is a receiver UE and expects to receive a transmission during the slot using a different beam or when the first UE expects to transmit during the slot.

[0009] In some implementations, the IUC information specifying the one or more available resources or non-available resources excludes a slot from the one or more available resources when the first UE measures a reference signal receive power (RSRP) below a threshold for a receiver beam associated with the slot. In some implementations, the IUC information specifying the one or more available resources or non-available resources excludes a slot from the one or more available resources when the first UE measures a reference signal receive power (RSRP) below a threshold for a transmitter beam associated with the slot. In some implementations, the method includes adjusting the threshold for the RSRP based on a number of available resources.

[0010] In an aspect, a method includes generating inter-UE coordination (IUC) information for resource allocation for beam based sidelink communication. The IUC information specifies at least one conflicting resource based on determining a conflict between a first beam and a second beam for a second UE. The method includes transmitting, from a first user equipment(UE) to the second UE, feedback data, the feedback data specifying the at least one conflicting resource.

[0011] In some implementations, the first UE is an intended receiver of the second UE, and the first UE does not expect to perform reception on a slot using a receiver beam for the second UE in some implementations, the IUC information specifying the at least one conflicting resource wherein a difference between a first RSRP of a first beam associated with the second UE and a second RSRP of the first beam does not satisfy a threshold difference. In some implementations, the IUC information is transmitted using a wide beam. In some implementations, the IUC information is transmitted using a same beam as a transmitting beam for PSCCH or PSSCH to the second UE or a third UE. in some implementations, the IUC information is transmitted using a same beam as a transmitting beam for PSFCH to the second UE or a third UE. In some implementations, the IUC information is transmitted using a corresponding beam to a receiver beam for PSFCH from the second UE or a third UE. In some implementations, the IUC information is transmitted using a corresponding beam to a receiver beam for PSCCH or PSSCH from the second UE or a third UE.

[0012] In an aspect, a system comprises one or more computers and one or more storage devices on which are stored instructions that are operable, when executed by the one or more computers, to cause the one or more computers to perform operations of the foregoing processes.

[0013] In an aspect, a system comprises one or more computers and one or more storage devices on which are stored instructions that are operable, when executed by the one or more computers, to cause the one or more computers to perform operations of the foregoing processes.

[0014] In an aspect, a non-transitory computer storage medium is encoded with instructions that, when executed by one or more computers, cause the one or more computers to perform operations of the method of any of foregoing processes. In an aspect, an apparatus comprises one or more baseband processors configured to perform operations of the method of any of the foregoing processes.

[0015] The details of one or more embodiments of these systems and methods are set forth in the accompanying drawings and the description below. 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 FIGURES

[0016] FIG. 1 illustrates an example communication system that includes sidelink communications, according to some implementations.

[0017] FIG. 2A illustrates an example scheme for inter-UE coordination for resource allocation (RA).

[0018] FIG. 2B illustrates an example scheme for inter-UE coordination for resource allocation.

[0019] FIG. 3 illustrates an example process for a beam based inter-UE coordination for resource allocation based on the scheme of FIG. 2 A.

[0020] FIG. 4 illustrates an example network including UEs for a beam based inter-UE coordination for resource allocation based on the scheme of FIG. 2B.

[0021] FIG. 5 illustrates an example network including UEs for a beam based inter-UE coordination for resource allocation based on the scheme of FIG. 2B.

[0022] FIG. 6 illustrates a flowchart of an example method for IUC for beam based sidelink communication.

[0023] FIG. 7 illustrates a flowchart of an example method for IUC for beam based sidelink communication.

[0024] FIG. 8 illustrates an example user equipment (UE).DETAILED DESCRIPTION

[0025] In sidelink (SL) communications, a first UE is configured to communicate directly with a second UE without direct base station involvement. For SL transmissions, a UE is configured to perform operations based on available resource block (RB) sets in the unlicensed spectrum. In the unlicensed spectrum, the UE is competing with other technologies (e.g., WLAN devices) for channel access. The first UE selects a channel for sidelink operation using unlicensed spectrum (SL-U) communications and subsequently can transmit to another UE using the selected channel. The UE may not always successfully complete a transmission, such as physical sidelink shared channel (PSSCH) or physical sidelink control channel (PSCCH) transmission.

[0026] Each UE for a SL communication is configured to perform beam management operations for sending and / or receiving SL transmissions. Beam management includes initial beam-pairing between a transmitting UE (Tx UE) and a receiving UE (Rx UE), beam maintenance by the UE, and beam failure recovery by the UE. For beam pairing, each of the Tx UE and the Rx UE selects a respective beam from a set of available candidate beams. The UEs can be configured to use some of the legacy SL channel state information (CSI) framework and Uu beam management framework. For frequency range 2 (FR2) communications, the SL communications are unicast.

[0027] For mode 2 operation using frequency range 1 (FR1) transmissions that are generally broadcast, a Tx UE (e.g., UE B) can coordinate with a helper UE (e.g., UE A) to determine which resources are to be used for SL-U communication between the UEs. In an aspect, a helper UE can monitor sidelink channels and detect resource reservation collisions. For example, a roadside unit can act as a helper UE.

[0028] In a first inter-UE coordination (IUC) scheme, described in further detail below with respect to FIG. 2A, a first UE performs sensing operations and sends coordination information to a second UE. The coordination information sent from the first UE specifies the preferred or non-preferred resources for the second UE to transmit to the first UE. This is also called a proactive IUC scheme with respect to the first UE. In a second IUC scheme, described in further detail below with respect to FIG. 2B, a first UE sends coordination information that indicates the presence of expected or potential resource conflicts on the resources indicated by the sidelink control information (SCI) sent to the first UE by a second UE. The indication can be a single bit using a physical sidelink feedback channel (PSFCH) occasion.

[0029] This disclosure describes how the first and second IUC schemes are modified for FR2 operation in which UEs perform unicast transmissions on respective selected Tx / Rx beams. In SL FR1, mode 2 resource selection procedures do not consider the beam direction, and the IUC schemes to enhance resource selection reliability is not beam based. For FR2 mode 2 resource selection, a resource selection from the helper UE (e.g., UE A) is enhanced to enable beam selection for the SL communications between the Tx and Rx UEs. The first, proactive IUC scheme 1 in SL FR2 includes beam based operations that enable beam management between the UEs, such as beam pairing, beam maintenance, and beam failure recovery. The first IUC scheme for FR2 enables a beam based IUC request from the Tx UE to the Rx UE. The configuration for the first IUC scheme is subsequently described in greater detail, including the contents of the request, configurations for the container of the request, and the configurations of the Tx and Rx beams from the IUC request. The first IUC scheme for FR2 enables a beam based IUC information from the Rx UE to the Tx UE. The configuration for the first IUC scheme is subsequently described in greater detail, including the contents of the IUC information, configurations for the container of the IUC information, and the configurations of the Tx and Rx beams from the IUC information. Parameters for beam based resource selection for mode 2 resource selection at the helper UE (e.g., UE A) are subsequently described in detail. Further modifications to the first IUC scheme include modifications to the set of determined preferred or non-preferred resources for beam based resource selection. The process for how the UEs use the received preferred or non-preferred resource set in resource selection is described herein. The Tx beam and Rx beam for each of the IUC request and the IUC information are subsequently described. These are modified from the configuration for sidelink-FRl in which mode 2 resource allocation scheme includes sensing, by the helper UE, using an omni-directional beam.

[0030] This disclosure further describes how the second IUC scheme is modified to consider beam direction. Specifically, for SL FR 1, mode 2 resource selection procedures do not consider beam direction. The second IUC scheme, in which the helper UE informs the Tx UE of potential conflicts, considers only omnidirectional transmissions. The legacy IUC scheme considers collisions in the time and frequency domains without considering beam direction. As described in the present disclosure, for FR2, the IUC scheme is modified to consider both the Tx beam and the Rx beam for determining resource collisions.

[0031] FIG. 1 illustrates an example communication system 100 that includes sidelink communications, according to some implementations. It is noted that the system of FIG. 1 ismerely one example of a possible system, and that features of this disclosure may be implemented in other wireless communication systems.

[0032] The following description is provided for an example communication system that operates in conjunction with fifth generation (5G) networks as provided by 3GPP technical specifications. However, the example implementations are not limited in this regard and the described examples may apply to other networks that may benefit from the principles described herein, such as 3GPP Long Term Evolution (LTE) networks, Wi-Fi, or Worldwide Interoperability for Microwave Access (WiMaX) networks, and the like. Furthermore, other types of communication standards are possible, including future 3 GPP systems (e.g., Sixth Generation (6G)), IEEE 802.16 protocols, or the like. While aspects may be described herein using terminology commonly associated with 5G NR, aspects of the present disclosure can be applied to other systems, such as 3G, 4G, and / or systems subsequent to 5G (e.g., 6G).

[0033] Frequency bands for 5G NR may be separated into two different frequency ranges. Frequency Range 1 (FR1) may include frequency bands operating in sub-6 GHz frequencies, some of which are bands that may be used by previous standards and may potentially be extended to cover new spectrum offerings from 410 Megahertz (MHz) to 7125 MHz. Frequency Range 2 (FR2) may include frequency bands from 24.25 Gigahertz (GHz) to 52.6 GHz. Bands in the millimeter wave (mmWave) range of FR2 may have smaller coverage but potentially higher available bandwidth than bands in the FR1.

[0034] As shown, the communication system 100 includes a number of user devices. 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 station 110-1 and base station 110-2 are collectively referred to as “base station 110” or “base stations 110”), two cells 115 (cell 115-1 and cell 115-2 are collectively referred to as “cell 115” or “cells 115”), and one or more servers 135 in a core network (CN) 140 that is connected to the Internet 145.

[0035] In some implementations, the UEs 105 can directly communicate with base stations 110 via links 120 (link 120-1 and link 120-2 are collectively referred to as “link 120” or “links 120”), which utilize a direct interface with the base stations referred to as a “Uu interface.” Each of the links 120 can represent one or more channels. The links 120 are illustrated as an air interface to enable communicative coupling, and can be consistent with cellular communication protocols, such as a GSM protocol, a CDMA network protocol, a UMTSprotocol, a 3 GPP LTE protocol, an Advanced long term evolution (LTE-A) protocol, a LTE- based access to unlicensed spectrum (LTE-U), a 5G protocol, a NR protocol, an NR-based access to unlicensed spectrum (NR-U) protocol, and / or any of the other communications protocols discussed herein.

[0036] As shown, certain user devices may be able to conduct communications with one another directly, e.g., without an intermediary infrastructure device such as base station 110-1. In this example, UE 105-1 may conduct communications directly with UE 105-2. Similarly, the UE 105-2 may conduct communications directly with UE 105-1. Such peer-to-peer communications may utilize a “sidelink” interface such as a PC5 interface. In certain implementations, the PC5 interface supports direct cellular communication between user devices (e.g., between UEs 105), while the Uu interface supports cellular communications with infrastructure devices such as base stations. For example, the UEs 105 may use the PC5 interface for a radio resource control (RRC) signaling exchange between the UEs (also called PC5-RRC signaling). The PC5 / Uu interfaces are used only as an example, and PC5 as used herein may represent various other possible wireless communications technologies that allow for direct sidelink communications between user devices, while Uu in turn may represent cellular communications conducted between user devices and infrastructure devices, such as base stations.

[0037] In some implementations, the UEs 105 may be configured with parameters for communicating via the Uu interface and / or the sidelink interface. In some examples, the UEs 105 may be “pre-configured” with some parameters. In these examples, the parameters may be hardwired into the UEs 105 or coded into spec. Additionally and / or alternatively, the UEs 105 may receive the parameters from the one or more of the base stations 110.

[0038] To transmit / receive data to / from one or more base stations 110 or UEs 105, the UEs 105 may include a transmitter / receiver (or alternatively, a transceiver), memory, one or more processors, and / or other like components that enable the UEs 105 to operate in accordance with one or more wireless communications protocols and / or one or more cellular communications protocols. The UEs 105 may have multiple antenna elements that enable the UEs 105 to maintain multiple links 120 and / or sidelinks 125 to transmit / receive data to / from multiple base stations 110 and / or multiple UEs 105. For example, as shown in FIG. 1, UE 105-1 may connect with base station 110-1 via link 120 and simultaneously connect with UE 105-2 via sidelink 125.

[0039] In some implementations, one or more sidelink radio bearers may be established on the sidelink 125. The sidelink radio bearers can include signaling radio bearers (SL-SRB) and / or data radio bearers (SL-DRB).

[0040] 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), Physical Sidelink Feedback Channel (PSFCH), and / or any other like communications channels. The PSFCH carries feedback related to the successful or failed reception of a sidelink transmission. The PSSCH can be scheduled by sidelink control information (SCI) carried in the sidelink PSCCH. In some examples, the sidelink interface can operate on an unlicensed spectrum (e.g., in the unlicensed 5 Gigahertz (GHz) and 6 GHz bands) or a (licensed) shared spectrum.

[0041] In one example, the sidelink interface implements vehicle-to-everything (V2X) communications. The V2X communications may, for example, adhere to 3GPP Cellular V2X (C-V2X) specifications, or to 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 as well as short- to medium -range (e.g., non- cellular) communications. Cellular-capable V2X communications may be called Cellular V2X (C-V2X) communications. C-V2X systems may use various cellular radio access technologies (RATs), such as 4GLTE or 5GNRRATs (orRATs subsequent to 5G, e.g., 6GRATs). Certain LTE standards usable in V2X systems may be called LTE-Vehicle (LTE-V) standards. As used herein in the context of V2X systems, and as defined above, the term “user devices” may refer generally to devices that are associated with mobile actors or traffic participants in the V2X system, e.g., mobile (able-to-move) communication devices such as vehicles, pedestrian user equipment (PUE) devices, and roadside units (RSUs).

[0042] In some implementations, UEs 105 may be physical hardware devices capable of running one or more applications, capable of accessing network services via one or more radio links 120 with a corresponding base station 110 (also referred to as a “serving” base station), and capable of communicating with one another via sidelink 125. Link 120 may allow the UEs 105 to transmit and receive data from the base station 110 that provides the link 120. The sidelink 125 may allow the UEs 105 to transmit and receive data from one another. The sidelink 125 between the UEs 105 may include one or more channels for transmitting information fromUE 105-1 to UE 105-2 and vice versa and / or between UEs 105 and UE-type RSUs and vice versa.

[0043] In some implementations, the base stations 110 are capable of communicating with one another over a backhaul connection 130 and may communicate with the one or more servers 135 within the CN 140 over another backhaul connection 133. The backhaul connections can be wired and / or wireless connections.

[0044] In some implementations, the UEs 105 are configured to use a resource pool for sidelink communications. A sidelink resource pool defines the time-frequency resources used for sidelink communications, and may be divided into multiple time slots, frequency channels, and frequency sub-channels. In some examples, the UEs 105 are synchronized and perform sidelink transmissions aligned with slot boundaries. A UE may be expected to select several slots and sub-channels for transmission of the transport block. In some examples, a UE may use different sub-channels for transmission of the transport block across multiple slots within its own resource selection window.

[0045] As described herein, for FR2 mode 2 resource selection, either of the UEs 105 (e.g., UE 105-1 or UE 105-2) can be a helper UE that assist the other UE for resource selection. In an example, a helper UE can be UE 105-1. The helper UE 105-1 can perform beam based operations that enable beam management between the UEs, such as beam pairing, beam maintenance, and beam failure recovery. The beam based operations enable the other UE 105- 2 to perform beam selection. The beam based operations can include a beam based IUC request from the Tx UE (e.g., UE 105-2) to the Rx UE (e.g., UE 105-1), operating as the helper UE. The beam based operations are in contrast to using omni-directional beams for the resource selection operations. The helper UE (e.g., UE 105-1) can perform beam based resource selection for mode 2 resource selection. In addition, the helper UE (e.g., UE 105-1) can inform the transmitting UE (e.g., UE 105-2) of potential resource conflicts, considering beam direction for both the UE 105-1 and the UE 105-2.

[0046] In some implementations, an exceptional resource pool may be configured for the UEs 105, perhaps by the base stations 110. The exceptional resource pool includes resources that the UEs 105 can use in exceptional cases, such as Radio Link Failure (RLF). The exceptional resource pool may include resources selected based on a random allocation of resources.

[0047] In some implementations, a UE that is initiating a communication with another UE is referred to as a transmitter UE (TX UE), and the UE receiving the communication is referredto as a receiver UE (RX UE). For example, UE 105-1 may be a TX UE and UE 105-2 may be an RX UE. Although FIG. 1 illustrates a single TX UE communicating with a single RX UE, a TX UE may communicate with more than one RX UE via sidelink.

[0048] In some implementations, a TX UE that is initiating sidelink communication may determine the available resources (e.g., sidelink resources) and may select a subset of these resources to communicate with an RX UE based on a resource allocation scheme. Example resource allocation schemes include Mode 1 and Mode 2 resource allocation schemes. In Mode 1 resource allocation scheme (referred to as “Mode 1”), the resources are allocated by a network node for in-coverage UEs. In Mode 2 resource allocation scheme (referred to as “Mode 2”), the TX UE selects the sidelink resources (e.g., sidelink transmission resources). For Mode 2 resource allocation, the Rx UE can function as a helper UE to assist the Tx UE in selecting sidelink resources. The Rx UE and the Tx UE coordinate with each other to select resources available to both UEs for transmissions between the Rx and Tx UEs. When using beam based communications in FR2, the Rx UE and Tx UE coordinate with each other to select preferred beams for communication, in addition to selecting other resources such as slots, subchannels, and RB sets. The beams that are selected can be based on the particular beams used for the coordination between the Rx UE and the Tx UE, as described herein. In this case, the UEs 105- 1 and 105-2 can be the Tx UE and Rx UE, respectively (or vice versa).

[0049] In some implementations, the communication system 100 supports different cast types, including unicast, broadcast, and groupcast (or multicast) communications. Unicast refers to direction communications between two UEs. Broadcast refers to a communication that is broadcast by a single UE to a plurality of other UEs. Groupcast refers to communications that are sent from a single UE to a set of UEs that satisfy a certain condition (e.g., being a member of a particular group).

[0050] FIG. 2A illustrates an example scheme 200 for inter-UE coordination for resource allocation (RA). This scheme shows a proactive scheme in which a UE (such as one of UEs 105 of FIG. 1) is configured to send coordination information that specifies a set of preferred or non-preferred resources for SL-U transmissions by a second UE. The example IUC scheme 200 shows that the first UE (e.g., UE-A) communications to the second UE (e.g., UE-B) that a subset of resources is available, including {A3, B2, C4}. These resources are indicated to the second UE (UE-B) prior to UE-B’s resource reservation. In another example, the first UE (UE- A) can be configured to signal resources that are not preferred or unavailable for SL-Utransmissions by the UE-B. In this example, the UE-A indicates a subset of resources including {A1,A2, A4, Bl, B3, B4, Cl, C2, C3} as being unavailable. The set of resources are indicated by UE-A to UE-B before UE-B’s resource reservation occurs.

[0051] The UE-A is configured to specify the list of resources that are either available or not available using SCI or a MAC CE. The SCI or MAC CE specifies one or more RB set indexes for respective RB sets in which designated subchannels in the frequency domain are specified for use as SL-U resources.

[0052] The IUC message contents for signaling using the scheme 200 can include the following. The first UE (e.g., UE-A) is associated with a resource pool configuration or preconfiguration. The resource pool configuration or configuration enables one of the following. For the indication of a resource set, the SCI or MAC CE can specify a number A combinations of resources using either time resource indicator values (TRIV) or frequency resource indicator values (FRIV) for an indicated resource reservation period. In some implementations, the value of resource reservation period is omitted at least when indicated in an explicit request of the UE-B. in some implementations, the first resource location of each TRIV is separately indicated by the UE-A.

[0053] The second UE (UE-B) is configured to receive the preferred or non-preferred resources set in the SCI or MAC CE. The UE-B is configured to handle IUC specifying a non-preferred resource set during the resource selection procedure. Specifically, the physical layer at UE-B excludes in its resource selection or reselection the candidate single-slot resource(s) obtained after Step 6 of the resource selection procedure.

[0054] FIG. 2B illustrates an example scheme 210 for inter-UE coordination for resource allocation. The IUC scheme 210 is a reactive scheme because a first UE (UE-A) signals a potential resource conflict to UE-B, and UE-B schedules SL-U communications without using the identified conflicting resources. The coordination information sent from UE-A to UE-B indicates the presence of expected / potential resource conflicts on the resources indicated by UE-B’s SCI. As shown in FIG. 2B, the conflicting resources are shaded and labeled “UE-C,” “UE-B,” and “UE-B / UE-C.” In an aspect, the UE-A can send a PSFCH occasion instance having a format of 0 to indicate presence of expected resource conflict on reserved resource(s) indicated by UE-B’s SCI.

[0055] The UE-A can use the following PSFCH resources for IUC. In an aspect, the UE-A uses the same parameters for IUC that the UE-A uses for PSFCH for SL hybrid automaticrepeat request (HARQ) messages. In this example, the UE-A uses a same period of the PSFCH resources as for SL HARQ, a same number of cycles shift pairs in a physical resource block as for SL HARQ, and a same number of PSFCH resources for multiplexing. In another aspect, the UE-A uses a separate parameter than as for PSFCH for SL HARQ. In this example, the UE-A uses a set of PRBs for PSFCH transmission and reception designated by the parameter.

[0056] The index of a PSFCH resource of UE-A for IUC transmission can be determined in a same manner as the PSFCH for SL HARQ is determined. Specifically, the index PID is an Ll- source identifier (ID) indicated by the SCI of UE-B’s. MID is the group member identifier. In sidelink groupcast, each receiver UE uses its group member ID to determine its own PSFCH resource. The value of MID is set to 0.

[0057] FIG. 3 is a diagram that illustrates an example process 300 for performing inter-UE coordination for beam based SL communication. Process 300 is an explicit request-based IUC process. In process 300, a first UE, which is UE-A as described in relation to FIG. 2A, includes a helper UE and can be a Rx UE for beam based SL communication. The second UE, which is UE-B described in relation to FIG. 2A, is the Tx UE for the SL communication. UE-A performs (302) beam based sensing operations, as subsequently described. The UE-B sends (304) an IUC request to the UE-A. UE-A, responsive to receiving the IUC request, determines (306) a set of preferred or non-preferred resources as described in relation to FIG. 2A, while also considering beam selection for UE-B. The determination of the resources is therefore a mode 2 resource selection that is beam based. The UE-A sends (308) IUC information to UE-B. UE- B performs (310) resource selection based on the preferred or non-preferred resources specified in the IUC information from UE-A. The UE-B, as the Tx UE, sends (312) a beam based data transmission, such as for the physical sidelink control channel (PSCCH) or the physical sidelink shared channel (PSSCH), using selected resources, including a specific beam, based on the preferred or non-preferred resources specified in the IUC information. Each of the steps of process 300 is subsequently described in further detail.

[0058] The UE-A, which is the helper UE, is configured to perform (302) beam based sensing in the environment. Beam based sensing includes determining, for each of the available beams of the Tx UE, beam measurements for those beams. The beam based sensing can include performing a search over all the beams on the transmitter and the receiver sides and selecting a beam pair offering a strongest reference signal received power (RSRP) with the UE-B. TheUE-A, which is the Rx UE, is ready to receive an IUC request from the Tx UE (UE-B) for resource selection.

[0059] The UE-A receives (304) an IUC request from the transmitting UE (UE-B). The IUC request from the Tx UE includes elements similar to those included in FR1, such as a priority value, a number of available sub-channels, a resource reservation period, a resource selection window location, and a resource set type. The values are based on UE-B’s traffic.

[0060] The IUC request of the Tx UE further includes beam information for the Tx UE. For example, the IUC request specifies a Tx beam identifier (ID) that indicates a transmit beam to be used for PSCCH / PSSCH data transmissions. The Tx beam ID may be specified in terms of sidelink transmission configuration indicator (TCI) state, in terms of sidelink channel state information reference signal (CSI-RS), or in terms of a sidelink synchronization signal block (S-SSB) resource identifier. The Tx UE also provides the receiver beam identifier that specifies the receiver beam (Rx beam) that is being used to receive PSCCH / PSSCH data transmissions. The Rx beam ID may be specified in terms of the sidelink TCI state, the sidelink CSI-RS, or the S-SSB resource ID.

[0061] The Tx UE sends the IUC request to the helper UE-A in one or more of the following containers. A container includes a pre-defined transmission format for sending data from one UE to another. The ICU container be part of SCI. In an aspect, the container of IUC request can be the SCI format 2-C that is modified for beam-based transmissions. Specifically, the SCI format 2-C can include one or more additional fields or repurposed fields that specify the Tx beam ID and / or the Rx beam ID. In an aspect, the container can include an SCI stage 2 format that is entirely newly defined (e.g. format 2-D). In this case, the fields are defined to consider the beam identifier information for PSCCH / PSSCH data transmission in addition to other mode 2 information used for IUC. For example, the container of the IUC request can set the embedded SCI format field to a predefined value to indicate the new format (e.g., a value of 10).

[0062] The container of the IUC request can be a MAC CE. In an aspect, the UE-B can use the FR1 IUC request MAC CE container. This container is modified to include additional fields or purposed fields that specify the Tx beam ID and / or the Rx beam ID. In another aspect, the IUC request is a new beam-based IUC request MAC CE. In this case, the fields are defined to consider the beam identifier information for PSCCH / PSSCH data transmission in addition to other mode 2 information used for IUC.

[0063] The UE-B can transmit the IUC request information with a beam indication message or with a sidelink CSI-RS transmission. In this example, the IUC request is combined with a resource selection signal or the reference signal or measurement related message. The UE-B sends the beam indication message, and the helper UE-A passes the IUC request. Alternatively, when the UE-B sends the CSI-RS for the beam measurement and pairing procedure with the UE-A (the Rx UE), the CSI-RS include the IUC request. The UE-A can use the beam pairing process of the beam based sending (302) to receive the IUC request. Therefore, when the helper UE is the Rx UE, the CSI-RS transmission can perform the two functions including both the beam sensing and the IUC request.

[0064] The UE-B is configured to transmit the IUC request using a beam based transmission based on a particular beam configuration. The direction of the beam based transmission can include one of the following options. In an aspect, the Tx UE can send the IUC request in different directions using a beam sweeping approach. The Tx UE can send the IUC request in different directions using directional beams. In another aspect, the Tx UE can use a wide beam to send the IUC request. The beam can be less wide than an omnidirectional beam but wider than a directional beam. In another aspect, the Tx UE sends the IUC request using a same serving Tx beam as used for PSCCH / PSSCH towards UE-A. In this example, the Tx UE (UE- B) and the Rx UE (UE-A) have already completed a beam pairing process. The Tx UE therefore has selected a beam for data transmission to the Rx UE. The same transmit beam is selected for the IUC request. In another aspect, the Tx UE can use a same beam for the IUC request as selected for a physical sidelink feedback channel (PSFCH). Responsive to receiving data from the Rx UE, the Tx UE replies with an acknowledgement (ACK / NACK) on the PSFCH using a serving Tx beam that is selected for the PSFCH. In some implementations, the serving Tx beam for the PSFCH is the same beam as the serving Tx beam for the PSCCH / PSSCH data transmission. In some implementations, the serving Tx beam for the PSFCH is a different beam from the serving Tx beam for the PSCCH / PSSCH data transmission. In either scenario, the Tx UE can use either serving Tx beam for sending the IUC request. Conversely, the Tx UE (UE- B) can use a beam corresponding to the serving Rx beam from the Rx UE (UE-A) for the PSFCH feedback or corresponding to the serving Rx beam from the Rx UE for the PSCCH / PSSCH data transmission.

[0065] The UE-A is configured to receive the IUC request using a particular beam configuration. The beam configuration can include one of the following options. In an aspect, the Rx UE can receive the IUC request using a wide beam. The beam can be less wide than anomnidirectional beam (e.g., less 360 degrees), but wider than a directional beam (e.g., about 180 degrees). In another aspect, the Rx UE receives the IUC request using a same serving Rx beam as used for PSCCH / PSSCH from UE-B. In this example, the Rx UE (UE-A) and the Tx UE (UE-B) have already completed a beam pairing process. The Rx UE therefore has selected a beam for data reception from the Tx UE. The same receiving beam can be used for the IUC request. In another aspect, the Rx UE can use a same beam for receiving the IUC request as selected for the PSFCH transmission to the Tx UE. Responsive to receiving data from the Tx UE, the Rx UE replies with an acknowledgement (ACK / NACK) on the PSFCH using a serving Rx beam that is selected for receiving the PSFCH feedback from the Tx UE. In some implementations, the serving Rx beam for the PSFCH is the same beam as the serving Rx beam for the PSCCH / PSSCH data transmission. In some implementations, the serving Rx beam for the PSFCH is a different beam from the serving Rx beam for the PSCCH / PSSCH data transmission. In either scenario, the Rx UE can use either serving Rx beam for receiving the IUC request. Conversely, the Rx UE (UE-A) can use a beam corresponding to the serving Tx beam from the Tx UE (UE-B) for the PSFCH feedback or corresponding to the serving Tx beam from the Tx UE for the PSCCH / PSSCH data transmission.

[0066] The helper UE (UE-1 / Rx UE) is configured to determine (306) a set of preferred or non-preferred resources for beam based SL communication. The resource selection process is modified from the FR1 resource selection procedure. The beam based SL resource selection can be enabled or disabled per configuration or pre-configuration, such as for resource pool configuration or pre-configuration, PC5-RRC configuration, and so forth. The resource configuration procedure includes an additional higher layer parameter for specifying the beam. The Rx UE can select a beam for data transmission that is associated with the resource selection. The selected Tx beam can be the beam that corresponds to the Rx beam received in IUC request.

[0067] The beam based SL resource selection can be performed using the steps that are modified from the FR1 scenario. In Step 1 of the resource selection, the helper UE (e.g., the Rx UE) defines the candidate resources. A candidate single-slot resource for beam-based transmission Rw,x,y is defined as a set of LsubCH contiguous sub-channels with sub-channel x+j in slot tyLwhere j = 0, ..., LsubCH-l for Tx beam w. In this way, the candidate resources are defined in three dimensions including the candidate beam and the frequency, and time domains.

[0068] The resource definition can be extended to the unlicensed spectrum (e.g., for an RB set based resource pool and interlace RB based transmission). A candidate single-slot resource for beam-based transmission Rw,x,y,z is defined as a set of LsubCH contiguous sub-channels starting from sub-channel x in slot tyLin LRBset contiguous RB sets starting from RB set z for Tx beam w. This definition could be extended to cover a scenario for multiple consecutive slot transmissions. In this way, the candidate resources are defined in four dimensions including the candidate beam, the frequency and time domains, and the RB set. The SL resource definition for the unlicensed spectrum is defined further in U.S. Prov. App. No. 63 / 547,229, the entirety of which is incorporated by reference herein.

[0069] Step 2 of the beam based SL resource definition includes configuration of a sensing window size. The sensing window is defined as parameter To. If the UE intends to trigger resource selection for a given slot N, the sensing result that can be used is performed at time N-To. In an aspect, the sensing window parameter is separately configured from the rest of the resource definition. This can differ from the configuration used for omni-directional based sensing. For omnidirectional based sending, the window size is 1100 milliseconds. In an example, the configurable sensing window size is above 1100 milliseconds (ms). The UE initially has sensing results for only one beam direction for each slot (though the UE can use different beam directions for different slots), and there is a lack of sensing results in other directions for the beam -based sensing for that slot. To enable the UE to acquire more results for other slots for one or more beam directions, the sensing window size can be extended. In another aspect, the configurable sensing window size is less than 100 ms. In this example, the sensing window can be shortened because there is a higher subcarrier spacing (SCS) in FR2 and therefore more slots per millisecond (e.g., up to 8 slots per ms). There are therefore relatively more sensing results within the sensing window relative to the FR1 sensing window of the same length.

[0070] Step 5 of the beam based SL resource definition includes selecting particular resources based on whether those resources were monitored during the sending window. The UE excludes any candidate single-slot resource Rw,x,yfrom the resource set SA if the candidate single-slot meets all the following conditions. First, a resource is excluded when the UE has not monitored slot tLin Step 2 using the Rx beam corresponding to Tx beam w. IF the UE monitors the slot with a beam other than the beam that corresponds to the identified Tx beam, the result is not accurate for that slot, and the sending result is not used. Second, for any periodicity value allowed by the higher layer parameter sl-ResourceReservePeriodList and ahypothetical SCI format 1-A received in slot tLwith a 'Resource reservation period' field set to that periodicity value and indicating all sub-channels of the resource pool in this slot, condition c in step 6 would be met. Specifically, Step 5 is configured to exclude some resources from the set of candidate resources when those resources are unmonitored slots. The UE-A can try to select a resource for its data transmission, but the UE does not monitor the channel at slot n. Another UE (e.g., UE-B) can transmit on slot n and make a periodic resource reservation with periodicity of 30 slots. UE-A then may need to exclude resources on slots n+30, n+60, n+90, etc., to avoid the potential collision with UE-B’s reservation. This rule can be applied for FR2.

[0071] An additional step, called Step 5a, is performed for the beam based SL resource definition. The UE performs step 5A if a number of candidate single-slot resources Rw,x,y remaining in the set SA is smaller than a threshold percentage X*Mtotai, the set SA is initialized to the set of all the candidate single-slot resources as in Step 4. Here, the value of X is separately configured for beam based operations, which is smaller than the X value for omni-directional beam based operations. The value of X can be smaller because the sensing is beam based and there may be fewer candidate results, as many results may have already been excluded in Step 5. The threshold is generally lower for beam based sensing. The value of X is generally 5% - 20% (e.g., 5%, 10%, 20%, etc.).

[0072] Once the candidate resources are determined, the helper UE (e.g., UE-A) can provide this information to the Tx UE (e.g., UE-B). The helper UE can provide a set of preferred resources to the Tx UE or a set of unavailable or excluded resources to the Tx UE. When determining a preferred resource set, the UE can perform a modified version of Step 6a. The helper UE (e.g., the Rx UE or UE-A) excludes candidate single-slot resource(s) belonging to slot(s) where the Tx UE (e.g., UE-B) does not expect to perform SL reception of a TB due to half-duplex operation. Specifically, if the Rx UE is expecting to transmit data on a particular slot, that resource is excluded from the preferred resource set because the Rx UE cannot receive data from the Tx UE on that slot. The Rx UE also excludes candidate resources that are using a Rx beam corresponding to a Tx beam as indicated by high layer parameter. Specifically, if the Rx UE is already committed to using another beam direction for a given slot other than the corresponding direction to the Tx beam), the resource is excluded from the set of candidate slots. This can occur if the Rx UE is receiving data from a third UE during that slot. However, if the helper UE is not the Rx UE, the helper UE does not have information for future transmissions or receptions from the Rx UE and this step is skipped. In other words, this applieswhen the UE is a destination UE (the Rx UE) of the TB for whose transmission the preferred resource set is being determined, and the higher layer parameter conditionl A2SchemelDisabled is not set to 'Disabled'.

[0073] When determining a non-preferred resource set, the UE additionally performs the following steps. The UE includes resource(s) indicated by a received SCI format 1-A, satisfying at least one of the following criteria. These resources are included in the set of resources indicated as non-candidate resources, so essentially these are excluded resources. The UE includes resources in which the RSRP measurement performed for the received SCI format 1-A, using a Rx beam corresponding to a Tx beam as indicated by high layer parameter, is higher than Th(prioRx) where prioRx is the value of the priority field in the received SCI format 1-A. The internal parameter Th(pL) is set to the corresponding value of RSRP threshold indicated by the k-th field in sl-ThresholdRSRP-Conditionl-B-l-OptionlList, where k = pi. When the helper UE is the Rx UE, the resources are included when a TB associated with the received SCI format 1-A and the RSRP measurement performed, for the received SCI format 1-A, using a Rx beam corresponding to a Tx beam as indicated by high layer parameter, is lower than Th' (prioRx) where prioRx is the value of the priority field in the received SCI format 1-A. The internal parameter Th' (pi) is set to the corresponding value of RSRP threshold indicated by the k-th field in sl-ThresholdRSRP-Conditionl-B-l-Option2List, where k = pi. The UE further specifies for exclusion resources(s) in slot(s) in which the UE does not expect to perform SL reception due to half duplex operation or using a RX beam corresponding to a Tx beam as indicated by high layer parameter, if the UE is a destination UE of a TB for whose transmission the non-preferred resource set is being determined.

[0074] The UE additionally performs the following version of Step 7. When the number of candidate single-slot resources remaining in the set SA is smaller than X*Mtotai, then Th(pi,pj) is increased by 3 dB for each priority value Th(pi,pj) and the procedure continues with Step 4. The value of X is separately configured for beam based operations, which is smaller than the X value for omni-directional beam based operations. The value of X is generally smaller than 20-30%. This is because in beam based sensing resource selection, there are few candidate resources that remain.

[0075] The helper UE (e.g., the Rx UE or UE-A) is configured to send (308) IUC information back to the Tx UE. The IUC information includes a priority, a number of sub-channels, a resource reservation period, a resource selection window location, a resource set type, and soforth. The IUC information also includes the preferred or excluded resources information. Specifically, the IUC information specifies the Tx beam ID to be used for transmitting PSCCH / PSSCH.

[0076] The specified Tx beam identifier may be in terms of sidelink TCI state or in terms of sidelink CSI-RS (or S-SSB) resource identifier. The IUC information specifies the Rx beam ID to be used for receiving PSCCH / PSSCH. The Tx beam ID may be in terms of sidelink TCI state or in terms of sidelink CSI-RS (or S-SSB) resource identifier.

[0077] The Rx UE sends the IUC information to the Tx UE (UE-B) in one or more of the following containers. The ICU information container be part of SCI. In an aspect, the container of IUC information can be the SCI format 2-C that is modified for beam-based transmissions. Specifically, the SCI format 2-C can include one or more additional fields or repurposed fields that specify the Rx beam ID and / or the Tx beam ID. In an aspect, the container can include an SCI stage 2 format that is entirely newly defined (e.g. format 2-D). In this case, the fields are defined to consider the beam identifier information for PSCCH / PSSCH data transmission in addition to other mode 2 information used for IUC. For example, the container of the IUC information can set the embedded SCI format field to a predefined value to indicate the new format (e.g., a value of 10).

[0078] The container of the IUC information can be a MAC CE. In an aspect, the helper UE (UE-A / Rx UE) can use the FR1 IUC information MAC CE container. This container is modified to include additional fields or purposed fields that specify the Tx beam ID and / or the Rx beam ID. In another aspect, the IUC information is a new beam-based IUC information MAC CE. In this case, the fields are defined to consider the beam identifier information for PSCCH / PSSCH data transmission in addition to other mode 2 information used for IUC.

[0079] The UE-A can transmit the IUC information with a beam indication message or with a sidelink CSI-RS transmission. In this example, the IUC information is combined with a resource selection signal or the reference signal or measurement related message. The UE-A sends the beam indication message, and the helper UE-B passes the IUC information. Alternatively, when the UE-A sends the CSI-RS for the beam measurement and pairing procedure with the UE-B (the Tx UE), the CSI-RS include the IUC information. The UE-A can use the beam pairing process of the beam based sending to receive the IUC information. Therefore, when the helper UE is the Rx UE, the CSI-RS transmission can perform the two functions including both the beam sensing and the IUC information.

[0080] The UE-A is configured to transmit the IUC information using a beam based transmission based on a particular beam configuration. The direction of the beam based transmission can include one of the following options. In an aspect, the Rx UE can send the IUC information in different directions using a beam sweeping approach. The Rx UE can send the IUC information in different directions using directional beams. In another aspect, the Rx UE can use a wide beam to send the IUC information. The beam can be less wide than an omnidirectional beam but wider than a directional beam. In another aspect, the Rx UE sends the IUC information using a same serving Tx beam as used for PSCCH / PSSCH towards UE- A. In this example, the Rx UE (UE-A) and the Tx UE (UE-B) have already completed a beam pairing process. The Rx UE therefore has selected a beam for data transmission to the Tx UE. The same transmit beam is selected for the IUC information. In another aspect, the Rx UE / helper UE can use a same beam for the IUC information as selected for a physical sidelink feedback channel (PSFCH). Responsive to receiving data from the Tx UE, the Rx UE replies with an acknowledgement (ACK / NACK) on the PSFCH using a serving Rx beam that is selected for the PSFCH. In some implementations, the serving Rx beam for the PSFCH is the same beam as the serving Rx beam for the PSCCH / PSSCH data transmission. In some implementations, the serving Rx beam for the PSFCH is a different beam from the serving Rx beam for the PSCCH / PSSCH data transmission. In either scenario, the Rx UE can use either serving Rx beam for sending the IUC information. Conversely, the Rx UE (UE-A) can use a beam corresponding to the serving Tx beam from the Tx UE (UE-B) for the PSFCH feedback or corresponding to the serving Tx beam from the Tx UE for the PSCCH / PSSCH data transmission.

[0081] The UE-B is configured to receive the IUC information using a particular beam configuration. The beam configuration can include one of the following options. In an aspect, the Tx UE can receive the IUC information using a wide beam. The beam can be less wide than an omnidirectional beam (e.g., less 360 degrees), but wider than a directional beam (e.g., about 180 degrees). In another aspect, the Tx UE receives the IUC information using a same serving Tx beam as used for PSCCH / PSSCH from UE-A. In this example, the Rx UE (UE-A) and the Tx UE (UE-B) have already completed a beam pairing process. The Tx UE therefore has selected a beam for data reception from the Rx UE. The same receiving beam can be used for the IUC information. In another aspect, the Tx UE can use a same beam for receiving the IUC information as selected for the PSFCH transmission to the Rx UE. Responsive to receiving data from the Rx UE, the Tx UE replies with an acknowledgement (ACK / NACK) on thePSFCH using a serving Tx beam that is selected for receiving the PSFCH feedback from the Rx UE. In some implementations, the serving Tx beam for the PSFCH is the same beam as the serving Tx beam for the PSCCH / PSSCH data transmission. In some implementations, the serving Tx beam for the PSFCH is a different beam from the serving Tx beam for the PSCCH / PSSCH data transmission. In either scenario, the Tx UE can use either serving Tx beam for receiving the IUC information. Conversely, the Tx UE (UE-B) can use a beam corresponding to the serving Rx beam from the Rx UE (UE-A) for the PSFCH feedback or corresponding to the serving Rx beam from the Rx UE for the PSCCH / PSSCH data transmission.

[0082] The Tx UE (UE-B) performs (310) resource selection using non -preferred resources or preferred resources. A Tx UE is configured with the higher layer parameter sl-InterUE- CoordinationSchemel uses a received non-preferred resource set as follows when performing resource selection or reselection. The UE excludes in Step 6b) of clause 8.1.4 resource(s) overlapping with the non-preferred resource set if the Tx beam contained in the IUC information is equal to the Tx beam associated with the resource selection. For example, if the Tx beam in the particular transmission is aligned with the Tx beam identified in the IUC information then that beam is used. If there is no alignment, the Tx beam is not used.

[0083] FIG. 4 shows a network 400 for SL communication among UE-A, UE-B, and UE-C. The UEs are configured for beam based SL communication using IUC scheme 2 in which the helper UE (e.g., UE-A) specifies which resources have collisions for each of UE-A, UE-B, and UE-C. The receive beam conflict is used for generating IUC scheme 2. UE-A is the intended Rx UE of UE-B, which is the Tx UE. UE-A determines UE-B for providing the conflict information to in a PSFCH as follows. When UE-A (the helper UE) is an intended receiver of UE-B for a reserved resource of a PSSCH transmission in a slot, UE-A does not expect to perform reception on the sidelink due to half-duplex operation or using a Rx beam for receiving PSSCH from UE-2 in the slot. UE-A cannot make a SL transmission and receive data from UE-B in a same slot, and so UE-A excludes the resource with the conflict. If the UE-A is receiving on a given slot from a third UE (UE-C) with a different beam, UE-A cannot receive the transmission using both a first Rx beam for UE-B and a second, different Rx beam for UE- C in the same slot. UE-A excludes these resource with the conflict. UE-A determines to transmit to the UE-B the PSFCH with the conflict information.

[0084] FIG. 5 shows a resource space 500 in which UE-B and UE-C are reserving the same resources 502 for transmitting to UE-A (the Rx UE and helper UE). The RSRP measurement on other UEs’ transmission is based on the receive beam to be used for targeted PSSCH. In this example, the UE-A can determine whether to exclude resource 502 (e.g., a slot) based on the RSRP of each of the UE-C and UE-B. For example, if the RSRP of UE-C is below a threshold and UE-B’ s beam satisfies the RSRP threshold, UE-A can consider resource 502 conflict-free. The beam measurements are made using the same Rx beam for each of UE-B and UE-C.

[0085] UE-A (the helper UE and Rx UE) can be provided conditions by optionForCondition2AlScheme2 to determine conflict of reserved resources in a resource pool. If optionForCondition2A!Scheme2 = 'RSRP-ThresPerPriorities' , UE-A can be provided by, ThresPSSCH- RSRP-List Th(pi,pj), a list of RSRP thresholds for each priority combination (pi,pj). If UE-A is an intended receiver for PSSCH in a reserved resource of UE-B, UE-A determines a resource conflict if the RSRP of UE-C using a Rx beam for receiving PSSCH from UE-B, is above threshold Th(p2, pi). If UE-A is an intended receiver for PSSCH in a reserved resource of UE-C, UE-A determines a resource conflict if the RSRP of UE-B using a Rx beam for receiving PSSCH from UE-C, is above threshold Th(pi, P2).

[0086] A difference in RSRP values can be considered by the Rx UE instead of just the RSRP values of the Tx UEs. If optionForCondition2A!Scheme2 = 'RSRP- ThresWithRsrpMeasurement' UE-A can be provided a value Delta Th by deltaRSRPThresh. If UE-A is an intended receiver for PSSCH in a reserved resource of UE-B, UE-A determines a resource conflict if the difference in RSRP values exceeds a threshold difference, e.g., RSRP2>RSRPi+Delta_Th, where RSRPi and RSRP2 are the RSRP measurements from UE-A, using a Rx beam for receiving PSSCH from UE-B, for UE-B and UE-C, respectively. If UE-A is an intended receiver for PSSCH in a reserved resource of UE-C, UE-A determines a resource conflict if the difference in RSRP values exceeds the threshold difference (e.g., RSRPi>RSRP2+Delta_Th).

[0087] The Tx beam of IUC scheme 2 is a beam sent by UE-A (the helper UE). When the UE- A is to send transmissions using the IUC scheme 2 to UE-B or UE-C, the Tx beams can include the following. A Tx beam from UE-A can be a wide beam, as described in relation to FIG. 3 for IUC scheme 1 for both the IUC request and IUC information beams. A Tx beam from UE- A can be a same beam as the serving Tx beam for PSCCH / PSSCH towards UE-B or UE-C, similar to the Tx beam described in relation to FIG. 3 for IUC scheme 1 for both the IUCrequest and IUC information beams. A Tx beam from UE-A can be a same beam as the serving Tx beam for PSFCH towards UE-B or UE-C, similar to the Tx beam described in relation to FIG. 3 for IUC scheme 1 for both the IUC request and IUC information beams. A Tx beam from UE-A can be a Tx beam corresponding to the serving Rx beam for PSFCH from UE-B or UE-C, similar to the Tx beam described in relation to FIG. 3 for IUC scheme 1 for both the IUC request and IUC information beams. A Tx beam from UE-A can be a Tx beam corresponding to the serving Rx beam for PSCCH / PSSCH from UE-B or UE-C, similar to the Tx beam described in relation to FIG. 3 for IUC scheme 1 for both the IUC request and IUC information beams.

[0088] In some implementations, the UE-B or UE-C is to receive transmissions using the IUC scheme 2 from UE-A. The Rx beam for UE-B or UE-C can include the following. A Rx beam for UE-B or UE-C can be a wide beam, as described in relation to FIG. 3 for IUC scheme 1 for both the IUC request and IUC information beams. A Rx beam for UE-B or UE-C can be a same beam as the serving Rx beam for PSCCH / PSSCH from UE-A, similar to the Rx beam described in relation to FIG. 3 for IUC scheme 1 for both the IUC request and IUC information beams. A Rx beam for UE-B or UE-C can be a same beam as the serving Rx beam for PSFCH from UE-A, similar to the Rx beam described in relation to FIG. 3 for IUC scheme 1 for both the IUC request and IUC information beams. A Rx beam for UE-B or UE-C can be a Rx beam corresponding to the serving Tx beam for PSCCH / PSSCH from UE-A, similar to the Rx beam described in relation to FIG. 3 for IUC scheme 1 for both the IUC request and IUC information beams. A Rx beam for UE-B or UE-C can be a Rx beam corresponding to the serving Tx beam for PSFCH from UE-A, similar to the Rx beam described in relation to FIG. 3 for IUC scheme 1 for both the IUC request and IUC information beams.

[0089] FIG. 6 illustrates a flowchart of an example method 600, according to some implementations. For clarity of presentation, the description that follows generally describes method 600 in the context of the other figures in this description. For example, method 600 can be performed by UE 105 of FIG. 1. It will be understood that method 600 can be performed, for example, by any suitable system, environment, software, hardware, or a combination of systems, environments, software, and hardware, as appropriate. In some implementations, various steps of method 600 can be run in parallel, in combination, in loops, or in any order.

[0090] In an aspect, the method 600 includes transmitting (602), to a first user equipment (UE) from a second UE, a request for inter-UE coordination (IUC) information including resourceallocation information for beam based sidelink communication. The method 600 includes receiving (604), at the second UE from the first UE, the IUC information specifying a beam identifier and one or more available resources or non-available resources for the sidelink communication. The method 600 includes performing (606), by the second UE, a sidelink communication using the identified beam.

[0091] In some implementations, the IUC information causes a physical layer in the second UE to exclude in resource selection or reselection the one or more available resources of the IUC information from candidate single-slot resources obtained during a resource selection procedure. In some implementations, at least one of the request for the IUC information or the IUC information includes a transmitter beam identifier specifying a transmitter beam for transmitting a physical sidelink control channel (PSCCH) or a physical sidelink shared channel (PSSCH). In some implementations, at least one of the request for the IUC information or the IUC information includes a receiver beam identifier specifying a receiving beam for receiving a PSCCH or a PSSCH.

[0092] In some implementations, at least one of the request for the IUC information or the IUC information is transmitted in a medium access control (MAC) control element (CE). In some implementations, at least one of the request for the IUC information or the IUC information is transmitted in sidelink control information (SCI) format 2. In some implementations, the request for IUC information is transmitted with beam indication message or a channel state information reference signal. In some implementations, the IUC information is transmitted with beam reporting information. In some implementations, the IUC information includes a field specifying a number of subchannels associated with a transmitter beam. In some implementations, the IUC information includes a field specifying one or more RB sets associated with a transmitter beam. In some implementations, the IUC information includes a field specifying one or more slots associated with a transmitter beam.

[0093] In some implementations, a sensing window is configured to have a length that enables multiple beam measurements for a slot. In some implementations, a sensing window for the first UE is configured to have a length that enables multiple beam measurements for a slot, and wherein the IUC information includes resources associated with a beam measurement by the first UE associated with a specified transmitter beam for the second UE. in some implementations, the sensing window is longer than 1100 milliseconds. In some implementations, the sensing window for the first UE is less than 100 milliseconds.

[0094] In some implementations, the method includes receiving, at the second UE, a set of all candidate single slot resources when a threshold number of identified candidate single slot resources does not exceed a threshold. In some implementations, the IUC information specifying the one or more available resources or non-available resources excludes a slot from the one or more available resources when the first UE is a receiver UE and expects to receive a transmission during the slot using a different beam or when the first UE expects to transmit during the slot.

[0095] In some implementations, the IUC information specifying the one or more available resources or non-available resources excludes a slot from the one or more available resources when the first UE measures a reference signal receive power (RSRP) below a threshold for a receiver beam associated with the slot. In some implementations, the IUC information specifying the one or more available resources or non-available resources excludes a slot from the one or more available resources when the first UE measures a reference signal receive power (RSRP) below a threshold for a transmitter beam associated with the slot. In some implementations, the method includes adjusting the threshold for the RSRP based on a number of available resources.

[0096] The example method 600 shown in FIG. 6 can be modified or reconfigured to include additional, fewer, or different steps (not shown in FIG. 6), which can be performed in the order shown or in a different order. In some implementations, the IUC information causes a physical layer in the second UE to exclude in resource selection or reselection the one or more available resources of the IUC information from candidate single-slot resources obtained during a resource selection procedure.

[0097] FIG. 7 illustrates a flowchart of an example method 700, according to some implementations. For clarity of presentation, the description that follows generally describes method 700 in the context of the other figures in this description. For example, method 700 can be performed by UE 105 of FIG. 1. It will be understood that method 700 can be performed, for example, by any suitable system, environment, software, hardware, or a combination of systems, environments, software, and hardware, as appropriate. In some implementations, various steps of method 700 can be run in parallel, in combination, in loops, or in any order.

[0098] The method 700 includes generating (702) inter-UE coordination (IUC) information for resource allocation for beam based sidelink communication. The IUC information specifies at least one conflicting resource based on determining a conflict between a first beam and asecond beam for a second UE. The method 700 includes transmitting (704), from a first user equipment (UE) to the second UE, feedback data, the feedback data specifying the at least one conflicting resource.

[0099] In some implementations, the first UE is an intended receiver of the second UE, and the first UE does not expect to perform reception on a slot using a receiver beam for the second UE in some implementations, the IUC information specifying the at least one conflicting resource wherein a difference between a first RSRP of a first beam associated with the second UE and a second RSRP of the first beam does not satisfy a threshold difference. In some implementations, the IUC information is transmitted using a wide beam. In some implementations, the IUC information is transmitted using a same beam as a transmitting beam for PSCCH or PSSCH to the second UE or a third UE. in some implementations, the IUC information is transmitted using a same beam as a transmitting beam for PSFCH to the second UE or a third UE. In some implementations, the IUC information is transmitted using a corresponding beam to a receiver beam for PSFCH from the second UE or a third UE. In some implementations, the IUC information is transmitted using a corresponding beam to a receiver beam for PSCCH or PSSCH from the second UE or a third UE.

[0100] FIG. 8 illustrates an example UE 800, according to some implementations. The UE 800 may be similar to and substantially interchangeable with UEs 105 of FIG. 1. The UE 800 may be any mobile or non-mobile computing device, such as, for example, mobile phones, computers, tablets, industrial wireless sensors (for example, microphones, pressure sensors, thermometers, motion sensors, accelerometers, inventory sensors, electric voltage / current meters, etc.), video devices (for example, cameras, video cameras, etc.), wearable devices (for example, a smart watch), relaxed-IoT devices.

[0101] The UE 800 may include processors 802, RF interface circuitry 804, memory / storage 806, user interface 808, sensors 810, driver circuitry 812 , power management integrated circuit (PMIC) 814, one or more antenna(s) 816, and battery 818. The components of the UE 800 may be implemented as integrated circuits (ICs), portions thereof, discrete electronic devices, or other modules, logic, hardware, software, firmware, or a combination thereof. The block diagram of FIG. 8 is intended to show a high-level view of some of the components of the UE 800. However, some of the components shown may be omitted, additional components may be present, and different arrangement of the components shown may occur in other implementations.

[0102] The components of the UE 800 may be coupled with various other components over one or more interconnects 820, which may represent any type of interface, input / output, bus (local, system, or expansion), transmission line, trace, optical connection, etc. that allows various circuit components (on common or different chips or chipsets) to interact with one another.The processors 802 may include processor circuitry such as, for example, baseband processor circuitry (BB) 822A, central processor unit circuitry (CPU) 822B, and graphics processor unit circuitry (GPU) 822C. The processors 802 may include any type of circuitry or processor circuitry that executes or otherwise operates computer-executable instructions, such as program code, software modules, or functional processes from memory / storage 806 to cause the UE 800 to perform operations as described herein. For example, the UE 800 can be one of the transmitting UE (Tx UE) or the receiving UE (Rx UE, helper UE) as described herein. The UE 800 can be configured to perform a sidelink communication by transmitting, to another UE acting as helper UE, a request for inter-UE coordination (IUC) information including resource allocation information for beam based sidelink communication. The UE 800 can receive the IUC information from the helper UE, the IUC information specifying abeam identifier and one or more available resources or non-available resources for the sidelink communication between the UEs. The UE 800 can perform a sidelink communication using a beam associated with the beam identifier. In another example, the UE 800 can act as a helper UE by generating IUC information for resource allocation for beam based sidelink communication in response to a request from another UE, such as a transmitting UE. The IUC information specifies at least one conflicting resource based on determining a conflict between a first beam and a second beam for the transmitting UE. The IUC information can be transmitted in a PSFCH transmission.

[0103] In some implementations, the baseband processor circuitry 822A may access a communication protocol stack 824 in the memory / storage 806 to communicate over a 3 GPP compatible network. In general, the baseband processor circuitry 822A may access the communication protocol stack to perform user plane functions at a physical (PHY) layer, medium access control (MAC) layer, radio link control (RLC) layer, packet data convergence protocol (PDCP) layer, service data adaptation protocol (SDAP) layer, and PDU layer; and perform control plane functions at a PHY layer, MAC layer, RLC layer, PDCP layer, RRC layer, and a non-access stratum layer. In some implementations, the PHY layer operations may additionally / altematively be performed by the components of the RF interface circuitry 804. The baseband processor circuitry 822A may generate or process baseband signals orwaveforms that carry information in 3 GPP-compatible networks. In some implementations, the waveforms for NR may be based cyclic prefix orthogonal frequency division multiplexing (OFDM) “CP-OFDM” in the uplink or downlink, and discrete Fourier transform spread OFDM “DFT-S-OFDM” in the uplink.

[0104] The memory / storage 806 may include one or more non -transitory, computer-readable media that includes instructions (for example, communication protocol stack 824) that may be executed by one or more of the processors 802 to cause the UE 800 to perform various operations described herein. The memory / storage 806 include any type of volatile or nonvolatile memory that may be distributed throughout the UE 800. In some implementations, some of the memory / storage 806 may be located on the processors 802 themselves (for example, LI and L2 cache), while other memory / storage 806 is external to the processors 802 but accessible thereto via a memory interface. The memory / storage 806 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.

[0105] The RF interface circuitry 804 may include transceiver circuitry and radio frequency front module (RFEM) that allows the UE 800 to communicate with other devices over a radio access network. The RF interface circuitry 804 may include various elements arranged in transmit or receive paths. These elements may include, for example, switches, mixers, amplifiers, filters, synthesizer circuitry, control circuitry, etc.

[0106] In the receive path, the RFEM may receive a radiated signal from an air interface via antenna(s) 816 and proceed to filter and amplify (with a low-noise amplifier) the signal. The signal may be provided to a receiver of the transceiver that downconverts the RF signal into a baseband signal that is provided to the baseband processor of the processors 802.

[0107] 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 RF signal through a power amplifier prior to the signal being radiated across the air interface via the antenna(s) 816. In various implementations, the RF interface circuitry 804 may be configured to transmit / receive signals in a manner compatible with NR access technologies.

[0108] The antenna(s) 816 may include one or more antenna elements to convert electrical signals into radio waves to travel through the air and to convert received radio waves into electrical signals. The antenna elements may be arranged into one or more antenna panels. The antenna(s) 816 may have antenna panels that are omnidirectional, directional, or a combination thereof to enable beamforming and multiple input, multiple output communications. The antenna(s) 816 may include microstrip antennas, printed antennas fabricated on the surface of one or more printed circuit boards, patch antennas, phased array antennas, etc. The antenna(s) 816 may have one or more panels designed for specific frequency bands including bands in FR1 or FR2. Specifically, the UE 800 can form beams using a phased array antenna. The beams can be directional to enable the UE 800 to communicate with other UEs at higher frequencies. The particular beam used for communication is selected as part of the resource selection processes described herein. For receiving beam based communication, the UE is configured to sweep over different beams to measure a beam strength (e.g., using RSRP) of the beams from different directions. The selection of a particular beam for transmission or reception can be selected based on coordination with one or more other UEs, as previously described.

[0109] The user interface 808 includes various input / output (VO) devices designed to enable user interaction with the UE 800. The user interface 808 includes input device circuitry and output device circuitry. Input device circuitry includes any physical or virtual means for accepting an input including, inter alia, one or more physical or virtual buttons (for example, a reset button), a physical keyboard, keypad, mouse, touchpad, touchscreen, microphones, scanner, headset, or the like. The output device circuitry includes any physical or virtual means for showing information or otherwise conveying information, such as sensor readings, actuator position(s), or other like information. Output device circuitry may include any number or combinations of audio or visual display, including, inter alia, one or more simple visual outputs / indicators (for example, binary status indicators such as light emitting diodes “LEDs” and multi -character visual outputs), or more complex outputs such as display devices or touchscreens (for example, liquid crystal displays “LCDs,” LED displays, quantum dot displays, projectors, etc.), with the output of characters, graphics, multimedia objects, and the like being generated or produced from the operation of the UE 800.

[0110] The sensors 810 may include devices, modules, or subsystems whose purpose is to detect events or changes in its environment and send the information (sensor data) about the detected events to some other device, module, subsystem, etc. Examples of such sensors include, inter alia, inertia measurement units including accelerometers, gyroscopes, ormagnetometers; microelectromechanical systems or nanoelectromechanical systems including 3-axis accelerometers, 3-axis gyroscopes, or magnetometers; level sensors; temperature sensors (for example, thermistors); pressure sensors; image capture devices (for example, cameras or lensless apertures); light detection and ranging sensors; proximity sensors (for example, infrared radiation detector and the like); depth sensors; ambient light sensors; ultrasonic transceivers; microphones or other like audio capture devices; etc.[OHl] The driver circuitry 812 may include software and hardware elements that operate to control particular devices that are embedded in the UE 800, attached to the UE 800, or otherwise communicatively coupled with the UE 800. The driver circuitry 812 may include individual drivers allowing other components to interact with or control various input / output (EO) devices that may be present within, or connected to, the UE 800. For example, driver circuitry 812 may include a display driver to control and allow access to a display device, a touchscreen driver to control and allow access to a touchscreen interface, sensor drivers to obtain sensor readings of sensors 810 and control and allow access to sensors 810, drivers to obtain actuator positions of electro-mechanic components or control and allow access to the electro-mechanic components, a camera driver to control and allow access to an embedded image capture device, audio drivers to control and allow access to one or more audio devices.

[0112] The PMIC 814 may manage power provided to various components of the UE 800. In particular, with respect to the processors 802, the PMIC 814 may control power-source selection, voltage scaling, battery charging, or DC-to-DC conversion.

[0113] In some implementations, the PMIC 814 may control, or otherwise be part of, various power saving mechanisms of the UE 800. A battery 818 may power the UE 800, although in some examples the UE 800 may be mounted deployed in a fixed location and may have a power supply coupled to an electrical grid. The battery 818 may be a lithium ion battery, a metal-air battery, such as a zinc-air battery, an aluminum-air battery, a lithium-air battery, and the like. In some implementations, such as in vehicle-based applications, the battery 818 may be a typical lead-acid automotive battery.

[0114] Various components may be described as performing a task or tasks, for convenience in the description. Such descriptions should be interpreted as including the phrase “configured to.” Reciting a component that is configured to perform one or more tasks is expressly intended not to invoke 35 U.S.C. § 112(f) interpretation for that component.

[0115] For one or more embodiments, at least one of the components set forth in one or more of the preceding figures may be configured to perform one or more operations, techniques, processes, or methods as set forth in the example section below. For example, the baseband circuitry as described above in connection with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples set forth below. For another example, circuitry associated with a UE, base station, network element, etc. as described above in connection with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples set forth below in the example section.

[0116] Although the embodiments above 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 embrace all such variations and modifications.

[0117] It is well understood that the use of personally identifiable information should follow privacy policies and practices that are generally recognized as meeting or exceeding industry or governmental requirements for maintaining the privacy of users. In particular, personally identifiable information data should be managed and handled so as to minimize risks of unintentional or unauthorized access or use, and the nature of authorized use should be clearly indicated to users.

Claims

WHAT IS CLAIMED IS:

1. One or more processors configured to, when executing instructions stored in a memory, perform operations comprising: causing transmission, to a user equipment (UE), a request for inter-UE coordination (IUC) information including resource allocation information for beam based sidelink communication; receiving, from the UE, the IUC information specifying a beam identifier and one or more available resources or non-available resources for the sidelink communication; and causing a sidelink communication using a beam associated with the beam identifier.

2. The one or more processors of claim 1, wherein the IUC information causes a physical layer in the second UE to exclude in resource selection or reselection the one or more available resources of the IUC information from candidate single-slot resources obtained during a resource selection procedure.

3. The one or more processors of any of claim 1 through claim 2, wherein at least one of the request for the IUC information or the IUC information includes a transmitter beam identifier specifying a transmitter beam for transmitting a physical sidelink control channel (PSCCH) or a physical sidelink shared channel (PSSCH).

4. The one or more processors of any of claim 1 through claim 3, wherein at least one of the request for the IUC information or the IUC information includes a receiver beam identifier specifying a receiving beam for receiving a PSCCH or a PSSCH.

5. The one or more processors of any of claim 1 through claim 4, wherein at least one of the request for the IUC information or the IUC information is transmitted in a medium access control (MAC) control element (CE).

6. The one or more processors of any of claim 1 through claim 5, wherein at least one of the request for the IUC information or the IUC information is transmitted in sidelink control information (SCI) format 2.

7. The one or more processors of any of claim 1 through claim 6, wherein the request for IUC information is transmitted with a beam indication message or a channel state information reference signal.

8. The one or more processors of any of claim 1 through claim 7, wherein the IUC information is transmitted with beam reporting information.

9. The one or more processors of any of claim 1 through claim 8, wherein the IUC information includes a field specifying a number of subchannels associated with a transmitter beam, a field specifying one or more resource block sets associated with a transmitter beam, or a field specifying one or more slots associated with a transmitter beam.

10. The one or more processors of any of claim 1 through claim 9, wherein a sensing window is configured to have a length that enables multiple beam measurements for a slot.

11. The one or more processors of any of claim 1 through claim 10, wherein a sensing window for the first UE is configured to have a length that enables multiple beam measurements for a slot, and wherein the IUC information includes resources associated with a beam measurement by the first UE associated with a specified transmitter beam for the second UE.

12. The one or more processors of any of claim 1 through claim 11, the operations further comprising receiving a set of all candidate single slot resources when a threshold number of identified candidate single slot resources does not exceed a threshold.

13. The one or more processors of any of claim 1 through claim 12, wherein the IUC information specifying the one or more available resources or non-available resources excludes a slot from the one or more available resources when the first UE is a receiver UE and expects to receive a transmission during the slot using a different beam or when the first UE expects to transmit during the slot; wherein the IUC information specifying the one or more available resources or non- available resources excludes a slot from the one or more available resources when the first UE measures a reference signal receive power (RSRP) below a threshold for a receiver beam associated with the slot; or wherein the IUC information specifying the one or more available resources or non- available resources excludes a slot from the one or more available resources when the first UE measures a RSRP below a threshold for a transmitter beam associated with the slot.

14. A method comprising:generating inter-UE coordination (IUC) information for resource allocation for beam based sidelink communication, the IUC information specifying at least one conflicting resource based on determining a conflict between a first beam and a second beam for a second user equipment (UE); and transmitting, from a first UE to the second UE, feedback data, the feedback data specifying the at least one conflicting resource.

15. The method of claim 14, wherein the first UE is an intended receiver of the second UE, and the first UE does not expect to perform reception on a slot using a receiver beam for the second UE.

16. The method of any of claim 14 through claim 15, wherein the IUC information specifying the at least one conflicting resource wherein a difference between a first reference signal receiver power (RSRP) of a first beam associated with the second UE and a second RSRP of the first beam does not satisfy a threshold difference.

17. The method of any of claim 14 through claim 16, wherein the IUC information is transmitted using a wide beam.

18. The method of any of claim 14 though claim 17, wherein the IUC information is transmitted using a same beam as a transmitting beam for a Physical Sidelink Control Channel (PSCCH) or a Physical Sidelink Shared Channel (PSSCH) to the second UE or a third UE; wherein the IUC information is transmitted using a same beam as a transmitting beam for a Physical Sidelink Feedback Channel (PSFCH) to the second UE or a third UE; wherein the IUC information is transmitted using a corresponding beam to a receiver beam for PSFCH from the second UE or the third UE; or wherein the IUC information is transmitted using a corresponding beam to a receiver beam for PSCCH or PSSCH from the second UE or a third UE.

19. An apparatus comprising: one or more antenna; a memory; andone or more processors in communication with the one or more antenna and the memory, the one or more processors, when executing instructions stored in the memory, configured to perform operations comprising: causing transmission, to a user equipment (UE) via the one or more antenna, a request for inter-UE coordination (IUC) information including resource allocation information for beam based sidelink communication; receiving, from the UE via the one or more antenna, the IUC information specifying a beam identifier and one or more available resources or non-available resources for the sidelink communication; and causing, via the one or more antenna, a sidelink communication using a beam associated with the beam identifier.

20. The apparatus of claim 19, wherein the IUC information causes a physical layer in the second UE to exclude in resource selection or reselection the one or more available resources of the IUC information from candidate single-slot resources obtained during a resource selection procedure.

Images