Explicit requirements design for UE cooperation

Abstract

A method, system, and computer-readable medium are disclosed for performing an operation that includes detecting one or more triggers for a supporting UE to send an explicit request for inter-UE coordination, generating an explicit request to be sent to the supporting UE in response to the detection of one or more triggers, and sending the explicit request to the supporting UE.

Description

[Technical field]

[0001] The present disclosure relates to wireless devices, and more particularly, to apparatus, systems, and methods for wireless devices to implement various cellular communication technologies. [Background technology]

[0002] Wireless communication networks provide an integrated communications platform and telecommunications services to wireless user devices. Exemplary telecommunications services include telephony, data (e.g., voice, audio, and / or video data), messaging, Internet access, and / or other services. Wireless communication networks have radio access nodes that exchange wireless signals with wireless user devices using radio network protocols such as those described in various telecommunications standards promulgated by the 3rd Generation Partnership Project (3GPP). Exemplary wireless communication networks include Code Division Multiple Access (CDMA) networks, Time Division Multiple Access (TDMA) networks, Frequency Division Multiple Access (FDMA) networks, Orthogonal Frequency Division Multiple Access (OFDMA) networks, Long Term Evolution (LTE), and Fifth Generation New Radio (5G NR). Wireless communication networks facilitate mobile broadband services using technologies such as OFDM, Multiple Input Multiple Output (MIMO), advanced channel coding, Massive MIMO, beamforming, and / or other features.

[0003] More recently, wireless communication networks have integrated vehicular communications, where vehicles or other mobile devices communicate or exchange vehicle-related information. Such wireless communication networks are referred to as vehicle-to-everything (V2X) communication systems. A V2X communication system may be characterized as a network where vehicles, UEs, and / or other devices and network entities exchange communications to coordinate traffic activities, among other possible purposes. V2X communications include communications conveyed between vehicles (e.g., wireless or communication devices that form part of, are included in, or are otherwise carried by, a vehicle) and various other devices. V2X communications include vehicle-to-pedestrian (V2P), vehicle-to-infrastructure (V21), vehicle-to-network (V2N), and vehicle-to-vehicle (V2V) communications, as well as communications between vehicles and other possible network entities or devices. V2X communications may also refer to communications between other non-vehicular devices that participate in a V2X network for the purpose of sharing V2X-related information. Summary of the Invention

[0004] According to one aspect of the disclosure, a method includes detecting one or more triggers for sending an explicit request for UE-to-UE cooperation from a supporting UE, generating an explicit request sent to the supporting UE in response to detecting the one or more triggers, and transmitting the explicit request to the supporting UE.

[0005] The foregoing implementations can be implemented using a computer system including a computer-implemented method, a non-transitory computer-readable medium storing computer-readable instructions for performing the computer-implemented method, and a computer memory interoperably coupled with a hardware processor configured to execute the computer-implemented method or the instructions stored in the non-transitory computer-readable medium. Each of these and other embodiments can optionally include one or more of the following features.

[0006] In some implementations, the one or more triggers include determining that the supporting UE is capable of sending inter-UE coordination information.

[0007] In some implementations, determining that the supporting UE is capable of sending UE-to-UE coordination information includes determining that the supporting UE is capable of sending the UE-to-UE coordination information using one of PC5-RRC signaling or higher layer signaling with the supporting UE.

[0008] In some implementations, the one or more triggers further include determining that the transport block for transmission by the UE satisfies at least one of a plurality of secondary conditions, the plurality of secondary conditions including: a latency requirement of the transport block is greater than a predetermined threshold; a detection result at the UE is unsatisfactory; a data priority of the transport block is greater than a predetermined threshold; a channel busy ratio is greater than a predetermined threshold; and the transport block is scheduled to be sent to a supporting UE.

[0009] In some implementations, generating the explicit request to be sent to the supporting UE includes generating a container for the explicit request, the container comprising one of a Medium Access Control (MAC) Control Element (CE), a PC5-Radio Resource Control (PC5-RRC) message, or a Sidelink Control Information (SCI) Phase 2 message.

[0010] In some implementations, the explicit request may include a priority value, a number of requested subchannels, a resource block group to be used for UE-to-UE coordination, a resource reservation interval, a source ID, a destination ID, a number of requested time resources, an indication of preferred or non-preferred resources, an indication of whether UE-to-UE coordination information is included in the sidelink control information (SCI) phase 2 signaling, an indication of the start time of the window of requested resources, an indication of the duration of the window of requested resources, a resource reselection counter (CRC), a resource reservation interval (REI), a resource reservation counter (RR), a resource reservation counter (RC ... resel), or a number N of combinations of (time resource indicator value, frequency resource indicator value, resource reservation periodicity).

[0011] In some implementations, the number of requested subchannels is:

number

number

[0012] In some implementations, the resource reservation interval is:

number

number

[0013] In some implementations, the indication of the start time of the window of the requested resource and the indication of the duration of the window of the requested resource are joint indications.

[0014] In some implementations, sending the explicit request to the assisting UE includes selecting a radio resource for sending the explicit request.

[0015] In some implementations, selecting radio resources for transmitting the explicit request includes one of: selecting from a set of resources allocated for explicit requests or selecting radio resources for the explicit request using resource selection.

[0016] In some implementations, selecting radio resources for an explicit request using resource selection may include determining a priority value for the explicit request, determining that a number of subchannels to be used for the explicit request is equal to 1, determining a number of time resources for the explicit request, determining a latency requirement for the explicit request, determining that a resource reservation periodicity for the explicit request is equal to 0, or determining a resource reselection counter (C) for the explicit request. resel ) is equal to 0.

[0017] In some implementations, the cast type of the explicit request is one of unicast or groupcast.

[0018] In some implementations, sending the explicit request to the supporting UE includes multiplexing the explicit request with the sidelink data transmission.

[0019] In some implementations, multiplexing the explicit request with the sidelink data transmission includes determining to multiplex the explicit request with the sidelink data transmission in response to at least one of: determining that a priority of a transport block associated with the explicit request is greater than or equal to a priority of the sidelink transmission; or determining that a latency of a transport block associated with the explicit request is less than or equal to a latency of the sidelink data transmission plus an offset.

