Patent Description:
In some wireless communications systems, communications may occur directly between UEs, e.g., in a device-to-device (D2D) or peer-to-peer (p2P) manner, often using communication resources shared by one or more networks that may serve such or other like UEs. Some such communication in <NUM> NR may, for example, be referred to as unicast sidelink communication. In some implementations, sidelink communication may be conducted by two UEs using communication resources that may be allocated by a network for an individual UE usage, or otherwise allocated in some shared manner to multiple UEs. A unicast sidelink may be limited to half-duplex communication between a pair of UEs in situations wherein the at least one of the UEs is unable to transmit and receive signals simultaneously. Moreover, there may be situations wherein a transmitting UE may need to retransmit data messages which may be missed by a receiving UE that may have been transmitting signals itself and hence not receiving or may have been tuned to receive other signals via resources (e.g., time and frequency based slots, etc.) that may not have included the signal from the transmitting UE. Likewise, if other devices may use shared resources for still other communications, there may be signal interferences that also lead to retransmission by the transmitting UE. Accordingly, improved techniques may be beneficial by improving efficient use of resources, for example, by reducing retransmissions.

<CIT> discloses a method for transmitting data via a sidelink comprising: a scheduling terminal sends to a transmitting terminal a first physical control signal, wherein the first physical control signal comprises a first transmission resource used to transmit first-type system information; and the scheduling terminal sends to the transmitting terminal the first-type system information, wherein the first-type system information comprises sidelink resource pool information used for transmission via a sidelink between the transmitting terminal and a receiving terminal.

R1-<NUM> "Discussion on supporting unicast, groupcast and broadcast via NR sidelink" by Panasonic discusses supporting unicast, groupcast and broadcast transmissions in physical layer.

As described in greater detail in the description and examples herein, techniques are provided that may improve the efficiency of sidelink unicast communication, for example, by allowing UEs to establish and/or otherwise make use of a sidelink schedule. In certain instances, the use of a sidelink schedule may reduce retransmissions.

By way of an initial example, a first UE may comprise a sidelink scheduler configured to access or otherwise obtain a link availability schedule indicating, at least in part, communication resources that may be available for use by at least the first UE for sidelink unicast communication. In certain example implementations, all or part of a link availability schedule may be obtained from a network resource and indicate, at least in part, communication resources that may be allocated to the first UE or otherwise allocated for sharing by the first UE. When the first UE has identified a second UE to attempt to engage in a sidelink unicast communication, the sidelink scheduler may establish one or more sidelink schedules with the second UE. Here, for example, a sidelink schedule may correspond to at least a subset of the communication resources indicated by the link availability schedule. The UE may subsequently establish and use a sidelink with the second UE based on the sidelink schedule.

According to the claimed invention, a first UE obtains a link availability schedule indicating, at least in part, communication resources available for use by at least the first UE for sidelink unicast communication; identifies a second UE to attempt to engage in a sidelink unicast communication; establishes a sidelink schedule with the second UE, the sidelink schedule corresponding to at least a subset of the communication resources indicated by the link availability schedule; establishes a sidelink with the second UE; and communicates, via the sidelink, with the second UE using at least a portion of the communication resources per the sidelink schedule.

In certain instances, to establish the sidelink schedule comprises one or both of the UEs may exchange sidelink negotiation information some of which may be based, at least in part, on the link availability schedule.

According to the claimed invention, to establish the sidelink schedule comprises: the first UE exchanges sidelink negotiation information with the second UE, wherein at least a portion of the sidelink negotiation information provided by the first UE to the second UE is based, at least in part, on the link availability schedule.

For example, as part of exchanging sidelink negotiation information with the second UE, a first UE may receive sidelink negotiation information from the second UE, which may correspond to a link availability schedule applicable to the second UE. In certain example implementations, at least a portion of the sidelink negotiation information may be indicative of at least one quality of service (QoS) parameter or the like, corresponding to the sidelink unicast communication. As presented by way of example herein, at least a portion of the sidelink negotiation information that may be exchanged may be exchanged as part of an RRC procedure, a MAC procedure, and/or other like protocol layer(s), or some combination there.

In certain example implementations, a sidelink schedule that may be negotiated or otherwise established may comprise two or more candidate sidelink schedules that may be acceptable to the first UE and the second UE. Thus, for example, one or both of the UEs may be configured to identify that a particular candidate sidelink schedule is to be used (e.g., serve as the sidelink schedule). For example, a first UE may send or receive an indication that a particular candidate sidelink schedule is to serve as the sidelink schedule.

While a sidelink schedule may be indicative of a specific resource available for a first UE to transmit signals over the sidelink to the second UE, the first UE may actually be configured to use the specific resource to transmit one or more signals to a device other than the second UE, or perhaps receive one or more signals from another device, or possibly some combination thereof. Similar capabilities may exist for the second UE to perform other communications that may not actually involve the first UE. Similarly, a sidelink schedule may be indicative of specific resources for use by the first UE to receive signals over the sidelink from the first UE, or vice versa.

