Patent Description:
In NR V2X, a Mode <NUM> resource selection procedure provides a set of candidate resources for higher layer that can be selected for transmission. However, since this mode operates in a distributed manner, it is essential to adjust the resource selection procedure in order to improve its reliability and reduce its latency. In particular, in case of periodic transmissions, there might be scenarios in which user equipments (UEs) end up consistently colliding with neighboring ones, thereby impeding the system performance. In addition, due to the distributed nature, the hidden node problem exists in V2X systems which significantly impacts the performance.

<NPL> discusses resource allocation for mode <NUM>.

<CIT> discloses: Methods and apparatuses for handling collision between sidelink feedback and sidelink data in a wireless communication system. In one method, a User Equipment, UE, is (pre-)configured to perform one or more sidelink transmissions on multiple carriers, wherein the UE is able to transmit a first number of carriers among the multiple carriers at the same time. The UE selects a first resource for transmitting a first sidelink transmission in a first slot on a first carrier. The UE derives a second resource for transmitting a PSFCH delivering a feedback in a second slot on a second carrier, wherein the second slot is at least partly overlapping with the first slot in a time domain. The UE determines whether to prioritize either the PSFCH or the first sidelink transmission based on a rule when the number of carriers which the UE identifies to transmit in the overlapped slot exceeds the first number of carriers.

Specific embodiments are defined in the dependent claims.

The embodiments related to <FIG> and <FIG> are comprised within the scope of the claims.

The electronic device according to one embodiment may be one of various types of electronic devices. The electronic devices may include, for example, a portable communication device (e.g., a smart phone), a computer, a portable multimedia device, a portable medical device, a camera, a wearable device, or a home appliance. According to one embodiment of the disclosure, an electronic device is not limited to those described above.

The terms used in the present disclosure are not intended to limit the present disclosure but are intended to include various changes, equivalents, or replacements for a corresponding embodiment. With regard to the descriptions of the accompanying drawings, similar reference numerals may be used to refer to similar or related elements. A singular form of a noun corresponding to an item may include one or more of the things, unless the relevant context clearly indicates otherwise. As used herein, terms such as "<NUM>st," "2nd," "first," and "second" may be used to distinguish a corresponding component from another component, but are not intended to limit the components in other aspects (e.g., importance or order). It is intended that if an element (e.g., a first element) is referred to, with or without the term "operatively" or "communicatively", as "coupled with," "coupled to," "connected with," or "connected to" another element (e.g., a second element), it indicates that the element may be coupled with the other element directly (e.g., wired), wirelessly, or via a third element.

As used herein, the term "module" may include a unit implemented in hardware, software, or firmware, and may interchangeably be used with other terms, for example, "logic," "logic block," "part," and "circuitry. " A module may be a single integral component, or a minimum unit or part thereof, adapted to perform one or more functions. For example, according to one embodiment, a module may be implemented in a form of an application-specific integrated circuit (ASIC).

In NR V2X, a UE can operate in Mode <NUM> and accordingly select the resources for transmission independently from the base station (gNB). In this mode, the UEs define a sensing window and a resource selection window. In the sensing window, all UEs that are not transmitting are required to monitor all subchannels to detect sidelink control information (SCI) transmitted by their neighbors. Once an SCI is detected, its reference signal receive power (RSRP) is measured and a set of resources can be considered as occupied in future slots within the resource selection window. This is because an SCI can indicate up to two future resources (i.e., subchannels and slots) as well as a periodicity in case of periodic transmissions. Subsequently, the sensing UE can identify a set of resources that are occupied in its resource selection window in order to avoid them. Despite the advantages of this procedure in reducing collisions (i.e., interference), its ability to avoid collisions is limited by a UE's sensing range. In particular, a UE will not be able to detect potentially interfering UEs outside its sensing range thus leading to collision. This can happen due to the hidden node problem.

<FIG> illustrates a diagram of the hidden node problem, according to an embodiment. For example, in <FIG>, if UE A attempts to communicate with UE B, it might interfere with the transmission of UE C despite being outside of its sensing range <NUM>. This issue is also magnified in the case of periodic transmissions if nodes A and C select the same initial resource and period, thus leading to consistent transport block (TB) losses. In addition to the hidden node problem, the communication between the two nodes (UE A and UE B) in <FIG> can be also lost due to the half-duplex limitation. In particular, if UE A selects a resource that is also selected by UE B for transmission, then the TB sent from UE A to UE B will also be lost since UE B will not be able to receive it. This scenario can also cause significant degradation of performance in the case of periodic transmissions because UEs A and B can consistently lose the transmitted TBs if they both select the same transmission period and initial resource.