[0020] 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 become apparent from the description and drawings, and from the claims. [Brief description of the drawings]

[0021] [Figure 1] FIG. 1 illustrates an example of a vehicle-to-everything (V2X) communication system 100, according to some embodiments.

[0022] [Diagram 2] FIG. 2 illustrates a communication chart of an assisted user equipment (UE) requesting inter-UE coordination information from a supporting UE, according to some embodiments.

[0023] [Figure 3A] 1 illustrates a flowchart of an exemplary method according to some embodiments.

[0024] [Figure 3B] 1 illustrates a flowchart of another exemplary method, according to some embodiments.

[0025] [Figure 4] FIG. 1 illustrates a UE in accordance with some embodiments.

[0026] [Diagram 5] FIG. 2 illustrates an access node according to some embodiments. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0027] One of the features being developed by the 3rd Generation Partnership Project (3GPP) for Vehicle-to-Everything (V2X) is UE-to-UE coordination. This feature, also called an extension of "Mode 2", allows a UE (called an "Assisting UE" or "UE-A") to assist another UE (called an "Assisted UE" or "UE-B") with resource selection. There are two schemes for UE-to-UE coordination. In the first scheme, "Scheme 1", UE-A provides UE-B with a set of preferred and / or non-preferred resources to be used by UE-B. In the second scheme, "Scheme 2", UE-A provides UE-B with an indication of the existence of an expected contention on resources as indicated by UE-B's SCI.

[0028] One of the advantages of inter-UE cooperation is the mitigation of the hidden node problem in V2X systems. The hidden node problem occurs in a scenario where two (or more) different UEs are communicating with a common UE, and the two different UEs are hiding from each other. In this scenario, since the two different UEs are hiding from each other, the UEs may use conflicting resources to communicate with the common UE. As a result, there is a high probability that at least one of the communications to the common UE will fail. Inter-UE cooperation mitigates this problem by allowing the common UE to coordinate resources used by the two different UEs, thereby avoiding the two different UEs from using conflicting resources.

[0029] Another advantage of inter-UE cooperation is the mitigation of the half-duplex problem. The half-duplex problem occurs in a scenario where a transmitter UE (e.g., UE-B) has a transport block (TB) to transmit to a receiver UE (e.g., UE-A), but the receiver UE cannot receive sidelink data in certain slots due to half-duplex (i.e., the receiver UE may be transmitting in those slots and the receiver UE does not support simultaneous transmission and reception). Inter-UE cooperation mitigates this problem by allowing the receiver UE to control the resources used by the transmitter UE. Thus, the receiver UE can restrict the transmitter UE from using resources that the receiver UE has dedicated to other communications. In scheme 1, the set of resources selected for UE-B's transmission is in the form of candidate single-slot resource selection (e.g., as specified in TS 38.214 section 8.1.4).

[0030] Recently, 3GPP agreement specifies that UE-to-UE cooperation may be triggered by an explicit request from UE-B. Details of the explicit request are under development. This disclosure describes methods and systems for enabling explicit requests, including methods and systems related to triggering conditions for an explicit request, content of the explicit request, transmission of the explicit request, and multiplexing the explicit request with data transmission. By enabling explicit requests, the disclosed methods and systems enable UEs operating in a V2X system to avoid communication problems such as the hidden node problem and half-duplex problem mentioned above.

[0031] 1 is a diagram illustrating an example of a vehicle-to-everything (V2X) communication system 100, according to some embodiments. It should be noted that the system of FIG. 1 is only one example of a possible system, and features of the present disclosure may be implemented in other wireless communication systems.

[0032] The following description is provided for an example V2X communication system 100 operating in conjunction with a fifth generation (5G) network as provided by the 3rd Generation Partnership Project (3GPP) Technical Specifications (TS). However, the example embodiments are not limited in this respect, and the described embodiments may be applied 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. Additionally, other types of communication standards are possible, including future 3GPP systems (e.g., sixth generation (6G)) systems, IEEE 802.16 protocols (e.g., WMAN, WiMAX, etc.), and the like. Although aspects may be described herein using terminology generally associated with 5G NR, aspects of the present disclosure may be applied to other systems, such as systems subsequent to 3G, 4G, and / or 5G (e.g., 6G).

[0033] V2X communications may conform to, for example, the 3GPP Cellular V2X (C-V2X) specification or one or more other or subsequent standards through which vehicles and other devices and network entities may communicate. V2X communications may utilize both long-range (e.g., cellular) and short- to medium-range (e.g., non-cellular) communications. Cellular-enabled V2X communications may be referred to as Cellular V2X (C-V2X) communications. C-V2X systems may use a variety of cellular radio access technologies (RATs), such as 4G LTE or 5G NR RAT (or a RAT subsequent to 5G, e.g., 6G RAT). Certain LTE standards that may be used in V2X systems may be referred to as LTE-Vehicle (LTE-V) standards.

[0034] As shown in the figure, the V2X communication system 100 includes several user devices. When used herein in the context of a V2X system and as defined above, the term "user device" may generally refer to devices associated with mobile actors or traffic participants in a V2X system, i.e., mobile (movable) communication devices such as vehicular and pedestrian user equipment (PUE) devices. More specifically, the V2X communication system 100 includes two UEs 105 (UEs 105-1 and UEs 105-2 collectively referred to as one or more "UEs 105"), two base stations 110 (base stations 110-1 and 110-2 collectively referred to as one or more "base stations 110"), two cells 115 (cells 115-1 and 115-2 collectively referred to as one or more "cells 115"), and one or more servers 135 in a core network (CN) 140 connected to an Internet 145.

[0035] As shown, certain user devices may be able to communicate directly with each other, i.e., without involving an intermediate infrastructure device such as base station 110-1. As shown, UE 105-1 may have V2X-related communications directly with UE 105-2. Similarly, UE 105-2 may have V2X-related communications directly with UE 105-2. Such peer-to-peer communications may utilize a "sidelink" interface, such as a PC5 interface. In certain embodiments, the PC5 interface supports direct cellular communications between user devices (e.g., between UEs 105), and the Uu interface supports cellular communications with infrastructure devices, such as base stations. For example, UE 105 may use the PC-5 interface for radio resource control (RRC) signaling exchange between UEs. The PC5 / Uu interface is used merely as an example, and PC5, as used herein, may represent various other possible wireless communication technologies that enable direct sidelink communications between user devices, and Uu may represent cellular communications between user devices and infrastructure devices, such as base stations.