As mentioned, a sidelink schedule may correspond to at least a subset of the communication resources indicated by the link availability schedule. By way of an example, a subset of the communication resources may correspond to at least one subframe of at least one slot indicated by the link availability schedule. Here, for example, slots may be indicative of resources by time and frequency. A sidelink schedule may be indicative of a communication resource granularity (time, frequency, or both). A sidelink schedule may be indicative of a network-related timing offset or the like for at least one communication resource for the sidelink unicast communication.

In certain instances, a sidelink may comprise a single unidirectional sidelink, at least two unidirectional sidelinks arranged in reversed directions so as to provide bidirectional communication, a bidirectional sidelink, or some combination thereof. In certain instances, a sidelink may comprise a PC5 or other like communication link.

Attention is now drawn to <FIG>, which illustrates an example of a wireless communications system <NUM> that supports sidelink establishment in accordance with aspects of the present disclosure. The wireless communications system <NUM> includes base stations <NUM>, UEs <NUM>, and a core network <NUM>. In some examples, the wireless communications system <NUM> may be a Long Term Evolution (LTE) network, an LTE-Advanced (LTE-A) network, an LTE-A Pro network, or a New Radio (NR) network. In some cases, wireless communications system <NUM> may support enhanced broadband communications, ultra-reliable (e.g., mission critical) communications, low latency communications, or communications with low-cost and low-complexity devices.

A UE <NUM> may be a personal electronic device such as a cellular phone, a personal digital assistant (PDA), a tablet computer, a laptop computer, or a personal computer.

Wireless communications system <NUM> may support direct communication between UEs <NUM> over a sidelink <NUM> (e.g., using a peer-to-peer (P2P), device-to-device (D2D) protocol, ProSe direct communications). Sidelink communication may be used for D2D media-sharing, vehicle-to-vehicle (V2V) communication, V2X communication (e.g., cellular V2X (cV2X) communication, enhanced V2X (eV2X) communication, etc.), emergency rescue applications, etc. One or more of a group of UEs <NUM> utilizing D2D communications may be within the geographic coverage area <NUM> of a base station <NUM>. In other cases, D2D communications are carried out between UEs <NUM> without the involvement of a base station <NUM>, e.g., particularly using the techniques presented herein for sidelink scheduling.

For example, wireless communications system <NUM> may use a transmission scheme between a transmitting device (e.g., a first UE <NUM> of a sidelink connection) and a receiving device (e.g., a second UE <NUM> of a sidelink connection), where the transmitting device is equipped with multiple antennas and the receiving device is equipped with one or more antennas.

In one example, a base station <NUM> or UE <NUM> may use multiple antennas or antenna arrays to conduct beamforming operations for directional communications with a UE <NUM> recipient. For instance, some signals (e.g. synchronization signals, reference signals, beam selection signals, or other control signals) may be transmitted by a base station <NUM> multiple times in different directions, which may include a signal being transmitted according to different beamforming weight sets associated with different directions of transmission. Transmissions in different beam directions may be used to identify (e.g., by the base station <NUM>, a first UE <NUM>, or a receiving device, such as a second UE <NUM>) a beam direction for subsequent transmission and/or reception by the base station <NUM>.

Some signals, such as data signals associated with a particular receiving device, may be transmitted by a base station <NUM> or a first UE <NUM> in a single beam direction (e.g., a direction associated with the receiving device, such as a second UE <NUM>). In some examples, the beam direction associated with transmissions along a single beam direction may be determined based at least in in part on a signal that was transmitted in different beam directions. For example, a receiving UE <NUM> may receive one or more of the signals transmitted by a base station <NUM> or a transmitting UE <NUM> in different directions, and the receiving UE <NUM> may report to the base station <NUM> or the transmitting UE <NUM> an indication of the signal it received with a highest signal quality, or an otherwise acceptable signal quality. Although these techniques are described with reference to signals transmitted in one or more directions by a base station <NUM>, a UE <NUM> may employ similar techniques for transmitting signals multiple times in different directions (e.g., for identifying a beam direction for subsequent transmission or reception by the UE <NUM>) or transmitting a signal in a single direction (e.g., for transmitting data to a receiving device).

In the user plane, communications at the bearer or PDCP layer may be IP-based. In cases where D2D or V2X communications are used, a V2X layer may provide related protocols, and in some cases may use ProSe direct communications protocols (e.g., PC5 signaling). A RLC layer may perform packet segmentation and reassembly to communicate over logical channels. A MAC layer may perform priority handling and multiplexing of logical channels into transport channels. In the control plane, the RRC protocol layer may provide establishment, configuration, and maintenance of an RRC connection between a UE <NUM> and a base station <NUM> or core network <NUM> supporting radio bearers for user plane data. At the PHY layer, transport channels may be mapped to physical channels.