To address the drawbacks of Mode <NUM>, several approaches are disclosed herein to improve the system's reliability and latency while supporting both periodic and aperiodic traffic types. In particular, some approaches disclosed herein may include sending an SCI with explicit/implicit indication to request resource selection assistance, imposing a restriction on the resource assistance requests based on different parameters such as priority, channel busy ratio (CBR) and channel occupancy ratio (CR), restricting the assistance request to retransmissions rather than initial transmission in the case of aperiodic traffic or allowing the receiver (Rx) UE to discard assistance reporting in the case of successful transmission, allowing the Rx UE to relay the resource reservation request in order to avoid the hidden node problem, allowing piggybacking of resource selection assistance information in SCI with a flag, allowing the UE to perform additional SCI transmission in the second half of the slot to help with low latency applications, reducing CReselection to avoid consistent collisions based on hybrid automatic repeat request (HARQ) feedback or Rx UE assistance, allowing the transmission (Tx) UE to request a list of active periodic transmissions from the Rx UE to avoid consistent collisions due to half duplex constraint, and/or utilizing the location information to overcome the exposed terminal problem.

To improve the performance of the resource selection procedure in NR V2X, according to one embodiment, one approach is to enable the Tx UE to request assistance from the RX UE(s). In this case, the Tx UE may send an SCI with a flag indicating resource selection assistance request. This flag may be either explicit by setting one or more bits in the SCI or implicit by setting one or more fields in the SCI to a reserved value (e.g., setting the periodicity field to a value beyond the pre-configured periodicities for the resource pool might be used to indicate a resource assistance request). This resource assistance request may also be dedicated to a specific UE by sending the destination identification (ID) or it may be sent in a broadcast mode (e.g., by using a reserved ID) in order to enable UE resource selection assistance in groupcast and broadcast. The Tx UE may also specify the resources over which it expects the UE assistance report. These resources may be either included in the payload or as future reservations in the SCI. This helps in reducing the power consumption by limiting the number of resources the UE has to monitor in the case of power limited UEs and also ensures the resource assistance information can be received in a timely manner. There may be collisions between the UEs providing the assistance information in case the request was done in broadcast/groupcast mode. To address this problem, UEs may generate a random backoff based on their IDs before providing the assistance information. During that backoff time, each UE monitors the available subchannels (either all or the ones specified by the Tx UE). If an SCI is detected with a destination ID equal to the UE that requested the assistance information, the payload is decoded to check the presence of assistance information. In this case, if assistance information is found, the UE discards the assistance information reporting request.

A power-limited UE that does not perform sensing may also benefit from UE assistance irrespective of the hidden node problem. In particular, a power-limited UE may request assistance from neighboring UEs in order to avoid future collisions since it is not aware of the resources already reserved by its neighboring UEs. In this case, once the UE wakes up with data to transmit, it attempts to perform an initial transmission on one or a limited number of subchannels. However, if the data to transmit does not fit within the subchannel in a given slot, it may raise a flag to indicate an assistance request for future resource selections. In particular, the UE assistance may be performed as follows.

First, the power-limited UE may send an SCI over one subchannel with a flag set to a value (e.g., <NUM>) to request assistance. The payload may carry some information about the traffic type (e.g., periodic/aperiodic, priority, size, packet delay budget (PDB), etc.) to facilitate the resource selection by the assisting UE (e.g., number of subchannels). Then, the SCI may indicate the ID of the UE from which assistance is requested if known (this can be helpful if a UE already selected a neighboring UE to assist with resource selection in relatively static cases). One example of such relatively static cases is an intersection. For example, there may be a fixed node (e.g., road side unit (RSU)) at each intersection that performs sensing of the occupied resources (this fixed node may also be alternating relatively slowly between the vehicle UEs approaching/exiting the intersection). Once a power-limited UE approaches this intersection, it may send an assistance request to this node for resource assistance selection information occasionally. For example, a power-limited UE may require sending a message only when it attempts to cross the intersection to alert neighboring cars and thus may request assistance for resource selection only at this instance. The SCI may not perform any future reservations since little to no information is known about the reserved resources by neighboring UEs. The power-limited UE requesting assistance may continue to monitor the resource pool for assistance information. If a specific UE is designated for assistance, it may respond back by sending information regarding the suggested resources to use for transmission. This information may be either carried in the SCI through a future resource reservation or carried in the payload. Once the UE requesting assistance receives the information, it may proceed with transmission over the indicated resources, or it may consider the assistance information and determine, based on the assistance information, over which resources to proceed with the transmission. While the indicated resources may be utilized for the transmission, the UE may consider the indicated resources for transmission, but then utilize different resources for transmission. If no response is received (e.g., non-decodable SCI, no neighboring UEs available to assist), a timer may be set and when this timer expires, it may either force the UE to either request UE assistance or perform the transmission. This decision may also be based on the PDB of the pending data. The resources used for the data transmission or the assistance request may be either randomly selected or the resource selection procedure can take the sensing information while the UE was waiting for assistance into consideration.