[0036] In some embodiments, the UEs 105 may be physical hardware devices capable of running one or more applications and accessing network services over one or more radio links 120 with corresponding base stations 110 and communicating with each other over a sidelink 125. The links 120 may enable the UEs 105 to transmit and receive data from the base stations 110 providing the links 120. The sidelinks 125 may enable the UEs 105 to transmit and receive data with each other. The sidelinks 125 between the UEs 105 may include one or more channels for transmitting information from the UE 105-1 to the UE 105-2 and vice versa, and / or between the UE 105 and a UE type RSU (not shown in FIG. 1 ). The channels may include a physical sidelink broadcast channel (PSBCH), a physical sidelink control channel (PSCCH), a physical sidelink discovery channel (PSDCH), a physical sidelink shared channel (PSSCH), and / or any other similar communication channel. In some examples, the PSSCH may be scheduled by sidelink control information (SCI) carried in the sidelink PSCCH. The SCI in NR V2X is transmitted in two stages. The first stage SCI in NR V2X is carried on the PSCCH and the second stage SCI is carried on the corresponding PSSCH. For example, the first stage SCI is carried on the PSCCH for sensing and broadcast communication. 段階 A second SCI is applied and carries the remaining information for data scheduling of unicast / groupcast data transmissions. 段階の By applying SCI, a two-stage SCI can be used.

[0037] The air interface between two or more UEs 105 and the UE 105 and UE type RSUs (not shown in FIG. 1) may be referred to as a PC5 interface. To transmit / receive data to / from one or more eNBs 110 or UEs 105, the UE 105 may include a transmitter / receiver (or alternatively, a transceiver), memory, one or more processors, and / or other similar components that enable the UE 105 to operate according to one or more wireless communication protocols and / or one or more cellular communication protocols. The UE 105 may have multiple antenna elements that enable the UE 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, the UE 105 may connect with a base station 110-1 via a link 120 and simultaneously connect with a UE 105-2 via a sidelink 125.

[0038] In some embodiments, the UE 105 is configured to use a resource pool for sidelink communication. The sidelink resource pool may be divided into multiple time slots, frequency channels, and frequency subchannels. In some examples, the UE 105 performs sidelink transmissions that are synchronized and aligned with slot boundaries. The UE may be expected to select several slots and subchannels for transmission of a transport block. In some aspects, the UE may use different subchannels to transmit a transport block across multiple slots within its resource selection window, which may be determined using packet delay budget information. In one embodiment, the UE may use a time-discontinuous transmission with a channel access granularity equal to one slot (the total TX duration for one transport block (TB) is N slots, e.g., N=1, 2, 3, 4...), and the channel access boundaries may be aligned from a system perspective at the slot level.

[0039] In some embodiments, the V2X communication system 100 supports different cast types, including unicast, broadcast, and groupcast (or multicast) communications. Unicast refers to direct communications between two UEs. Broadcast refers to communications broadcast by a single UE to multiple other UEs. Groupcast refers to communications sent from a single UE to a set of UEs that meet some condition (e.g., are members of a particular group).

[0040] In some embodiments, the V2X communication system 100 implements UE-to-UE coordination. Thus, one or more user devices of the V2X communication system 100 may support UE-to-UE coordination. As an example, the UE 105-1 may be an assisting UE (UE-A) and the UE 105-2 may be an assisted UE (UE-B), or vice versa. In this example, the UE-A controls resources used by the UE-B. As described above, the UE-B (e.g., the UE 105-2) may send an explicit request for UE-to-UE coordination information to the UE-A (e.g., the UE 105-1).

[0041] In some embodiments, the UE-B is configured with a trigger condition for generating an explicit request for UE-to-UE coordination. The UE-B may be configured to generate the explicit request in response to determining that the trigger condition is satisfied. In some examples, the first trigger condition is knowledge of the presence of a UE-A capable of sending UE-to-UE coordination messages. Thus, the first trigger condition is that the UE-B knows a UE-A capable of participating in UE-to-UE coordination. The UE-B may be configured to use one of a number of alternative methods for determining that the UE-A can participate in UE-to-UE coordination. In a first alternative method applicable to unicast communication, the UE-B determines that the UE-A can transmit UE-to-UE coordination information via PC5-RRC communication. In a second alternative method applicable in unicast or groupcast communication, the UE-B uses higher layer signaling (e.g., V2X layer or application layer signaling) with the UE-A to determine that the UE-A can transmit UE-to-UE coordination information. Other alternative methods are also possible.

[0042] In some examples, the second trigger condition is that the transport block for transmission by UE-B satisfies one or more secondary conditions. The first secondary condition may be that the latency requirement of the transport block, e.g., packet delay budget (PDB), is greater than a predefined threshold. The explicit request and exchange of IUC between UE-A and UE-B takes time (e.g., 10 slots). If the UE-B's TB needs to be delivered in a short time (e.g., 8 slots), UE-B may decide not to trigger the IUC because by the time UE-B receives the IUC from UE-A, it may already be too late to transmit the UE-B's TB due to its latency requirement. The second secondary condition may be a determination that the sensing result at UE-B is not satisfactory. As an example, the sensing result at UE-B is not satisfactory in a scenario where UE-B performs only partial or no sensing, or where UE-B does not monitor the channel due to scheduled transmission in a large number of slots (e.g., a threshold number of slots). As another example, when the number of detected slots at UE-B is below a certain threshold, which may be configured (pre-) by a resource pool, the detection result at UE-B is not satisfactory.

[0043] The third secondary condition may be that the data priority of the transport block is greater than a predefined threshold (e.g., a threshold indicating high priority data). If the data priority of the transport block is greater than a predefined threshold, UE-B may spend resources / time to obtain IUC from UE-A, which aims to improve transmission reliability. The fourth secondary condition is that the channel busy ratio (e.g., of a resource pool) is greater than a predefined threshold. If the CBR is high, the channel is more congested and the data transmission of UE-B is more likely to collide with the transmission of another UE. Therefore, UE-B may allocate time / resources to obtain IUC from UE-A to further improve its data transmission reliability. The fifth secondary condition may be that the transport block is scheduled to be transmitted to UE-A. Here, UE-B may allocate resources / time to obtain IUC from UE-A since UE-B knows that UE-A can provide information.