A carrier may be associated with a pre-defined frequency channel (e.g., an evolved universal mobile telecommunication system terrestrial radio access (E-UTRA) absolute radio frequency channel number (EARFCN)) and may be positioned according to a channel raster for discovery by UEs <NUM>. In some examples, signal waveforms transmitted over a carrier may be made up of multiple sub-carriers (e.g., using multi-carrier modulation (MCM) techniques such as orthogonal frequency division multiplexing (OFDM) or discrete Fourier transform spread OFDM (DFT-S-OFDM)).

The organizational structure of the carriers may be different for different radio access technologies (e.g., LTE, LTE-A, LTE-A Pro, NR).

Devices of the wireless communications system <NUM> (e.g., base stations <NUM> or UEs <NUM>) may have a hardware configuration that supports communications over a particular carrier bandwidth or may be configurable to support communications over one of a set of carrier bandwidths. In some examples, the wireless communications system <NUM> may include base stations <NUM> and/or UEs <NUM> that support simultaneous communications via carriers associated with more than one different carrier bandwidth.

Wireless communications system <NUM> may support communication with a UE <NUM> on multiple cells or carriers, a feature which may be referred to as carrier aggregation or multi-carrier operation.

In some cases, an eCC may utilize a different symbol duration than other component carriers, which may include use of a reduced symbol duration as compared with symbol durations of the other component carriers.

Wireless communications system <NUM> may be an NR system that may utilize any combination of licensed, shared, and unlicensed spectrum bands, among others. The flexibility of eCC symbol duration and subcarrier spacing may allow for the use of eCC across multiple spectrums. In some examples, NR shared spectrum may increase spectrum utilization and spectral efficiency, specifically through dynamic vertical (e.g., across the frequency domain) and horizontal (e.g., across the time domain) sharing of resources.

In some wireless communications systems, data transmissions (e.g., target traffic) may be periodically broadcasted from a UE <NUM> or base station <NUM>. For example, in V2X communications, a vehicle (e.g., or a UE <NUM>) may broadcast safety messages (with a known size) periodically to enable nearby vehicles, sensors, or additional UEs <NUM> to receive necessary information about the transmitting vehicle.

Wireless communications system <NUM> may support efficient techniques for establishing a unicast link (e.g., connection) between two wireless devices (e.g., UEs <NUM>, vehicles, sensors, etc.). For example, a connection-oriented link may be established by a V2X layer of a protocol stack between the two wireless devices that supports an optimized AS layer configuration (e.g., over-the-air) for higher throughput (e.g., <NUM> quadrature amplitude modulation (QAM), CA, etc.), supports enhanced security protection, and allows more efficient resource usage (e.g., power control, beam management, etc.). In some cases, the unicast connection may be established over a sidelink <NUM> between the two wireless devices, for example, without going through a base station. To establish the unicast connection over the sidelink <NUM>, a first UE <NUM> may transmit a request message to a second UE <NUM>, and the second UE <NUM> may transmit a response message accepting the request to the first UE <NUM>.

Additionally, the first UE <NUM> may transmit a connection complete message to the second UE <NUM> and establish a security context with the second UE <NUM> as part of establishing a connection over the sidelink <NUM>. In some cases, the request message, the response message, and the connection complete message may be transmitted via RRC signaling (e.g., over PC5 to have unified PC5 and Uu management). Additionally, a connection may be established based on parameters (e.g., capabilities, connection parameters, etc.) for the first UE <NUM> and/or the second UE <NUM> that are transmitted in the respective request message and/or response message. For example, the parameters may include PDCP parameters, RLC parameter, MAC parameters, PHY layer parameters, capabilities of either UE <NUM>, or a combination thereof. Such communications may be performed as part of a link management process.

Attention is drawn next to <FIG>, which is a block diagram illustrating some features of an apparatus for use in a UE configured for sidelink unicast communication based, at least in part, on one or more sidelink schedule(s) negotiated with a peer UE, in accordance with certain aspects of the present disclosure.

Referring to <FIG>, one example of an implementation of the UE <NUM> may include a variety of components including components such as one or more processing units <NUM> and memory <NUM> and transceiver <NUM> in communication via one or more buses <NUM>, which may operate in conjunction with the modem <NUM> and the communication component <NUM> to enable one or more of the functions described herein related to V2X and related communications. Further, the one or more processing unit(s) <NUM>, modem <NUM>, memory <NUM>, transceiver <NUM>, RF front end <NUM> and one or more antennas <NUM>, may be configured to support voice and/or data calls (simultaneously or non-simultaneously) in one or more radio access technologies.