Thus, according to one embodiment, Tx UEs may send SCI to request assistance information for resource selection either to a dedicated UE or to all neighboring UEs. This request may be either explicit in a field in the SCI or implicit by using reserved values for one or more SCI fields. To reduce collisions, this request may be restricted to be transmitted on a limited number of subchannels (e.g., one subchannel) in the case of power-limited UEs.

<FIG> illustrates a diagram of a sidelink slot <NUM> with a PSFCH, according to an embodiment. The PSFCH channel may be used to transmit the feedback information from the Rx to the Tx UEs. It may be used for Unicast and groupcast options <NUM> and <NUM>. In the case of unicast and groupcast option <NUM>, the PSFCH is used to transmit ACK/NACK whereas for the case of groupcast option <NUM>, the PSFCH carries only NACK. For sidelink feedback, a sequence-based PSFCH format (PSFCH format <NUM>) with one symbol (not including automatic gain control (AGC) training period) is supported.

In PSFCH format <NUM>, the ACK/NACK bit is transmitted through two Zadoff-Chu (ZC) sequences of length <NUM> (same root but different cyclic shift), whereby the presence of one sequence indicates an ACK and the presence of the other indicates a NACK (i.e., these sequences are used in a mutually exclusive manner). Since sequences are used to convey the ACK/NACK to the transmitter, feedback from multiple UEs may be multiplexed on the same physical resource block (PRB). In particular, in the current design, up to <NUM> ACK/NACKs from <NUM> UEs can be multiplexed on the same PRB (<NUM> subcarriers) by using different cyclic shifts. In this case, each UE is assigned the same root sequence but with two cyclic shifts (one for ACK and another for NACK). The main purpose of using this code division multiplexing (CDM)-based format is due to the case of groupcast option <NUM> in which multiple ACK/NACK feedbacks are expected from different UEs per physical sidelink shared channel (PSSCH) transmission. For groupcast option <NUM>, ACK/NACKs from different UEs may be transmitted on the same PRB by allocating two different sequences for each UE to use for its ACK/NACK transmissions and, in this case, the sequences and the PRB used by each UE will depend on a unique ID. On the other hand, for groupcast option <NUM>, only a NACK is required and thus the cyclic shift corresponding to the ACK message is not used and all the UEs included in the groupcast will use the same sequence and PRB for NACK. To support AGC, the resource elements used for the PSFCH may be duplicated in the immediately preceding OFDM symbol (this implies that two consecutive symbols are always used for transmission of PSFCH format <NUM>). Subsequently, the first symbol may be used for AGC training after the Tx/Rx switch. In addition, at least one symbol is used for the gap right after PSSCH transmission and another is used after the PSFCH transmission to allow for Tx/Rx switching as shown in <FIG>.

For the period of N slot(s) of the PSFCH resource, three values are supported (i.e., N=<NUM>, N=<NUM>, and N=<NUM>). These values define the periodicity of the PSFCH resource and subsequently it's associated overhead. For a PSSCH transmission with its last symbol in slot n, when the corresponding HARQ feedback is due for transmission, it is expected to be in slot n+a, where a is the smallest integer larger than or equal to K logical slots (i.e., slots within the PSSCH resource pool) with the condition that slot n+a contains PSFCH resources and K is equal to <NUM> or <NUM>.

According to one embodiment, power-limited UEs may request assistance for resource selection by sending either a dedicated PSFCH sequence or a selected PSFCH sequence from a pool. The UE receiving the sequence may respond by providing the assistance information to a specific UE using its ID if a dedicated sequence is used or using an ID corresponding to the PSFCH sequence that is randomly selected from a pool.