[0044] In some embodiments, the container of the explicit request may be a Medium Access Control (MAC) control element (CE), a PC5-RRC message transmitted over the PSSCH, or an SCI phase 2 message. In some examples, the content of the explicit request may include a priority value (e.g., as described in TS 38.214 section 8.1.5), a number of subchannels, a resource block group assigned for inter-UE coordination, a resource reservation interval, a source ID, a destination ID, a number of time domain resources for the transport block, an indication of preferred or non-preferred resources, an indication of whether inter-UE coordination information is (further) included in SCI phase 2, an indication of the start time of a window of requested resources (e.g., preferred or non-preferred resources), a duration of the window of requested resources, and a resource reselection counter (CRC). resel), and the number N of combinations of time resource indicator value (TRIV), frequency RIV (FRIV), and resource reservation periodicity. Note that the PSCCH / PSSCH allocation is indicated via the Frequency Resource Allocation and Time Resource Allocation fields in the form of time RIV (TRIV) and RIV (FRIV).

[0045] In one example, the number of subchannels is

number

number

number

number

[0046] In some embodiments, the explicit request includes a joint indication of the start time and duration of a window of resources. In these embodiments, the start time and duration are represented using a Resource Indicator Value (RIV), which is calculated as follows:

number

[0047] In some embodiments, the explicit request includes a separate indication of the start time and duration of the window of resources. In some examples, the start time is indicated in the explicit request using one of several alternatives. The first alternative is a direct indication. In this alternative, the explicit request is indicated up to two minutes after the slot carrying the explicit request. A The explicit request includes an "A" bit to indicate the logical slot of the first explicit request (i.e., the start of the window). In case of multiple transmissions of the same explicit request, the bit represents the number of slots from the slot carrying the last explicit request. The maximum value of A may be pre-configured per resource pool or may be configured via PC5-RRC. A second alternative uses a pre-defined table of slot numbers. In this alternative, the explicit request includes a desired table entry index indicating the number of slots from the slot carrying the explicit request to the start of the window. In one example, the pre-defined table of slot numbers is configured per resource pool or via PC5-RRC.

[0048] In embodiments where the explicit request includes separate indications of the start time and duration of a window of a resource, the duration may be indicated in the explicit request using one of several alternatives. The first alternative is a direct indication. In this alternative, the explicit request includes up to two suffixes representing the duration of the window. B The explicit request includes a "B" bit indicating the number of logical slots in the window. The maximum value of B may be pre-configured per resource pool or may be configured via PC5-RRC. A second alternative uses a pre-defined table of slot numbers. In this alternative, the explicit request includes a desired table entry index indicating the number of slots representing the duration of the window. In one example, the pre-defined table of slot numbers is configured per resource pool or via PC5-RRC.

[0049] In some embodiments, C resel may be indicated in an explicit request using one of several alternatives. The first alternative is direct indication. In this alternative, an explicit request may be D Possible C resel The maximum value of D may be pre-configured per resource pool or may be configured via PC5-RRC. resel In this alternative, an explicit request specifies the desired C value in the table. resel The desired table entry index for indicating the value. In one example, resel The value is configured per resource pool or via PC5-RRC.

[0050] In some embodiments, UE-B is configured to select resources for transmitting the explicit request using one of several alternative methods. In a first alternative method, UE-B selects resources dedicated to the explicit request. In one example, the dedicated resources are reserved by either UE-A or UE-B with some periodicity during the initial capability exchange phase. In another example, the dedicated resources are configured per resource pool.

[0051] In a second alternative, the UE-B uses resource selection to select resources for the explicit request. In some examples, the resource selection is based on a priority value (e.g., prio Tx ) is used. In these examples, the priority value may be pre-configured by the resource pool or via PC5-RRC. In other examples, the priority value depends on the priority value of the transport block to be transmitted. In yet other examples, UE-B has another transport block to transmit to UE-A along with the explicit request. In these examples, the lower of the respective priority values ​​associated with the transport block and the explicit request is used as the priority value.

[0052] Furthermore, in the second alternative, the number of subchannels used for explicit requests (L subch ) is equal to 1. Furthermore, UE-B can use one of several alternatives to determine the number of time resources for the explicit request. In a first alternative, the number of time resources is pre-determined (e.g., 1). In a second alternative, the number of time resources is pre-configured by a resource pool or via PC5-RRC.

[0053] Furthermore, in a second alternative, the UE-B determines the PDB for resources used for the explicit request using one of several alternatives: In a first alternative, the PDB is equal to the PDB of the transport block for transmission minus some offset. The offset is used by the UE-B to receive and process the UE-B coordinated information; In a second alternative, the PDB is pre-configured by the resource pool or via PC5-RRC; In a third alternative, the PDB depends on the PDB of the transport block for transmission.

[0054] In some cases, the resource reservation periodicity (P rsvp_TX ) is equal to 0. In some cases, C reselis equal to 0. In some examples, UE-B uses a specified percentage for resource selection for an explicit request, where the percentage is a percentage of the identified candidate resources across all candidate resources from which resources are selected. In some examples, the subchannels in the resource pool used for explicit request transmissions may be restricted by a resource pool configuration. For example, the resource pool configuration may specify that only the first or last X subchannels may be used for explicit request transmissions.

[0055] In some embodiments, the cast type of the explicit request can be unicast or groupcast, so UE-B can send an explicit request to a specific UE-A via unicast, to multiple UE-As via unicast, and / or to a group of UE-As via groupcast.