In an aspect, the one or more processing unit(s) <NUM> may include modem <NUM> that uses one or more modem processors. The various functions related to a communication component <NUM> may be included or otherwise implemented, at least in part, in modem <NUM> and/or processing unit(s) <NUM> and, in an aspect, may be executed by a single processor, while in other aspects, different ones of the functions may be executed by a combination of two or more different processors. For example, in an aspect, the one or more processing unit(s) <NUM> may include any one or any combination of a modem processor, or a baseband processor, or a digital signal processor, or a transmit processor, or a receiver processor, or a transceiver processor associated with transceiver <NUM>. In other aspects, some of the features of the one or more processing unit(s) <NUM> and/or the modem <NUM> associated with the communication component <NUM> may be performed by transceiver <NUM>.

Also, memory <NUM> may be configured to store data used herein and/or local versions of applications <NUM> for the communication component <NUM> and/or one or more subcomponents of the communication component <NUM> being executed by at least one processing unit(s) <NUM>. Memory <NUM> can include any type of computer-readable medium usable by a computer or at least one processing unit(s) <NUM>, such as random access memory (RAM), read only memory (ROM), tapes, magnetic discs, optical discs, volatile memory, non-volatile memory, and any combination thereof. In an aspect, for example, memory <NUM> may be a non-transitory computer-readable storage medium that stores one or more computer-executable codes defining all or part of communication component <NUM> and/or one or more of its subcomponents, and/or data associated therewith, when UE <NUM> is operating at least one processing unit(s) <NUM> to execute the communication component <NUM> and/or one or more of its subcomponents.

Receiver <NUM> may include hardware, firmware, and/or software code executable by a processor for receiving data, the code comprising instructions and being stored in a memory (e.g., computer-readable medium). Transmitter <NUM> may include hardware, firmware, and/or software code executable by a processor for transmitting data, the code comprising instructions and being stored in a memory (e.g., computer-readable medium).

RF front end <NUM> may be coupled with one or more antennas <NUM> and can include one or more low-noise amplifiers (LNAs) <NUM>, one or more switches <NUM>, one or more power amplifiers (PAs) <NUM>, and one or more filters <NUM> for transmitting and receiving RF signals.

In an aspect, RF front end <NUM> may use one or more switches <NUM> to select a particular LNA <NUM> and the specified gain value based on a desired gain value for a particular application.

In an aspect, RF front end <NUM> may use one or more switches <NUM> to select a particular PA <NUM> and the specified gain value based on a desired gain value for a particular application.

In an aspect, each filter <NUM> can be coupled with a specific LNA <NUM> and/or PA <NUM>. In an aspect, RF front end <NUM> can use one or more switches <NUM> to select a transmit or receive path using a specified filter <NUM>, LNA <NUM>, and/or PA <NUM>, based on a configuration as specified by transceiver <NUM> and/or processing unit(s) <NUM>.

In an aspect, for example, the modem <NUM> can configure transceiver <NUM> to operate at a specified frequency and power level based on the UE configuration of the UE <NUM> and the communication protocol used by the modem <NUM>.

In an aspect, the modem <NUM> can be a multiband-multimode modem, which can process digital data and communicate with transceiver <NUM> such that the digital data is sent and received using transceiver <NUM>. In an aspect, the modem <NUM> can be multiband and be configured to support multiple frequency bands for a specific communications protocol. In an aspect, the modem <NUM> can be multimode and be configured to support multiple operating networks and communications protocols. In an aspect, the modem <NUM> can control one or more components of UE <NUM> (e.g., RF front end <NUM>, transceiver <NUM>) to enable transmission and/or reception of signals from the network based on a specified modem configuration.

As illustrated in <FIG>, an example communication component <NUM> may comprise a sidelink scheduler <NUM> that may be configured to perform all or part of the techniques presented herein, e.g., based, at least in part, on a link availability schedule <NUM>, sidelink negotiation information <NUM>, or some combination thereof. Sidelink scheduler <NUM> may generate or otherwise provide one or more sidelink schedules <NUM>, which may comprise or otherwise be based on a granularity <NUM>, timing offset <NUM>, or some combination thereof which may be useful in providing UE <NUM> with adequate information for communicating over a sidelink. In certain instances, a sidelink schedule selection indication <NUM> may be provided for determining which of the sidelink schedules <NUM> to use for sidelink communication. A sidelink schedule selection indication <NUM> may, for example, be set by the first UE and shared with the second UE, or vice versa. A communication resource allocation <NUM> may be used to determine a link availability schedule, and may be received from a network or other like external resource in certain example implementations. Also, as illustrated, a protocol stack <NUM> may be provided which includes one or more layers that may be used by the techniques herein.