Power-limited UEs may request assistance from neighboring UEs in order to avoid future collisions. These assistance requests may be sent in the form of dedicated sequence(s) on a PSFCH resource(s). Subsequently, a UE receiving the dedicated PSFCH sequence may provide assistance information regarding the resources available for transmission. The available PSFCH sequences for the assistance request(s) may be either provided in the form of a pool of sequences or may be dedicated to the limited-power UEs beforehand. In particular, a limited-power UE may be dedicated a specific sequence on a pre-selected PRB/subchannel. Alternatively, a set of available sequences may be used by any limited-power UE requesting assistance. In the former case, the available resources may be indicated directly to the requesting UE since its ID is known (i.e., the assisting UE will know the requesting UE through its dedicated sequence and PRB/subchannel). In the latter case, an approach similar to random access may be considered in which the assistance information is provided with an ID based on the selected PSFCH resource for the assistance request. This is because multiple UEs may request assistance simultaneously and thus the assistance information may be sent to each one separately to avoid collisions.

According to one embodiment, to improve the system performance, the system may limit the resource assistance requests based on CBR, CR, priority, periodicity, TB size, and/or packet delay budget, to reduce the resource assistance overhead. In some cases, the system may be highly occupied or the TB to be transmitted may be small or has low priority and thus UE resource selection assistance may not be favorable. To address this concern, the system may limit the resource assistance request based on CBR. If the CBR is too high, the system will be overloaded and collisions will occur on the resource assistance request, thereby hindering its reliability. In addition, there might not be enough resources to carry the resource assistance report. The system may limit the resource assistance request based on CR. Since the assistance request must be sent, it may increase the UE's CR towards its CR limit. In this case, the UE may not be able to meet the packet delay budget when the assistance information arrives as it will not be able to transmit due to reaching its CR limit. The system may limit the resource assistance request based on a priority level. Depending on the priority level, the UE may elect to request for resource selection assistance or not. In particular, it may be favorable to request assistance for higher priority traffic only in order to reduce the overhead and increase the chances of reliable transmissions. The system may limit the resource assistance request based on periodicity. Since periodic transmissions may result in consistent collisions between UEs, it may be given higher priority for resource assistance requests. For example, resource assistance requests may be limited only to periodic traffic. The system may limit the resource assistance request based on TB size. If the TB size is small, it may not be beneficial to request resource assistance information especially in highly occupied scenarios. The system may limit the resource assistance request based on PDB. Given the PDB, it may not be possible to request resource selection assistance. In particular, a resource assistance request involves at least two transmissions (i.e., resource assistance request and reporting). In this case, this may be beyond the PDB, especially in highly occupied systems and thus it may not be beneficial to get assistance in such cases.

According to one embodiment, to reduce the resource assistance overhead, a UE may be allowed to request assistance only if initial transmission fails (i.e., only for TB retransmissions). Alternatively, Rx UE may discard the assistance request in case the initial transmission of aperiodic traffic is successful. To limit the resource assistance overhead, the system may restrict the assistance to TB retransmissions. For example, this restriction may be imposed only for aperiodic traffic in cases of groupcast and unicast. This is because for aperiodic traffic, the first TB transmission may be successful, thereby eliminating the need for assistance and its associated overhead. Alternatively, the Rx UE may be allowed to discard the assistance request for aperiodic retransmissions in case it was successful.

According to one embodiment, to avoid the hidden node problem, a UE may elect to relay the resource reservations of one or more of its neighbors. This relaying may be based on traffic priority and/or RSRP thresholds.

In some examples, the hidden node problem described above may limit the system performance. In particular, the limited sensing range of Tx UEs may result in TB collisions with neighboring UEs outside their sensing ranges. However, in case of the hidden node problem, the Rx UE will be aware of the potential collision as it may detect the resource selections of both UEs. Hence, the system may allow the Rx UE to relay the resource reservation of the Tx UE. In this case, the second tier neighbors may be aware of the potential collisions and accordingly adjust their resource selections. This relaying may be either requested by the Tx UE or done independently by the Rx UE either proactively or when it detects the presence of hidden node(s) with conflicting resource reservations. To request the relaying, this may be done either explicitly by setting a flag in the SCI or implicitly by setting one or more parameters to specific values. In addition, when the relaying SCI is being transmitted, it may include a flag that this is a resource reservation relaying either explicitly with a flag in the SCI or implicitly by setting one or more parameters to specific values (e.g., using the same Tx UE ID). The Rx UE may relay the resource reservation of the higher priority traffic as indicated by the SCI, the Rx UE may relay the resource reservation of the UE with higher RSRP thus requiring the Tx UE with worse channel conditions to change its resource selection, or the Rx UE may relay the resource reservation of the UE with lower RSRP in order to reduce its incurred interference and increase its reliability.