[0056] In some embodiments, the UE-B may be configured to multiplex the explicit request with the sidelink data transmission. In these embodiments, the UE-B may use the MAC CE as a container for the explicit request. Furthermore, the UE-B may use the lower of the respective priority values ​​associated with the sidelink and the explicit request as the priority value for the multiplexing communication. In some examples, the UE-B is configured with criteria for multiplexing. In one example, the UE-B multiplexes the explicit request with the sidelink data transmission when the data priority of the transport block associated with the explicit request is equal to or greater than the priority of the sidelink transmission. In another example, the UE-B multiplexes the explicit request with the sidelink data transmission when the PDB of the transport block associated with the explicit request is equal to or less than the offset plus the PDB of the sidelink data transmission.

[0057] In some embodiments, in response to receiving the explicit request, UE-A determines preferred and / or non-preferred resources for UE-B. In one example, when UE-A determines a set of preferred resources triggered by an explicit request, UE-A applies a legacy resource selection procedure and selects the remaining packet delay budget C resel The parameters of and the number of time resources for TB are provided or derived from information in an explicit request.

[0058] FIG. 2 illustrates a communication diagram 200 of an assisted UE 204 requesting UE-to-UE coordination information from a supporting UE 202, according to some embodiments. As illustrated in FIG. 2, a supporting UE 202 (labeled UE-A 202) exchanges capability information 206 with a supported UE 204 (labeled UE-B 204). Based on the capability information, as illustrated by block 208, UE-B 204 determines that UE-A 202 is capable of providing UE-to-UE coordination information. Additionally, UE-B 204 determines an ID (e.g., a layer 1 ID and a layer 2 ID) of UE-A 202. In block 210, UE-B 204 checks whether a criterion or condition for sending an explicit request is met upon arrival of data for transmission. Examples of such criteria, such as various trigger conditions, which may include determining the capability information of UE-A 202 as described with respect to block 208, are described in more detail above with respect to FIG. 1. In response to determining that the criteria are met, UE-B 204 provides an explicit request 210 to UE-A 202. In response to receiving the explicit request 210, UE-A 202 provides Inter-UE Coordination (IUC) information 212 to the UE 204. At block 214, UE-B 204, in response to receiving the IUC information 212, performs resource selection based on the IUC information 212.

[0059] In some embodiments, the assisting UE (UE-A) uses information provided in its resource selection explicit request to generate the IUC. Thus, when UE-to-UE cooperation is triggered by an explicit request, the parameters used in UE-A's resource selection procedure are provided in the explicit request. For example, UE-A may provide the number of time domain resources, the remaining packet delay budget, the start time and duration of the window, or the C-domain of UE-B's resource selection. resel Additionally and / or alternatively, UE-A may use at least one of the following parameters in the resource selection of UE-B: TX (Data Priority), L subCH (number of subchannels), P rsvp_TX (resource reservation periodicity) can be used.

[0060] 3A illustrates a flowchart of an example method 300 according to some implementations. For clarity of presentation, the following description generally describes the method 300 in the context of other figures in this description. For example, the method 300 may be performed by the UE 105 of FIG. 1. It will be appreciated that the method 300 may be suitably performed by, for example, any suitable system, environment, software, hardware, or combination of systems, environments, software, and hardware. In some implementations, various steps of the method 300 may be performed in parallel, in combination, in a loop, or in any order.

[0061] At block 302, the method 300 includes detecting one or more triggers for sending an explicit request for UE-to-UE cooperation from a supporting UE.

[0062] At block 304, the method 300 includes generating an explicit request sent to the assisting UE in response to detecting the one or more triggers.

[0063] At block 304, the method 300 includes sending an explicit request to the assisting UE.

[0064] In some implementations, the one or more triggers include determining that the supporting UE is capable of sending inter-UE coordination information.

[0065] In some implementations, determining that the supporting UE is capable of sending UE-to-UE coordination information includes determining that the supporting UE is capable of sending the UE-to-UE coordination information using one of PC5-RRC signaling or higher layer signaling with the supporting UE.

[0066] In some implementations, the one or more triggers further include determining that the transport block for transmission by the UE satisfies at least one of a plurality of secondary conditions, the plurality of secondary conditions including: a latency requirement of the transport block is greater than a predetermined threshold; a detection result at the UE is unsatisfactory; a data priority of the transport block is greater than a predetermined threshold; a channel busy ratio is greater than a predetermined threshold; and the transport block is scheduled to be sent to a supporting UE.

[0067] In some implementations, generating the explicit request to be sent to the supporting UE includes generating a container for the explicit request, the container comprising one of a Medium Access Control (MAC) Control Element (CE), a PC5-Radio Resource Control (PC5-RRC) message, or a Sidelink Control Information (SCI) Phase 2 message.

[0068] In some implementations, the explicit request may include a priority value, a number of requested subchannels, a total number of resource block groups in the IUC, a resource reservation interval, a source ID, a destination ID, a number of requested time resources, an indication of preferred or non-preferred resources, an indication of whether inter-UE coordination information is included in the sidelink control information (SCI) phase 2 signaling, an indication of the start time of the window of requested resources, an indication of the duration of the window of requested resources, or a resource reselection counter (CRC). resel )

[0069] In some implementations, the number of requested subchannels is:

number

number

[0070] In some implementations, the resource reservation interval is:

number

number

[0071] In some implementations, the indication of the start time of the window of the requested resource and the indication of the duration of the window of the requested resource are joint indications.

[0072] In some implementations, sending the explicit request to the assisting UE includes selecting a radio resource for sending the explicit request.

[0073] In some implementations, selecting radio resources for transmitting the explicit request includes one of: selecting from a set of resources allocated for explicit requests or selecting radio resources for the explicit request using resource selection.

[0074] In some implementations, selecting radio resources for an explicit request using resource selection may include determining a priority value for the explicit request, determining that a number of subchannels to be used for the explicit request is equal to 1, determining a number of time resources for the explicit request, determining a latency requirement for the explicit request, determining that a resource reservation periodicity for the explicit request is equal to 0, or determining a resource reselection counter (C) for the explicit request. resel ) is equal to 0.

[0075] In some implementations, the cast type of the explicit request is one of unicast or groupcast.

[0076] In some implementations, sending the explicit request to the supporting UE includes multiplexing the explicit request with the sidelink data transmission.

[0077] In some implementations, multiplexing the explicit request with the sidelink data transmission includes determining to multiplex the explicit request with the sidelink data transmission in response to at least one of: determining that a priority of a transport block associated with the explicit request is greater than or equal to a priority of the sidelink transmission; or determining that a latency of a transport block associated with the explicit request is less than or equal to a latency of the sidelink data transmission plus an offset.