With this in mind attention is drawn next to <FIG>, which is a timeline <NUM> illustrating some example signaling processes between two UEs (labeled UE1 and UE2) that may be used to establish sidelink unicast communication therebetween, in accordance with certain aspects of the present disclosure. An example process <NUM> is represented by a first message exchange comprising an RRC Connection Setup with direct link setup, and a second message exchange comprising a RRC Radio Bearer Config (for various QoS). Another example process <NUM> is represented by a message exchange comprising a MAC CE. Finally, an example process <NUM> is represented by L1 control and data transmission(s) and corresponding HARQ feedback transmissions. In timeline <NUM>, a PC5 interface is illustrated as an example that may be employed to support the techniques presented herein.

<FIG> illustrates portions of an example resource map <NUM> that may be indicative, at least in part, of information for communication resource allocation <NUM>, a link availability schedule <NUM>, and/or the like, in accordance with certain aspects of the present disclosure. By way of an example, an LTE/NR, TDD config may comprise a map indicating to a UE which slot is used for UL and which slot is used for DL, e. g, partial resource map <NUM> lists different subframes as allocated for uplink communication (marked "U"), downlink communication (marked "D"), or not used (marked "U").

<FIG> illustrates some example link availability schedules <NUM> for a UE, in accordance with certain aspects of the present disclosure. For example, for a Config-index1 example link availability schedule <NUM> shows a sequence of blocks representing all or part of one or more slots (e.g., depending on granularity) corresponding to communication resources (e.g., corresponding to time and frequency characteristics). In this example all of the blocks may be used for either transmission or reception. Here, for example, "T" represents an ability to transmit, "R" represents an ability to receive. Similarly, in a Config-index <NUM> example link availability schedule <NUM> shows a sequence of blocks representing all or part of one or more slots (e.g., depending on granularity) corresponding to communication resources (e.g., corresponding to time and frequency characteristics). Here, for example, in addition to "T" and "R" blocks, a "U" block is included which represents not available or not used (at least for the sidelink communication).

In certain example implementations as part of a sidelink scheduler <NUM> (see <FIG>), an RRC process or other like sidelink establishment procedure may be configured to support a unidirectional flow case, e.g., wherein a transmitting (TX) UE needs to know a receiving (RX) UE's link availability schedule. For a certain QoS for sidelink unicast flow, AS layer parameters may be configured for a DRB (Data radio bearer) before the data transport can occur. Here, for example, part of a MAC-config may be used to decide/configure the "link availability" which limits the TX UE's arbitrary resource usage for this DRB. Note, however, that in certain instances, a "link availability" does not necessary mean that resources in the schedule are "dedicated" to the TX UE for transmission. Instead, such may serve to help the TX UE to avoid selecting a resource where the peer UE is unwilling to be used for receiving. A TX UE may, for example, conduct resource selection within a boundary or the like of a peer UE's RX schedule.

For a unidirectional unicast flow (TX UE has traffic to RX UE, none in other direction), UE <NUM> (see <FIG>) may include one or more QoS parameters (e.g., data rate/periodicity, delay budget, etc.) along with proposed AS layer configurations in an RRC message <NUM> (e.g., may comprise an RRCConnectionSetupRequest, an RRCConnectionReconfiguration, or the like). UE <NUM> (again see <FIG>) may determine the high-level "link availability" for this flow, and include it in response message (e.g., an RRC message <NUM>). In certain instances, a link availability schedule may comprise a so-called "whitelist" based on resources available for reception. Conversely, in certain instances, a link availability schedule may comprise a so-called "blacklist" based on resources not available for reception. In still another example, a bitmap or other like data set may be used to indicate both resources that are available and are not available for reception. In certain example implementations, a Message <NUM> may also be used to represent a failure in negotiation, e.g., if UE <NUM> is so busy/congested and QoS demand from UE <NUM> is deemed to be too high to support.

In certain example implementations as part of a sidelink scheduler <NUM> (see <FIG>), an RRC process or other like sidelink establishment procedure may be configured to support a bidirectional flow sidelink unicast communication. Here, for example, suppose an RRC process or other like procedure is to negotiate parameters for bi-directional flow (reciprocal traffic). Accordingly, in this situation, each peer UE acts as a TX UE and also as a RX UE. Thus, link availability schedule(s) may comprise TX/RX scheduling. Depending on an estimated traffic amount or some other aspect peer UEs may agree on different TX/RX splits (e.g., <NUM>/<NUM>, <NUM>/<NUM> or <NUM>/<NUM>,. <NUM>/<NUM> or <NUM>/<NUM>, etc.) An RRC process or other like procedure may be configured to allow a more extensive negotiation process to occur, e.g., as both UEs may need to examine its own link availability schedule and the peer UE's link availability schedule to agree upon one or more sidelink schedules and/or candidate or alternate sidelink schedules. In certain instances, such processes may comprise a <NUM>-way or <NUM>-way "handshake" based process or the like. Note that the TX/RX schedule(s) that may be exchanged in some implementations may be considered somewhat "raw" and still subject to a final resource selection agreement, because some sidelink communication may use a common channel shared with other UEs in proximity, such that every slot/subframe may still be up for contention. In certain instances, bidirectional flow sidelink schedule negotiation may also be supported by establishing at least two unidirectional flows, each of which may be individually negotiated, e.g., as previously described.