Several approaches may be utilized for a UE to perform this relaying. For example, one approach may be as simple as retransmitting the same SCI information at a later slot (with adjustments to the slot information). Alternatively, it may be sent as higher layer information in the payload. The Rx UE may attempt to relay the exact information received in the SCI with adjustments to the new slot timing. In particular, the Rx UE may maintain the same source ID, destination ID, priority, etc. However, the Rx UE may need to adjust the future resources indicated by the SCI since the relayed information are sent in a different slot compared to the original SCI. For example, if the original SCI was performing resource reservations for two slots in the future that are <NUM> and <NUM> slots ahead and the relaying occurs in the following slot after the initial transmission, then the future reservations will indicate resource reservations that are <NUM> and <NUM> slots ahead. Although this works well for aperiodic traffic, periodic traffic may face a discrepancy as the periodically indicated resources may be different from the original one. Thus, if the resources reserved in the past may be indicated in the SCI similar to the LTE V2X, then the periodic reservations in the relayed SCI may be adjusted to match that of the original transmissions. Alternatively, the UE may relay the SCI without the periodic reservation (i.e., relaying is done in each period separately). In such a case, no confusion occurs for the Tx UE when it receives the relayed resource reservation request because it will be able to detect the same Tx UE ID.

The relaying may be performed by the higher layers by including the resource reservation requests in the payload along with their associated information. In such a case, information about the future reserved resources as well as the resource reservation period may be included in the payload. The relaying may be performed by both SCI indication and higher layers. In particular, the SCI may either include an implicit or explicit flag that this is a resource reservation relaying. However, the information regarding the reserved resources may be included by the higher layers in the payload and carried by the PSSCH.

The system may consider how the relaying UE is selected. The system may allow the Tx UE to select the relaying UE(s) based on specific information (e.g., relative location). In this case, the relaying request flag along with the destination ID(s) will be used to identify the UEs that are expected to relay the information. Alternatively, it may be left to the Rx UE to perform the relaying when necessary (e.g., when a collision due a hidden node is detected).

In one embodiment, the system may consider the location information as an input factor when requesting resource selection assistance and/or relaying of resource selection information. To further reduce the chances of collisions due to the hidden node problem, a UE may request resource selection assistance based on the Rx UE location or the targeted UEs' locations. For example, assuming that a UE is targeting to send a TB(s) in a specific direction (e.g., a vUE attempting to send information along a highway), it may select one or more UEs for resource selection assistance based on their location along the highway. Alternatively, if the Tx UE attempts to communicate with an RX UE in location X but is not able to get assistance information from the Rx UE (e.g., due to limited delay budget or limited power budget), the Tx UE may select any neighboring UE within the same location for assistance. In addition, the Tx UE may also request the relaying for the resource selection information based on the targeted UE(s) location. For example, if a Tx UE attempts to communicate with other UEs along a highway, it may require resource selection relaying to avoid the hidden node problem. In this case, the UE may also include the desired direction/location either in the SCI or in the payload and accordingly the Rx UE(s) decide whether to relay the resource reservation or not.

In one embodiment, if UEs are capable of beam selection, a UE may direct its beam such that the resource assistance request is sent only in the direction of the target UE(s) location. In some examples, vehicle UEs may be able to perform beam selection to reduce the interference and improve the data rates. However, in such scenarios, the hidden node problem may be more pronounced as the vehicle UEs may not be able to sense SCIs in all directions. In addition, UEs may also be interested in assistance information only in the desired directions for transmitting their TBs. To address this concern, the UE may direct its Tx beam such that the resource selection assistance request is sent only in the direction of the target UE(s) location.

According to one embodiment, to reduce the resource assistance overhead, the system may allow the Rx UE to piggyback the resource selection assistance information in SCI. In particular, a flag may be included in the SCI to indicate that the future resources indicated by the SCI are not reserved. Subsequently, these resources may be considered as recommended resources for future transmissions by the Tx UE. This reserves the resources by eliminating the need for transmitting the UE resource assistance information in the PSSCH thereby not affecting the payload.

According to one embodiment, the system may allow the Rx UE to transmit partial/full resource selection assistance information within the same slot to accommodate high priority UEs with limited PDB. The indication for low PDB may be included either implicitly or explicitly in the SCI sent by the Rx UE. To meet the stringent latency requirement of high priority traffic, the system may reduce the time required for resource assistance requests. In particular, an explicit/implicit flag may be included in the SCI to indicate low packet delay budget and to request for immediate assistance information. To meet this objective, one possible approach is to allow the Rx UE to transmit either partial or full resource assistance information in the same slot in which the assistance request was transmitted. A selected destination UE(s) may be requested to provide resource selection feedback.