[0078] 3B illustrates a flowchart of an example method 320 according to some implementations. For clarity of presentation, the following description generally describes the method 320 in the context of other figures in this description. For example, the method 320 may be performed by the UE 105 of FIG. 1. It will be appreciated that the method 320 may be suitably performed by, for example, any suitable system, environment, software, hardware, or combination of systems, environments, software, and hardware. In some implementations, various steps of the method 320 may be performed in parallel, in combination, in a loop, or in any order.

[0079] At 322, the method 320 includes receiving an explicit request for inter-UE coordination from an supported UE.

[0080] At 324, the method 320 includes generating information for inter-UE coordination based on the explicit request.

[0081] At 326, the method 320 includes transmitting information for inter-UE coordination to the supported UE.

[0082] In some implementations, the explicit request includes the number of requested time domain resources, the remaining packet delay budget (C resel ), which contains at least one of a start time and duration of a window for the requested time domain resource.

[0083] In some implementations, the information for inter-UE coordination includes information indicating time-frequency resources for supported UEs to transmit transport blocks.

[0084] 4 illustrates a UE 400 according to some embodiments. The UE 400 may be similar to and substantially interchangeable with the UE 105 of FIG.

[0085] The UE 400 may be any mobile or non-IoT device, such as, for example, a mobile phone, a computer, a tablet, an industrial wireless sensor (e.g., microphone, carbon dioxide sensor, air pressure sensor, moisture sensor, thermometer, motion sensor, accelerometer, laser scanner, fluid level sensor, inventory sensor, voltage / current meter, actuator, etc.), a video surveillance / monitoring device (e.g., camera, video camera, etc.), a wearable device (e.g., smart watch), a relaxed mobile computing device, etc.

[0086] The UE 400 may include a processor 402, an RF interface circuit 404, a memory / storage 406, a user interface 408, a sensor 410, a driver circuit 412, a power management integrated circuit (PMIC) 414, an antenna structure 416, and a battery 418. The components of the UE 400 may be implemented as an integrated circuit (IC), a portion thereof, a discrete electronic device, or other module, logic, hardware, software, firmware, or a combination thereof. The block diagram of FIG. 4 is intended to show a high-level view of some of the components of the UE 400. However, some of the components shown may be omitted, additional components may be present, and different arrangements of the components shown may occur in other implementations.

[0087] The components of UE 400 may be coupled with various other components via one or more interconnects 420, which may represent any type of interface, input / output, bus (local, system, or extended), transmission line, trace, optical connection, etc. that allows various circuit components (on a common or different chips or chipsets) to interact with one another.

[0088] The processor 402 may include processor circuitry such as, for example, a baseband processor circuit (BB) 422A, a central processing unit circuit (CPU) 422B, and a graphics processing unit circuit (GPU) 422C. The processor 402 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 406 to cause the UE 400 to perform the operations described herein, including, for example, the operations described in connection with FIGS.

[0089] In some embodiments, the baseband processor circuit 422A may access a communications protocol stack 424 in the memory / storage 406 to communicate over a 3GPP-compliant network. In general, the baseband processor circuit 422A may access the communications protocol stack to perform user plane functions at the PHY, MAC, RLC, PDCP, SDAP, and PDU layers, and control plane functions at the PHY, MAC, RLC, PDCP, RRC, and non-access layers. In some embodiments, PHY layer operations may additionally / alternatively be performed by components of the RF interface circuit 404. The baseband processor circuit 422A may generate or process baseband signals or waveforms that carry information in a 3GPP-compliant network. In some embodiments, waveforms for NR may be based on Cyclic Prefix OFDM "CP-OFDM" in the uplink or downlink, and Discrete Fourier Transform Spread OFDM "DFT-S-OFDM" in the uplink.

[0090] The memory / storage 406 may include one or more non-transitory computer-readable media (e.g., communication protocol stack 424) that include instructions that may be executed by one or more of the processors 402 to cause the UE 400 to perform various operations described herein, including, for example, the operations described in connection with FIGS. 1-3. The memory / storage 406 includes any type of volatile or non-volatile memory that may be distributed throughout the UE 400. In some embodiments, some of the memory / storage 406 may be located on the processor 402 itself (e.g., L1 and L2 caches), while other memory / storage 406 may be external to the processor 402 but accessible via a memory interface. The memory / storage 406 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.

[0091] The RF interface circuitry 404 may include transceiver circuitry and a radio frequency front end module (RFEM) that enable the UE 400 to communicate with other devices over a radio access network. The RF interface circuitry 404 may include various elements disposed in the transmit or receive paths. These elements may include, for example, switches, mixers, amplifiers, filters, combiner circuits, control circuits, etc.

[0092] In the receive path, the RFEM may receive a radiated signal from the air interface via the antenna structure 416 and proceed to filter and amplify the signal (using a low noise amplifier). The signal may be provided to a transceiver receiver that downconverts the RF signal to a baseband signal that is provided to a baseband processor of the processor 402.

[0093] In the transmit path, the transmitter of the transceiver upconverts the baseband signal received from the baseband processor and provides an RF signal to the RFEM, which may amplify the RF signal through a power amplifier before the signal is radiated over the air interface via the antenna 416.

[0094] In various embodiments, the RF interface circuitry 404 may be configured to transmit and receive signals in accordance with an NR access technology. In particular, the RF interface circuitry 404 may be configured to transmit / receive signals related to exchanging capability information, transmitting / receiving / detecting information related to trigger conditions of an IUC, requesting assistance information from or to other UEs, and other operations described above in connection with FIGS. 1-3.

[0095] The antenna 416 may include antenna elements that convert electrical signals into radio waves to travel through the air and convert received radio waves into electrical signals. The antenna elements may be arranged in one or more antenna panels. The antenna 416 may have antenna panels that are omnidirectional, directional, or a combination thereof to enable beamforming and multiple-input multiple-output communications. The antenna 416 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 416 may have one or more panels designed for a particular frequency band, including bands in FR1 or FR2.