An example Tx/Rx schedule negotiation may comprise a two-step process in which a combined TX/RX sidelink schedule may be established based, at least in part, on the link availability schedules of the UEs. Here, for example, in a first step, each UE may share sidelink negotiation information corresponding to their individual TX/RX available and/or TX/RX non-availability, e.g., based, at least in part on respective link availability schedules, etc. In certain example implementations such information may comprise bitmaps or other like easily comparable data formats. Two applicable bitmaps, e.g., one from each UE, may be processed (e.g., applying a logical AND operation, etc.) to quickly identify commonality regarding the blocks (e.g., each comprising one or more slots). In a second step, the UEs may determine which of these available blocks or portions thereof may comprise TX slots and RX slots, or the like. Such a determination may, for example, take into account a QoS or other like aspect associated with a sidelink unicast communication. If the resulting TX/RX (and possibly unavailable) candidate sidelink schedule may not satisfy a QoS of the DRB, then the attempted sidelink connection may be deemed to have failed. However, in some instances, it may be determined that the QoS or other pertinent factor may be changed in some manner (e.g., lowered, degraded, etc.) to allow the attempted sidelink connection to continue accordingly. Indeed, as described in greater detail below, in certain situations, it may be useful for the UEs to adapt/reconfigure sidelink unicast connections in a dynamic manner, e.g., to account for changing conditions, etc..

Another example Tx/Rx schedule negotiation may comprise a one-step process in which a combined TX/RX sidelink schedule may be established based, at least in part, on the link availability schedules of the UEs. Here, for example, a UE1 may propose one or more TX/RX sidelink schedules to a UE2. A candidate sidelink schedule may, for example, be based at least in part on knowledge of the traffic demands (in both directions) and applicable constraints on UE1 (e.g., QoS, data, timing, etc.). In response, if two or more candidate sidelink schedules have been proved, the UE2 may select one that is deemed acceptable. In certain instances, the UE1 may indicate a priority or preference with regard to each of the candidate sidelink schedules, e.g., so as to inform the UE2 as to a preferred order of selection. The UE2 may send an indication of a selected candidate sidelink schedule to the UE1. Also, as mentioned, in some implementations, the UE1 and UE2 may be configured to allow dynamic changes, such as, changing from one candidate sidelink schedule to another at various times, e.g., by sending an applicable indication, etc. If the UE2 is unable to agree with the candidate schedule(s) as presented by UE1, then UE2 may reject the message (and optionally include one or more alternative candidate sidelink schedules for UE1 to consider). In certain example implementations,.

As suggested, in certain implementations, it may be useful for the UEs to dynamically change or otherwise adjust the sidelink schedule being used. For example, a change may be useful if one of the UEs has engaged new traffic and as such needs to alter the RX portion of the sidelink schedule. In another example, with regard to the TX portion of the sidelink schedule, a change may be useful to a UE having some bursty traffic for a flow.

In certain example implementations, one or more sidelink schedules may be re-negotiated by restarting the negotiation/connection processes, e.g., as previously described. Thus, by way of an RRC reconfiguration, new sidelink schedule(s) may be negotiated for the DRB. However, some delay may be expected.

In another example, a sidelink schedule may be quickly changed based on an indication from one UE to the other UE to switch to a different sidelink schedule within a set of candidate sidelink schedules previously considered. Here, for example, such example sidelink schedule changes may be performed via MAC CE (e.g., L2 signaling, or the like), with a set of candidate sidelink schedules being pre-negotiated, e.g., during RRC. MAC CE may, for example, respond to an indication (e.g., an index, identifier, etc.) of the new sidelink schedule to trigger a switch with the new schedule so the UE may adjust its resource selection bounds correspondingly.

A sidelink schedule may comprise various formats depending upon the situation, design aspects, or the like. In certain non-limiting example implementations, a sidelink schedule may indicate a schedule granularity, e.g., for blocks or slots being considered. For example, a schedule granularity may indicate <NUM>, <NUM> , <NUM>, <NUM>, <NUM>,. , M subframes, e.g., depending on a latency requirement. If a "N-subframe" time period is blocked by an RX UE as not eligible for "RX", then traffic arrival during such time period may suffer a delay up to N subframes. A sidelink schedule may also be indicative of its purpose or type, e.g., an Rx-only schedule (link availability), or TX/RX schedule. A sidelink schedule may also indicate a corresponding starting frame (e.g., timing offset) and periodicity, e.g., for the bitmap configuration. In some instances, a common configuration may be pre-configured or network-configured in RRC signaling, possibly allowing an index or the like to be used.