<FIG> illustrates a diagram of a sidelink slot, according to an embodiment. The requesting UE may send an SCI including destination UE ID and a special flag requesting immediate resource selection assistance. Either no PSSCH data is included or it may be included but processed at later slots. The Rx UE may respond after decoding the SCI by generating an SCI with recommended resources. The generated SCI may be carried in the same slot <NUM> on the last OFDM symbols <NUM> and <NUM>. The symbols <NUM> and <NUM> may be unutilized PSFCH symbols.

It may not be required for the Rx UE to send the SCI with the assistance information within the same slot. In other words, it may depend on the Rx UE implementation. However, to enable assistance for UEs with stringent latency requirement, the sensing window for the resource assistance information may be started within the same slot. In this case, if the Rx UE was a high capability UE, then the Tx UE will get the assistance information immediately within the slot. In addition, the Tx UE may also request assistance from a specific UE that is known to have higher capability but not necessarily the Rx UE. In particular, in case of platooning, the Tx UE may request assistance from the platoon head in order to obtain the resources thus it may select a UE with the highest capability to reduce the latency.

In one embodiment, to overcome the issue of consistent collisions, the system may allow UEs to reduce their randomly selected number for resource reselection (Cresel). This reduction may be based on HARQ feedback when it is enabled or on the assistance information when HARQ feedback is disabled. A drawback of the mode <NUM> resource selection procedure of Rel-<NUM> NR V2X is the possibility of consistent collisions. In particular, in case of periodic transmissions, a UE is expected to maintain its periodic selected resources until the end of Cresel. However, there may be cases in which two UEs select the same periodic resources and thus consistently collide for long durations. To address this drawback along with the hidden node problem, the system implements two approaches depending on whether feedback is enabled or disabled. If feedback is enabled, a UE may elect to reduce its Cresel when it does not receive HARQ feedback for 'X' number of times over one or multiple periods (e.g., due to the half-duplex) or when it receives NACK for 'Y' number of times over one or multiple periods (e.g., due to the hidden node problem). In NR Rel-<NUM>, a UE is able to detect three cases when HARQ feedback is enabled (i.e., ACK, NACK and discontinuous transmission (DTX) due to absence of NACK). If feedback is disabled, a UE may elect to reduce its Cresel based on the assistance information received from the Rx UE.

In one embodiment, to overcome the half duplex issue, the Tx UE may request the Rx UE to provide a list of active periodic transmissions. By matching this list with the previously decoded SCIs, the Tx UE may identify the overlapping periodic transmissions and adjust accordingly to avoid consistent packet losses. To avoid consistent packet loses due to the half-duplex constraint, the system may rely on aligning periodic transmissions. In particular, the Tx UE may request the Rx UE to provide a list of active periodic transmissions. This request may be included either implicitly or explicitly in SCI. Alternatively, it may be included as a higher layer parameter to reduce the SCI overhead. Subsequently, the Rx UE responds by providing a list of the periods of its current transmissions. This may be carried as a higher layer parameter as the number of periods configured per resource pool may be large and thus beyond the capacity of SCI. Once this is received, the Tx UE will be aware of the periods reserved by the Rx UE and may identify possible consistent packet loses due to the half-duplex issue. This may be done by matching the periodic reservations identified through previously decoded SCIs with the ones received in the assistance report to identify potentially overlapping periodic transmissions.

<FIG> illustrates a diagram of the exposed node problem, according to an embodiment. Due to the distributed nature of the mode <NUM> resource selection, the system is vulnerable to the exposed node problem. In particular, two nodes may not be able to utilize the same resource for transmission despite being far apart, thereby hindering the resource utilization efficiency. For example, UE B may be within the same sensing range <NUM> of UE C, and thus UE C can detect its resource reservation. However, if UE C is attempting to communicate with UE D and UE B is attempting to communicate with UE A then both transmissions should not be interfering because UE D is out of the transmission range of UE B and UE A is out of the transmission range of UE C. However, given that UE C sensed the reservation of UE B, UE C will not be able to utilize the same set of resources, thereby resulting in the exposed node problem.

According to one embodiment, to overcome the exposed terminal problem, the system may require all UEs to include their location information in SCIs when transmitting (i.e., include the location information in unicast/groupcast option <NUM>/broadcast transmissions). The UEs may use the location information indicated in the SCI in order to alleviate the impact of the exposed node problem on the resource utilization efficiency of the system. In particular, in NR Rel-<NUM>, a UE transmits location information in SCI in case of groupcast option <NUM>. This information is necessary so that neighboring UEs may decide whether to provide HARQ feedback or not. This may be extended in further releases by requiring all UEs to provide their location information. Once the location information of the neighboring UEs is available at a UE, it may use it as an input to the resource selection procedure of Mode <NUM> thus deciding whether a resource may be used or not (i.e., to resolve the exposed node problem). In particular, in <FIG>, for example, if UE B is aware of the locations of UE A and UE C and knows that their inter-UE distance is larger than a predetermined threshold, then it may use the same resource reserved by UE C to communicate with UE A.