[0096] User interface circuitry 408 includes various input / output (I / O) devices designed to enable user interaction with UE 400. User interface 408 includes input device circuitry and output device circuitry. Input device circuitry includes any physical or virtual means for accepting input, including, among others, one or more physical or virtual buttons (e.g., a reset button), a physical keyboard, a keypad, a mouse, a touchpad, a touch screen, a microphone, a scanner, a headset, etc. Output device circuitry includes any physical or virtual means for displaying or otherwise communicating information, such as sensor readings, actuator position(s), or other similar information. The output device circuitry may include any number or combination of audio or visual displays, including, among others, one or more simple visual outputs / indicators (e.g., binary status indicators such as light emitting diodes "LEDs" and multi-character visual outputs), or more complex outputs such as display devices or touch screens (e.g., liquid crystal displays "LCDs", LED displays, quantum dot displays, projectors, etc.), where output such as text, graphics, multimedia objects, etc. are generated or created from operation of the UE 400.

[0097] The sensors 410 may include devices, modules, or subsystems intended to detect events or changes in the environment and transmit information about the detected events (sensor data) to some other device, module, subsystem, etc. Examples of such sensors include, among others, inertial measurement units including accelerometers, gyroscopes, or magnetometers; microelectromechanical systems or nanoelectromechanical systems including 3-axis accelerometers, 3-axis gyroscopes, or magnetometers; level sensors; flow sensors; temperature sensors (e.g., thermistors); pressure sensors; barometric pressure sensors; gravimeters; altimeters; image capture devices (e.g., cameras or lensless apertures); light detection and ranging sensors, proximity sensors (e.g., infrared detectors, etc.), depth sensors, ambient light sensors, ultrasonic transceivers, microphones or other similar audio capture devices, etc.

[0098] The driver circuitry 412 may include software and hardware elements that operate to control particular devices embedded in, attached to, or otherwise communicatively coupled to the UE 400. The driver circuitry 412 may include individual drivers that allow other components to interact with or control various input / output (I / O) devices that may be present in or connected to the UE 400. For example, the driver circuitry 412 may include a display driver that controls and enables access to a display device, a touchscreen driver that controls and enables access to a touchscreen interface, a sensor driver that obtains sensor readings of the sensor circuitry 428 and controls and enables access to the sensor circuitry 428, a driver that obtains actuator positions of electromechanical components or controls and enables access to electromechanical components, a camera driver that controls and enables access to an embedded image capture device, an audio driver that controls and enables access to one or more audio devices.

[0099] The PMIC 414 may manage the power supplied to various components of the UE 400. In particular, with respect to the processor 402, the PMIC 414 may control power source selection, voltage scaling, battery charging, or DC-DC conversion.

[0100] In some embodiments, the PMIC 414 may control or otherwise be a part of various power saving mechanisms of the UE 400, including the DRX discussed herein. The battery 418 may power the UE 400, although in some examples the UE 400 may be mounted and deployed at a fixed location and may have a power source that is coupled to a power grid. The battery 418 may be a lithium ion battery, a metal air battery such as a zinc air battery, an aluminum air battery, a lithium air battery, or the like. In some implementations, such as vehicle-based applications, the battery 418 may be a typical automotive lead acid battery.

[0101] 5 illustrates an access node 500 (e.g., a base station or a gNB) according to some embodiments. The access node 500 may be similar to and substantially interchangeable with the base station 110. The access node 500 may include a processor 502, an RF interface circuit 504, a core network (CN) interface circuit 506, a memory / storage circuit 508, and an antenna structure 510.

[0102] The components of the access node 500 may be coupled to various other components via one or more interconnects 512. The processor 502, RF interface circuitry 504, memory / storage circuitry 508 (including communication protocol stack 514), antenna structure 510, and interconnects 512 may be similar to the similarly named elements shown and described with respect to Figure 4. For example, the processor 502 may include processor circuitry such as a baseband processor circuitry (BB) 516A, a central processing unit circuitry (CPU) 516B, and a graphics processing unit circuitry (GPU) 516C.

[0103] The CN interface circuitry 506 may provide connectivity to a core network, e.g., a fifth generation core network (5GC), using a 5GC compliant network interface protocol, such as a Carrier Ethernet protocol or some other suitable protocol. Network connectivity may be provided to / from the access node 500 via optical fiber or wireless backhaul. The CN interface circuitry 506 may include one or more dedicated processors or FPGAs for communicating using one or more of the aforementioned protocols. In some implementations, the CN interface circuitry 506 may include multiple controllers to provide connectivity to other networks using the same or different protocols.

[0104] As used herein, the terms "access node", "access point", etc. may refer to equipment that provides wireless baseband functionality for data and / or voice connectivity between a network and one or more users. These access nodes may be referred to as BSs, gNBs, RAN nodes, eNBs, NodeBs, RSUs, TRxPs, TRPs, etc., and may include terrestrial stations (e.g., terrestrial access points) or satellite stations that provide coverage within a geographic area (e.g., a cell). As used herein, the terms "NG RAN node" etc. may refer to an access node 500 operating in a NR or 5G system (e.g., gNB), and the term "E-UTRAN node" may refer to an access node 500 operating in a LTE or 4G system (e.g., eNB). According to various embodiments, the access node 500 may be implemented as one or more of a macrocell base station and / or a dedicated physical device such as a femtocell, picocell, or other like cell having a smaller coverage area, smaller user capacity, or higher bandwidth compared to a macrocell.

[0105] In some embodiments, all or a portion of the access node 500 may be implemented as one or more software entities executing on a server computer as part of a virtual network, which may be referred to as a CRAN and / or a virtual baseband unit pool (vBBUP). In these embodiments, the CRAN or vBBUP may implement a RAN functionality split, such as a PDCP split, where the RRC and PDCP layers are operated by the CRAN / vBBUP and other L2 protocol entities are operated by the access node 500, a MAC / PHY split, where the RRC, PDCP, RLC, and MAC layers are operated by the CRAN / vBBUP and the PHY layer is operated by the access node 500, or a "lower PHY" split, where the RRC, PDCP, RLC, MAC layers, and the upper part of the PHY layer are operated by the CRAN / vBBUP and the lower part of the PHY layer is operated by the access node 500.