Attention is drawn next to <FIG> which illustrates aspects of an example sidelink scheduling process <NUM>, in accordance with certain aspects of the present disclosure. Here, an example "raw" schedule <NUM> illustrates available resources for a UE marked with an "A", which may be used for transmit or receive, and other unavailable resources marked with a "U". This raw schedule may comprise or be based at least in part on a link availability schedule and/or communication resource allocation. A corresponding proposed sidelink schedule <NUM>, which may be provided or otherwise indicated in sidelink negotiation information to a peer UE, shows that certain "A" marked resources in the raw schedule <NUM> may be purposed accordingly for possible transmission (marked with a "T") or possible reception (marked with an "R). A further corresponding example candidate sidelink schedule <NUM> may be negotiated in which the resources may be reduced to match a desired granularity, parameter, etc. As illustrated by the reduced width of candidate sidelink scheduled <NUM> compared to the proposed sidelink schedule <NUM>, the granularity has been reduced (at least with regard to time) for the resources to be used. Similarly, a granularity with regard to frequency may also change as a sidelink schedule becomes agreed to during negotiation.

<FIG> shows an example situation <NUM> in which a UE1 may need to be involved in sidelink communication with a plurality of UEs. Here, there may be a need to determine a "link availability" schedule involving multiple links. In this example, UE1 may currently be using some resources to TX to UE <NUM> in consideration of link availability schedule <NUM>, while other available resources are not used. UE3 and UE <NUM> may each intend to establish a unidirectional flow to UE <NUM>, and thus, for example, UE1 may use or otherwise indicate link availability scheduled <NUM>. Thus, UE3 and UE4 may each attempt to negotiate use of the "A" (available) blocks but not the "U" block corresponding to the TX block of schedule <NUM>. It should be understood, that UE1 may receive during the three "A" blocks in both schedule <NUM> and <NUM>.

<FIG> shows an example situation <NUM> in which a UE1 may need to be involved in sidelink communication with a plurality of UEs. Here, there may be a need to determine a "TX/RX/U" schedule involving multiple links. In this example, UE1 may be currently using some resource to TX/RX with UE2, other resources are not used, e.g., in consideration of link availability schedule <NUM>. If UE1 intends to establish a bidirectional flow to UE3, then UE1 may consider using link availability schedule <NUM> in the negotiation with UE3, which orthogonizes the two links (UE1-UE2, and UE1-UE3) in time domain. Here, UE3 may propose to in RX mode in block <NUM>, while UE2 is in an RX mode in blocks <NUM> and slot <NUM>. Alternatively, with reference to example link availability schedule <NUM>, UE1 may propose to reuse the part or all of the T/R slots for both UE1-UE2 and UE1-UE3 links, and keep unused slots for future use.

Attention is drawn next to <FIG>, which is a flow-diagram illustrating an example method <NUM> for use in a UE, for example, as in <FIG>, configured for sidelink unicast communication based, at least in part, on one or more sidelink schedule(s), in accordance with certain aspects of the present disclosure.

At example block <NUM>, a first UE may obtain a link availability schedule indicating, at least in part, communication resources available for use by at least the first UE for sidelink unicast communication. By way of some examples, all or part of a link availability schedule may be based, at least in part, on local processing, configuration or other like usage considerations of the first UE, communication resource allocations associated with one or more networks, or the like or some combination thereof.

At example block <NUM>, the first UE may identify a second UE to attempt to engage in a sidelink unicast communication. Here, for example, the first UE may identify the second UE based, at least in part, on signals received from the second UE, and/or signals received from one or more other devices, preconfigured information stored in a memory of the UE, sensor-based information, user inputs, etc..

At example block <NUM>, the first UE may establish a sidelink schedule with the second UE. Here, for example, the sidelink schedule may correspond to at least a subset of the communication resources indicated by the link availability schedule. At optional block <NUM>, the first UE may exchange sidelink negotiation information with the second UE. At optional block <NUM>, the first UE may receive sidelink negotiation information from the second UE. At optional block <NUM>, the first UE may identify that one of two or more candidate sidelink schedules is serve as the sidelink schedule. At optional block <NUM>, the first UE may receive an indication from the second UE that one of two or more candidate sidelink schedules is serve as the sidelink schedule.

At example block <NUM>, the first UE may establish a sidelink with the second UE, and at example block <NUM>, the first UE may communicate (transmit and/or receive), via the sidelink, with the second UE using at least a portion of the communication resources per the sidelink schedule.

The electromagnetic spectrum is often subdivided by various authors/entities into differently identified classes, bands, channels, etc., based on frequency/wavelength. For example, a portion of the electromagnetic spectrum from <NUM> to <NUM> is commonly known as the radio spectrum with the corresponding electromagnetic waves often called radio waves.

The International Telecommunications Union (ITU), for example, currently identifies twelve differently named bands in the radio spectrum based on powers of ten meters of wavelength. Here, for example, of particular interest to modern wireless communications are certain radio frequencies/bands within the ITU's very high frequency (VHF) band (<NUM> - <NUM>), ultra-high frequency (UHF) band (<NUM> - <NUM>), super high frequency (SHF) band (<NUM> - <NUM>), and/or extremely high frequency (EHF) band (<NUM> - <NUM>).

In another example, the Institute of Electrical and Electronics Engineers (IEEE) recognizes the same VHF and UHF bands of the ITU, but divides the radio spectrum (<NUM> - <NUM>), corresponding to the ITU's UHF, SHF and EHF bands, into ten differently named bands.

One of the issues that may arise from having different authors/entities naming portions of the radio spectrum is that some potential confusion may arise. For example, the ITU's EHF band (<NUM> - <NUM>) corresponds to wavelengths between <NUM> and <NUM> and as such is often referred to a millimeter wave band. However, the (narrower) IEEE band designated as the "G" band (<NUM> - <NUM>) is also often referred to as a millimeter wave band.

For <NUM> new radio (NR), two initial operating bands have been identified as frequency range designations FR1 (<NUM>-<NUM>) and FR2 (<NUM> - <NUM>). It is expected that other frequency range designations may be identified for <NUM>, or later generations. Even though a portion of FR1 is greater than both <NUM> (> <NUM>) and <NUM> (> <NUM>), FR1 is often referred to as a Sub-<NUM> band or a Sub-<NUM> band in various documents and articles regarding <NUM> NR topics. A similar nomenclature issue sometimes occurs with regard to FR2 in various documents and articles regarding <NUM> NR topics. While a portion of FR2 is less than <NUM> (< <NUM>, e.g., the lower end of the EHF band), FR2 is often referred to as a millimeter wave band in various documents and articles regarding <NUM> NR topics. Additionally, all or some of the frequencies between the upper bound of FR1 (currently, <NUM>) and the lower band of FR2 (currently, <NUM>) are often referred to as mid-band frequencies.

With the above aspects in mind, unless specifically stated otherwise, it should be understood that the term "sub-<NUM>" or the like if used herein by way of example may represent all or part of FR1 for 5GNR. Further, unless specifically stated otherwise, it should be understood that the term "millimeter wave" if used herein by way of example may represent all or part of FR2 for <NUM> NR, and/or all or part of the EHF band.

It should also be understood that the terms "sub-<NUM>" and "millimeter wave" are also intended herein to represent modifications to such example frequency bands that may occur do to author/entity decisions regarding wireless communications, e.g., as presented by example herein. For example, unless specifically stated otherwise, it should be understood that the terms "sub-<NUM>" or "millimeter wave" if used herein may also represent respective (non-overlapping) portions of the so-called mid-band frequencies.

It should be understood that the above examples are not necessarily intended to limit claimed subject matter. For example, unless specifically recited, claimed subject matter relating to wireless communications is not necessarily intended to be limited to any particular author/entity defined frequency band, or the like.

For synchronous operation, the UEs may have similar frame timing, and transmissions from different UEs may be approximately aligned in time. For asynchronous operation, the UEs may have different frame timing, and transmissions from different UEs may not be aligned in time.

The various illustrative blocks and modules described in connection with the disclosure herein may be implemented or performed with a general-purpose processor, a DSP, an ASIC, an FPGA, or other PLD, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein, e.g., with regard to one or more processing units.

By way of example, and not limitation, non-transitory computer-readable media may include RAM, ROM, electrically erasable programmable ROM (EEPROM), flash memory, compact disk (CD) ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other non-transitory medium that can be used to carry or store desired program code means in the form of instructions or data structures and that can be accessed by a general-purpose or special-purpose computer, or a general-purpose or special-purpose processor.

Claim 1:
A method for use in sidelink unicast communication, the method comprising, at a first user equipment, UE, (<NUM>):
obtaining (<NUM>) a link availability schedule indicating, at least in part, communication resources available for use by at least the first UE (<NUM>) for sidelink unicast communication;
identifying (<NUM>) a second UE (<NUM>) to attempt to engage in a sidelink unicast communication;
establishing (<NUM>) a sidelink schedule with the second UE (<NUM>), the sidelink schedule corresponding to at least a subset of the communication resources indicated by the link availability schedule, wherein establishing the sidelink schedule comprises exchanging sidelink negotiation information with the second UE (<NUM>), and wherein at least a portion of the sidelink negotiation information provided by the first UE (<NUM>) to the second UE (<NUM>) is based, at least in part, on the link availability schedule;
establishing (<NUM>) a sidelink with the second UE (<NUM>); and
communicating (<NUM>), via the sidelink, with the second UE (<NUM>) using at least a portion of the communication resources per the sidelink schedule.