According to one embodiment, the system may update the Mode <NUM> resource selection procedure to pass the resources received in the assistance report and/or the resources selected based on sensing, the system may update the Mode <NUM> resource selection procedure to exclude/penalize the resources indicated as occupied by the assistance reports, and the system may add a timer that impacts the validity of the resource assistance reports.

Once the assistance information becomes available, a Mode <NUM> resource selection procedure is required to take them into consideration according to the work item description (WID). To achieve this, the system may pass two sets of resources to the higher layer to select from (one based on sensing and the other based on the obtained assistance reports). The system may pass only the resources indicated by the resource assistance report (e.g., if the number of resources within the set is above a certain threshold to reduce the probability of collision). If some resources are indicated as reserved (e.g., due to the hidden node problem), the system may exclude them from the total set of resources before running the procedure. Alternatively, these resources may remain but may be penalized with a high hypothetical RSRP level. This level may be a pre-configured value that may be dependent on priority or the location of the Rx UE (e.g., increase the RSRP to a higher level if the Rx UE is far away). If some resources are indicated as reserved (e.g., due to the hidden node problem) but their priority is not known, a UE may set a pre-configured priority when handling these resources according to the Mode <NUM> resource selection procedure (e.g., when selecting the RSRP threshold). The system may add a timer on the validity of the resource assistance report (i.e., may reduce the probability of selecting/excluding the resources indicated in the report). The timer may be a function of the UE speed.

According to one embodiment, the Rx UE may proactively provide assistance information to the Tx UE after a number of failed re-transmissions and/or the detection of a conflicting hidden node. This may also be triggered by the priority of the Tx UE transmission. The assistance information may be indicated explicitly by raising a flag in the SCI or implicitly by setting one or more parameters in the SCI to specific values.

To further improve the system performance, an Rx UE may proactively provide assistance information to the Tx UE. This may occur if the Rx UE detects a set of a number of failed (re)-transmissions or when the measured RSRP is below a certain threshold. This resource selection assistance may also be triggered by the presence of a hidden node that is overlapping with the resources reserved by the Tx UE. Alternatively, it may also be triggered by the priority of the information to be sent by the Tx UE. In this case the Rx UE may provide the assistance information either in the SCI or in the payload to the Tx UE. The indication of the presence of assistance information may be either implicit or explicit. The indication may be explicit by raising a flag in the SCI and including the Tx UE ID as the destination ID. The indication may be implicit by setting one or more parameters of the SCI to specific values (e.g., setting the source ID to the Tx UE ID and the destination ID to the Rx UE ID).

According to one embodiment, the Rx UE may periodically provide assistance information to the neighboring UEs. The assistance information may be triggered by the CBR or the priority of neighboring UEs. The periodic assistance information may be indicated explicitly by raising a flag in the SCI or implicitly by setting one or more parameters in the SCI to specific values. They may also be piggybacked on the same resources used for periodic transmissions by the Rx UE.

In particular, to reduce the delay involved in requesting assistance information, an Rx UE may periodically provide assistance information to be used by its neighboring UEs. This assistance report may be periodically updated based on the resource reservations of its neighboring UEs. These periodic resource assistance reports may be also triggered by the priority of neighboring UEs and/or the CBR. These assistance reports may be also piggybacked in the same slots in which the Rx UE is performing periodic transmissions. The indication of the presence of assistance information may be either implicit or explicit. The indication may be implicit by setting one or more parameters of the SCI to specific values (e.g., setting the source ID and the destination ID to the Rx UE ID). The indication may be explicit by raising a flag in the SCI.

<FIG> illustrates a flowchart <NUM> for a method of providing assistance information, according to an embodiment. Any of the components or any combination of the components described (i.e., in the device diagrams) can be used to perform one or more of the operations of the flowchart <NUM>. The operations depicted in the flowchart <NUM> are example operations and may involve various additional steps not explicitly provided in the flowchart <NUM>. The order of the operations depicted in flowchart <NUM> is exemplary and not exclusive, as the order may vary depending on the implementation.