[0106] In a V2X scenario, the access node 500 may be or operate as an RSU. The term "Road Side Unit" or "RSU" may refer to any transportation infrastructure entity used for V2X communications. An RSU may be implemented in or by a suitable RAN node or a stationary (or relatively stationary) UE, and an RSU implemented in or by a UE may be referred to as a "UE-type RSU", an RSU implemented in or by an eNB may be referred to as an "eNB-type RSU", an RSU implemented in or by a gNB may be referred to as a "gNB-type RSU", etc.

[0107] In the description herein, for convenience, various components may be described as performing a task or tasks. Such descriptions should be construed to include the phrase "configured to." It is expressly intended that the description of a component as being configured to perform one or more tasks does not enforce 35 U.S.C. 112(f) interpretation of the component.

[0108] Although the above embodiments 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, and it is intended that the following claims be interpreted to embrace all such variations and modifications.

[0109] It is understood that use of personally identifiable information should comply with privacy policies and practices generally recognized as meeting or exceeding industry or governmental requirements for maintaining user privacy. In particular, personally identifiable information data should be managed and handled in a manner that minimizes the risk of unintended or unauthorized access or use, and the nature of permitted uses should be clearly indicated to users.

Claims

1. 1. A method performed by a user equipment (UE), the method comprising: Detecting one or more triggers for sending an explicit request for UE-to-UE cooperation from a supporting UE; generating the explicit request sent to the assisting UE in response to detecting the one or more triggers; sending the explicit request to the supporting UE; A method comprising:

2. The one or more triggers include: The method of claim 1 , comprising determining that the supporting UE is capable of sending inter-UE coordination information.

3. Determining that the supporting UE is capable of sending inter-UE coordination information includes: The method of claim 2, comprising: determining, using one of PC5-RRC signaling or higher layer signaling with the supporting UE, that the supporting UE is capable of sending the UE-to-UE coordination information.

4. The one or more triggers include: A transport block for transmission by the UE is a plurality of secondary conditions, the plurality of secondary conditions being: a latency requirement for the transport block is greater than a predetermined threshold; and The detection result at the UE is unsatisfactory; and a data priority of the transport block is greater than a predetermined threshold; and A channel busy ratio is greater than a predetermined threshold; and and the transport block is scheduled to be sent to the supporting UE.

5. Generating the explicit request to be sent to the assisting UE comprises:

2. The method of claim 1, comprising generating a container for the explicit request, the container comprising one of a Medium Access Control (MAC) Control Element (CE), a PC5-Radio Resource Control (PC5-RRC) message, or a Sidelink Control Information (SCI) Phase 2 message.

6. The explicit request may include a priority value, a number of requested sub-channels, a resource block group allocated for inter-UE coordination, a resource reservation interval, a source ID, a destination ID, a number of requested time resources, an indication of preferred or non-preferred resources, an indication of whether inter-UE coordination information is included in Sidelink Control Information (SCI) phase 2 signaling, an indication of a start time of the window of the requested resources, an indication of the duration of the window of the requested resources, a resource reselection counter (CRC) resel 2. The method of claim 1, further comprising at least one of: a number N of (time resource indicator value, frequency resource indicator value, resource reservation periodicity) combinations.

7. The number of requested subchannels is: [0010] It is represented using [0025] 7. The method of claim 6, wherein Λ is the number of subchannels in the resource pool available for sidelink communication.

8. The resource reservation interval is: [0030] It is represented using [0045] 7. The method of claim 6, wherein x is a number of supported resource reservation periods in a resource pool available for sidelink communication.

9. The method of claim 6 , wherein the indication of the start time of the window of the requested resource and the indication of the duration of the window of the requested resource are joint indications.

10. Sending the explicit request to the supporting UE comprises: The method of claim 1 , comprising selecting a radio resource for transmitting the explicit request.

11. Selecting the radio resource for transmitting the explicit request comprises: selecting from a set of resources dedicated to said explicit request; or and selecting the radio resource for the explicit request using resource selection.

12. Selecting the radio resource for the explicit request using resource selection comprises: determining a priority value for said explicit request; determining that a number of subchannels to be used for said explicit request is equal to one; determining a number of time resources for the explicit request; determining a latency requirement for said explicit request; determining that a resource reservation periodicity for the explicit request is equal to 0; or A resource reselection counter for the explicit request (C resel 12. The method of claim 11, comprising at least one of: determining that n is equal to 0;

13. The method of claim 1 , wherein a cast type of the explicit request is one of unicast or groupcast.

14. Sending the explicit request to the supporting UE comprises:

2. The method of claim 1, comprising multiplexing the explicit request with a sidelink data transmission.

15. multiplexing the explicit request with sidelink data transmission, multiplexing the explicit request with the sidelink data transmission. determining that a priority of a transport block associated to the explicit request is equal to or greater than a priority of the sidelink transmission; or determining that a latency of the transport block associated to the explicit request is less than or equal to a latency of the sidelink data transmission plus an offset.

16. 1. A processor for a user equipment (UE) in a cellular communication network, the processor comprising: A processing circuit that executes one or more instructions that, when executed, cause the processor to: Detecting one or more triggers for sending an explicit request for UE-to-UE cooperation from a supporting UE; generating the explicit request to be sent to the assisting UE in response to detecting the one or more triggers; and A communications circuit that executes one or more instructions that, when executed, cause the UE to: a communications circuit configured to perform operations including transmitting the explicit request to the assisting UE; A processor comprising:

17. The one or more triggers include: The processor of claim 16 , further comprising determining that the supporting UE is capable of sending inter-UE coordination information.

18. 1. A method performed by a supporting user equipment (UE), the method comprising: receiving an explicit request for inter-UE coordination from a supported UE; generating information for inter-UE coordination based on the explicit request; transmitting the information for inter-UE coordination to the supported UE; A method comprising:

19. The explicit request includes the number of requested time domain resources, the remaining packet delay budget (C resel 20. The method of claim 18, wherein the requested time domain resource includes at least one of a start time and a duration of a window for the requested time domain resource.

20. The method of claim 18, wherein the information for inter-UE coordination includes information indicating time-frequency resources for the supported UE to transmit transport blocks.

Images