At <NUM>, a UE transmits an assistance request to at least one neighboring UE. At <NUM>, the UE receives assistance information including an indication of at least one resource for transmission from the at least one neighboring UE. At <NUM>, the UE transmits over the indicated at least one resource. Alternatively, the UE may assign a higher priority to the indicated at least one resource.

<FIG> illustrates a block diagram of an electronic device <NUM> in a network environment <NUM>, according to one embodiment. The electronic device <NUM> may communicate with the electronic device <NUM> via the server <NUM>. The electronic device <NUM> may include a processor <NUM>, a memory <NUM>, an input device <NUM>, a sound output device <NUM>, a display device <NUM>, an audio module <NUM>, a sensor module <NUM>, an interface <NUM>, a haptic module <NUM>, a camera module <NUM>, a power management module <NUM>, a battery <NUM>, a communication module <NUM>, a subscriber identification module (SIM) <NUM>, or an antenna module <NUM>. In one embodiment, at least one (e.g., the display device <NUM> or the camera module <NUM>) of the components may be omitted from the electronic device <NUM>, or one or more other components may be added to the electronic device <NUM>. In one embodiment, some of the components may be implemented as a single integrated circuit (IC). For example, the sensor module <NUM> (e.g., a fingerprint sensor, an iris sensor, or an illuminance sensor) may be embedded in the display device <NUM> (e.g., a display).

The processor <NUM> may execute, for example, software (e.g., a program <NUM>) to control at least one other component (e.g., a hardware or a software component) of the electronic device <NUM> coupled with the processor <NUM>, and may perform various data processing or computations. As at least part of the data processing or computations, the processor <NUM> may load a command or data received from another component (e.g., the sensor module <NUM> or the communication module <NUM>) in volatile memory <NUM>, process the command or the data stored in the volatile memory <NUM>, and store resulting data in non-volatile memory <NUM>. Additionally or alternatively, the auxiliary processor <NUM> may be adapted to consume less power than the main processor <NUM>, or execute a particular function. The auxiliary processor <NUM> may be implemented as being separate from, or a part of, the main processor <NUM>.

The auxiliary processor <NUM> may control at least some of the functions or states related to at least one component (e.g., the display device <NUM>, the sensor module <NUM>, or the communication module <NUM>) among the components of the electronic device <NUM>, instead of the main processor <NUM> while the main processor <NUM> is in an inactive (e.g., sleep) state, or together with the main processor <NUM> while the main processor <NUM> is in an active state (e.g., executing an application). According to one embodiment, the auxiliary processor <NUM> (e.g., an image signal processor or a communication processor) may be implemented as part of another component (e.g., the camera module <NUM> or the communication module <NUM>) functionally related to the auxiliary processor <NUM>.

The communication module <NUM> may include one or more communication processors that are operable independently from the processor <NUM> (e.g., the AP) and supports a direct (e.g., wired) communication or a wireless communication. According to one embodiment, the communication module <NUM> may include a wireless communication module <NUM> (e.g., a cellular communication module, a short-range wireless communication module, or a global navigation satellite system (GNSS) communication module) or a wired communication module <NUM> (e.g., a local area network (LAN) communication module or a power line communication (PLC) module). A corresponding one of these communication modules may communicate with the external electronic device via the first network <NUM> (e.g., a short-range communication network, such as Bluetooth™, wireless-fidelity (Wi-Fi) direct, or a standard of the Infrared Data Association (IrDA)) or the second network <NUM> (e.g., a long-range communication network, such as a cellular network, the Internet, or a computer network (e.g., LAN or wide area network (WAN)). These various types of communication modules may be implemented as a single component (e.g., a single IC), or may be implemented as multiple components (e.g., multiple ICs) that are separate from each other.

At least some of the above-described components may be mutually coupled and communicate signals (e.g., commands or data) there between via an inter-peripheral communication scheme (e.g., a bus, a general purpose input and output (GPIO), a serial peripheral interface (SPI), or a mobile industry processor interface (MIPI)).

According to one embodiment, commands or data may be transmitted or received between the electronic device <NUM> and the external electronic device <NUM> via the server <NUM> coupled with the second network <NUM>.

Claim 1:
A method (<NUM>), comprising:
transmitting (<NUM>), from a first user equipment, UE, an assistance request to at least one neighboring UE;
receiving (<NUM>), by the first UE and from the at least one neighboring UE (<NUM>, <NUM>, <NUM>), assistance information including an indication of at least one resource for transmission; and
transmitting (<NUM>), from the first UE, over the indicated at least one resource, wherein the assistance request is transmitted via sidelink control information, SCI, characterized in that the assistance request is set by using a reserved value for a field in SCI.