Patent Description:
It is expected that vehicle-to-everything (V2X) communications will play an essential role in the evolution of the automotive industry in the near future and revolutionize the field. Dedicated short-range communication (DSRC) by IEEE and the long-term evolution - vehicular (LTE-V) developed by 3GPP are two major vehicular communication technologies developed thus far.

The third generation partnership project (3GPP) has also approved a work item. "Revised WID on <NUM> V2X with NR sidelink," LGE, RAN#<NUM>, Newport Beach, USA, September <NUM>-<NUM>, <NUM>, for the standardization of the fifth generation (<NUM>) new radio access technology (NR) vehicle-to-everything (V2X) wireless communication with the goal of providing <NUM>-compatible high-speed reliable connectivity for vehicular communications in the near future for applications such as safety systems and autonomous driving. High data rates, low latencies and high reliabilities are some of the key areas that are being investigated and standardized.

V2X communications constitute communications on the sidelink (SL) between devices such as user equipment (UEs), road side units (RSUs), pedestrians (P), in addition to downlink (DL) (base station to UE) and uplink (UL) (UE to base station). For V2X communication, groupcast is supported. One groupcast option is to have groups formed based on geographical distance.

In some cases, one UE can lose its location information. It thus cannot perform group operations based on distance. In such a case, the UE needs to interrupt distance-based operation. Thus, there is a need for a method to disable distance-based operation.

The 3GPP standard change proposal "<NPL>" proposes several options to handle the case where RX UE's location is unavailable, including disabling the HARQ feedback.

Another 3GPP standard change proposal "<NPL>" which also deals with the problem of the location information being unavailable at the RX UE side, observes that disabling HARQ feedback in this case would reduce the reliability of emergency (high priority) traffic. However, to avoid that, it is here proposed to always perform HARQ feedback when location information of the RX UE is not available.

Hence, the object of the present invention is to provide improved methods and communication devices which can avoid an erroneous interpretation when option <NUM> hybrid automatic repeat request (HARQ) feedback for sidelink communication is disabled but the communication device does not have its location information. This object is solved by the attached independent claims and further embodiments and improvements of the invention are listed in the attached dependent claims. Hereinafter, up to the "brief description of the drawings", expressions like ". aspect according to the invention", "according to the invention", or "the present invention", relate to technical teaching of the broadest embodiment as claimed with the independent claims. Expressions like "implementation", "design", "optionally", "preferably", "scenario", "aspect" or similar relate to further embodiments as claimed, and expressions like "example", ". aspect according to an example", "the disclosure describes", or "the disclosure" describe technical teaching which relates to the understanding of the invention or its embodiments, which, however, is not claimed as such.

According to a first aspect, a method according to the invention implemented by a first communication device is provided. This method comprising: receiving, by the first communication device, a first indicator indicating distance based HARQ feedback operation with negative acknowledgement only and a first sidelink message grant; and determining, by the first communication device, that location information associated with the first communication device is unavailable, and based thereon, transmitting, by the first communication device, a second indicator indicating that the location information is unavailable.

In a first implementation form of the method according to the first aspect, the first indicator being received in a sidelink control information (SCI) message.

In a second implementation form of the method according to the first aspect or any preceding implementation form of the first aspect, the first communication device comprising a sidelink user equipment (UE).

In a third implementation form of the method according to the first aspect or any preceding implementation form of the first aspect, the second indicator being transmitted in a physical sidelink control channel (PSCCH).

In a fourth implementation form of the method according to the first aspect or any preceding implementation form of the first aspect, the second indicator being transmitted in a combination of a physical sidelink feedback channel (PSFCH) and a radio resource control (RRC) message.

In a fifth implementation form of the method according to the first aspect or any preceding implementation form of the first aspect, the first indicator being received from a second communication device.

In a sixth implementation form of the method according to the first aspect or any preceding implementation form of the first aspect, the location information comprising a location of the first communication device.

In a seventh implementation form of the method according to the first aspect or any preceding implementation form of the first aspect, the second indicator being transmitted to a second communication device.

In an eighth implementation form of the method according to the first aspect or any preceding implementation form of the first aspect, further comprising: receiving, by the first communication device from a third communication device, a third indicator indicating a second sidelink message grant; determining, by the first communication device, that the location information is available, and based thereon: evaluating, by the first communication device, a distance between the first communication device and the third communication device; and determining, by the first communication device, that a sidelink message associated with the second sidelink message grant was unsuccessfully received and the distance meets a distance threshold, and based thereon, transmitting, by the first communication device to the third communication device, a negative acknowledgement (NACK).

According to a second aspect, another method according to the invention implemented by a first communication device is provided. This method comprising: receiving, by the first communication device, a first indicator indicating distance based HARQ feedback operation with negative acknowledgement only and a first sidelink message grant; and determining, by the first communication device, that location information is unavailable and a first sidelink message associated with the first sidelink message grant was unsuccessfully received, and based thereon: determining, by the first communication device, a priority of the first sidelink message associated with the first sidelink message grant meets a priority threshold, and based thereon, transmitting a NACK.

In a first implementation form of the method according to the second aspect, further comprising: receiving, by the first communication device, a second indicator indicating a second sidelink message grant; and determining, by the first communication device, that the location information is unavailable and a second sidelink message associated with the second sidelink message grant was unsuccessfully received, and based thereon: determining, by the first communication device, a priority of the second sidelink message associated with the second sidelink message grant fails to meet the priority threshold, and based thereon, not sending by the first communication device, a transmission of the NACK.

In a second implementation form of the method according to the second aspect or any preceding implementation form of the second aspect, the first indicator being received in a SCI message.

In a third implementation form of the method according to the second aspect or any preceding implementation form of the second aspect, the first indicator being received from a second communication device.

According to a third aspect according to the invention, a first communication device is provided. This first communication device comprising: one or more processors; and a non-transitory memory storage comprising instructions that, when executed by the one or more processors, cause the first communication device to: receive a first indicator indicating distance based HARQ feedback operation with negative acknowledgement only and a first sidelink message grant; and determine that location information associated with the first communication device is unavailable, and based thereon, transmitting, by the first communication device, a second indicator indicating that the location information is unavailable.

In a first implementation form of the first communication device according to the third aspect, the first indicator being received in a SCI message.

In a second implementation form of the first communication device according to the third aspect or any preceding implementation form of the third aspect, the first communication device comprising a sidelink UE.

In a third implementation form of the first communication device according to the third aspect or any preceding implementation form of the third aspect, the second indicator being transmitted in a PSCCH.

In a fourth implementation form of the first communication device according to the third aspect or any preceding implementation form of the third aspect, the second indicator being transmitted in a combination of a PSFCH and a RRC message.

In a fifth implementation form of the first communication device according to the third aspect or any preceding implementation form of the third aspect, the first indicator being received from a second communication device.

In a sixth implementation form of the first communication device according to the third aspect or any preceding implementation form of the third aspect, the location information comprising a location of the first communication device.

In a seventh implementation form of the first communication device according to the third aspect or any preceding implementation form of the third aspect, the second indicator being transmitted to a second communication device.

In an eighth implementation form of the first communication device according to the third aspect or any preceding implementation form of the third aspect, the instructions further causing the first communication device to: receive, from a third communication device, a third indicator indicating a second sidelink message grant; determine that the location information is available, and based thereon: evaluate a distance between the first communication device and the third communication device; and determine that a sidelink message associated with the second sidelink message grant was unsuccessfully received and the distance meets a distance threshold, and based thereon, transmit, to the third communication device, a NACK.

According to a fourth aspect according to the invention, another first communication device is provided. This first communication device comprising: one or more processors; and a non-transitory memory storage comprising instructions that, when executed by the one or more processors, cause the first communication device to: receive a first indicator indicating distance based HARQ feedback operation with negative acknowledgement only and a first sidelink message grant; and determine that location information is unavailable and a first sidelink message associated with the first sidelink message grant was unsuccessfully received, and based thereon: determine a priority of the first sidelink message associated with the first sidelink message grant meets a priority threshold, and based thereon, transmitting a NACK.

In a first implementation form of the first communication device according to the fourth aspect, the instructions further causing the first communication device to: receive a second indicator indicating a second sidelink message grant; and determine that the location information is unavailable and a second sidelink message associated with the second sidelink message grant was unsuccessfully received, and based thereon: determine a priority of the second sidelink message associated with the second sidelink message grant fails to meet the priority threshold, and based thereon, stop not sending a transmission of the NACK.

In a second implementation form of the first communication device according to the fourth aspect or any preceding implementation form of the fourth aspect, the first indicator being received in a SCI message. In a third implementation form of the first communication device according to the fourth aspect or any preceding implementation form of the fourth aspect, the first indicator being received from a second communication device.

According to the invention it is possible to disable participation in distance based groupcast option <NUM> operation when the UE does not have its location information. Disabling UE participation helps to prevent incorrect operation when the UE does not send positive feedback, which would lead to the UE being interpreted as being too far away or that the transmission was received correctly. Neither of which are correct. Sending negative feedback is also incorrect behavior and may lead to unnecessary retransmissions.

The structure and use of disclosed embodiments are discussed in detail below. It should be appreciated, however, that the present disclosure provides many applicable concepts that can be embodied in a wide variety of specific contexts. The specific embodiments discussed are merely illustrative of specific structure and use of embodiments, and do not limit the scope of the disclosure.

<FIG> illustrates an example communications system <NUM>. Communications system <NUM> includes an access node <NUM>, with coverage area <NUM>, serving user equipments (UEs), such as UEs <NUM>. Access node <NUM> is connected to a backhaul network <NUM> that provides connectivity to services and the Internet. In a first operating mode, communications to and from a UE passes through access node <NUM>. In a second operating mode, communications to and from a UE do not pass through access node <NUM>, however, access node <NUM> typically allocates resources used by the UE to communicate when specific conditions are met. Communication between a UE pair in the second operating mode occurs over sidelinks <NUM>, comprising uni-directional communication links. Communication between a UE and access node pair also occur over uni-directional communication links, where the communication links between the UE and the access node are referred to as uplinks <NUM>, and the communication links between the access node and UE is referred to as downlinks <NUM>.

Access nodes may also be commonly referred to as Node Bs, evolved Node Bs (eNBs), next generation (NG) Node Bs (gNBs), master eNBs (MeNBs), secondary eNBs (SeNBs), master gNBs (MgNBs), secondary gNBs (SgNBs), network controllers, control nodes, base stations, access points, transmission points (TPs), transmission-reception points (TRPs), cells, carriers, macro cells, femtocells, pico cells, and so on, while UEs may also be commonly referred to as mobile stations, mobiles, terminals, users, subscribers, stations, and the like. Access nodes may provide wireless access in accordance with one or more wireless communication protocols, e.g., the Third Generation Partnership Project (3GPP) long term evolution (LTE), LTE advanced (LTE-A), <NUM>, <NUM> LTE, <NUM> NR, sixth generation (<NUM>), High Speed Packet Access (HSPA), the IEEE <NUM> family of standards, such as <NUM>. 11a/b/g/n/ac/ad/ax/ay/be, etc. While it is understood that communications systems may employ multiple access nodes capable of communicating with a number of UEs, only one access node and two UEs are illustrated for simplicity.

For the purpose of sidelink communications, where communications occur between UEs without the involvement of an access node (except with the potential allocation of the resources by the access node), the notion of resource pools (RPs) was introduced for the LTE sidelink, and is being reused for NR sidelink. A resource pool is a set of resources that can be used for sidelink communication. Resources in a resource pool are configured for different channels including control channels (e.g., physical sidelink control channel (PSCCH)), shared channels (e.g., physical sidelink shared channel (PSSCH)), feedback channels, synchronization signals, reference signals, broadcast channels (e.g., master information block (MIB)), and so on. The technical standard defines rules on how the resources are shared and used for a particular configuration of the resource pool. However, the rules usually allow for a possibility of conflicts between multiple communications by a UE. For example, if a UE needs to transmit and receive at the same time, there is a conflict for the UE because of the half-duplex operation constraint. Another example is when a UE needs to transmit signals beamformed to different directions through a same antenna. If the antenna employs analog beamforming, which is the common practice at high frequencies, the UE cannot always perform the communications simultaneously in multiple directions.

According to the current agreements in 3GPP working group RAN1, a resource pool for sidelink can be configured in units of slots in the time domain and physical resource blocks (PRBs) or sub-channels in the frequency domain. A sub-channel consists of one or more PRBs. <FIG> illustrates a diagram <NUM> of an example resource pool <NUM>. Resource pool <NUM> is shown in a time-frequency resource grid with time-domain slots (such as slot <NUM>) and frequency-domain PRBs or sub-channels (such as sub-channel <NUM>). The resource grid is configured in a band, a carrier component (CC), a bandwidth part (BWP), and so on. The number of PRBs in a resource pool can differ in each slot. In addition, the location of the resource pool can differ in each slot. The resource pool may also be absent in any particular slot.

In the rest of this disclosure, resources in the RP are illustrated with simplifications. For example, resources are shown contiguous in both time and frequency domains although they may not be contiguous in the resource grid as shown in the above example. Also, the frequency resources are not necessarily shown at the PRB/sub-channel resolution in the frequency domain.

For NR mobile broadband (MBB), each PRB in the resource grid is defined as a slot comprising <NUM> consecutive orthogonal frequency division multiplexed (OFDM) symbols in the time domain and <NUM> consecutive subcarriers in the frequency domain, i.e., each resource block contains <NUM>×<NUM> resource elements (REs). When used as a frequency-domain unit, a PRB denotes <NUM> consecutive subcarriers. There are <NUM> symbols in a slot when a normal cyclic prefix is used and <NUM> symbols in a slot when an extended cyclic prefix is used. The duration of a symbol is inversely proportional to the subcarrier spacing (SCS). For a {<NUM>, <NUM>, <NUM>, <NUM>} kHz SCS, the duration of a slot is {<NUM>, <NUM>, <NUM>, <NUM>} ms, respectively. A <NUM> subframe spans <NUM>, <NUM>, <NUM>, <NUM>} or equivalently <NUM>µ slots where µ={<NUM>, <NUM>, <NUM>, <NUM>} for {<NUM>, <NUM>, <NUM>, <NUM>} kHz SCS, respectively. Each PRB can be allocated to combinations of control channel, shared channel, feedback channel, reference signals, and so on. In addition, some REs of a PRB can be reserved. A similar structure is likely to be used on the sidelink as well. A communication resource can be a PRB, a set of PRBs, a code (if code division multiple access (CDMA) is used, similarly as for the physical uplink control channel (PUCCH)), a physical sequence, a set of REs, and so on.

The feedback channel in the NR sidelink is used for communication of hybrid automatic repeat request (HARQ) feedback, which comprises an acknowledgment (ACK) or a negative acknowledgement (NACK) of successful receipt of a block of data in a shared channel. The amount of ACK/NACK (A/N) information is small and, therefore, the physical sidelink feedback channel (PSFCH) does not need to be configured (or transmitted) in every slot of a resource pool if the latency constraints allow it. Instead, as agreed in RAN1, a PSFCH can be configured on one every N slots in the resource pool (possibly more symbols in future releases), where N may take integer values such as <NUM>, <NUM>, <NUM>, etc. Therefore, if slot nf in the resource pool contains PSFCH resources, so do slots nf + N, nf + <NUM>N, nf + 3N,. The notation k mod N = nf can be used to indicate every slot k that contains a PSFCH 'instance' or a PSFCH 'opportunity.

When a transmitting UE (source UE or TxUE) transmits signals (e.g., for a shared channel carrying data or payload) to a receiving UE (destination UE or RxUE), the destination UE attempts to demodulate and decode the signals. If the process (e.g., the decoding) is successful, the destination UE sends an ACK to the source UE; otherwise, the destination UE sends a NACK to the source UE. An example of an ACK is a logical or binary "<NUM>" while a NACK is a logical or binary "<NUM>". The reverse may also be utilized. Whether the destination UE sends an ACK/NACK depends on the standard and the HARQ process configuration. There are generally four possible cases, which are shown in Table <NUM>.

A typical operation is for the source UE to transmit a control channel and a shared channel in the same slot. The control channel includes sidelink control information (SCI) indicating the scheduling of the shared channel, where the scheduling provides information for the location (e.g., start and size) of the shared channel, the modulationcoding scheme (MCS), and so forth. The control channel may include additional information, such as fields related to the HARQ process, such as a redundancy version, a new data indicator, and a HARQ process number. If the destination UE is unable to decode the control channel for a single transmission, no feedback signal should be transmitted by the destination UE. The same concept is applicable even if the transmission of the shared channel spans multiple slots with the control channel being transmitted in the first slot. However, if a periodic or semi-persistent transmission is scheduled for a source UE, and the destination UE fails to receive a transport block (TB), the destination UE can send a NACK to the source UE.

Except for the last case shown in Table <NUM>, the RxUE may need to transmit a feedback. Having knowledge of nf and N as well as other configuration parameters, the RxUE can locate PSFCH resources that can be used for transmitting the feedback. However, there is another parameter that the RxUE needs to consider. When RxUE receives the signals, the RxUE needs time to process and decode the signal, create the ACK/NACK signals, and so on. The minimum time needed between receiving the last symbol of the signal and transmitting the feedback signals should be known.

It is agreed in RAN1 to have a parameter K as the minimum slot number difference between the slot containing the last symbol of a physical sidelink shared channel (PSSCH) and the slot containing its associated PSFCH. The value of K may be determined by the standard, may be (pre)configured, or may depend on a UE capability. In any case, should the RxUE that is receiving signals on a PSSCH transmit a feedback, the RxUE does so in slot n + a, where n is the slot containing the last symbol of the PSSCH and a is the smallest integer larger than or equal to K with the condition that slot n + a contains PSFCH. Therefore, K ≤ a ≤ K + N - <NUM>.

Another parameter X may be defined as the number of PSFCH symbols in a PSFCH format with a repetition of a one-symbol PSFCH. For example, when X = <NUM>, A/N feedback is not repeated; but when X = <NUM>, the RxUE retransmits the A/N feedback, which can improve reliability by increasing the effective signal-to-noise ratio (SNR) of the feedback signal received by the TxUE. For Rel-<NUM>, X=<NUM> is supported.

<FIG> illustrates a diagram <NUM> of an example PSFCH configuration with parameters N, K, and X in a RP. As shown in <FIG>, a TxUE transmits signals on PSSCHm in slot n <NUM>. In this example, the earliest possible slot for the corresponding A/Nm, i.e., n + K (slot <NUM>), does not contain PSFCH resources. Hence, the RxUE should wait an additional number of slots in order to transmit feedback.

In the example illustrated in <FIG>, an OFDM symbol is designated as a guard period (GP), such as GP <NUM>, immediately preceding the PSFCH symbols <NUM> in order to allow UEs to switch (possibly) between transmission and reception modes. In addition, time may be needed for automatic gain control (AGC) circuitry to settle at the UE receiving the PSFCH (i.e., the TxUE). This time may be part of a GP symbol or be another symbol. Another AGC symbol, not shown in <FIG>, may be the first symbol of a slot. AGC and GP symbols, as well as other signals such as reference signals in a slot, may be omitted in figures of this disclosure unless needed. Furthermore, X is usually assumed <NUM> unless stated otherwise.

<FIG> illustrates a diagram <NUM> of a resulting mapping of PSSCH resources to the corresponding PSFCH. As an example, N slots <NUM> are mapped to PSFCH <NUM>.

Similar to the design of PUCCH formats, different PSFCH formats are possible and likely to be approved for different scenarios. The different formats can be categorized as short (e.g., <NUM>-<NUM> OFDM symbols) or long (e.g., longer than <NUM> OFDM symbols), which can be used for different SNR needs. Another possible format may include more PRBs. Also, in terms of the payload size, different formats can be defined that carry a small payload of <NUM> or <NUM> bits versus larger payloads, the latter case useful if ACK/NACK bundling will be adopted. Table <NUM> summarizes the NR Rel-<NUM> PUCCH formats.

Typical PSFCH formats could be based on PUCCH format o and format <NUM>, both short formats, but suitable for carrying ≤<NUM> bits and ><NUM> bits, respectively. A PSFCH format based on PUCCH format o can be designed based on sequence selection, which can be utilized for application of some example embodiments in this disclosure.

As presented in 3GPP TR <NUM>, which is hereby incorporated herein by reference in its entirety, there are two options for HARQ feedback when groupcast is used. For sidelink unicast and groupcast, HARQ feedback and HARQ combining in the physical layer are supported. HARQ-ACK feedback for a PSSCH is carried in sidelink feedback control information (SFCI) format(s) via PSFCH in resource allocation Modes <NUM> and <NUM>.

When sidelink HARQ feedback is enabled for unicast, in the case of non-code block group (non-CBG) operation the RxUE generates HARQ-ACK if it successfully decodes the corresponding TB. The RxUE generates HARQ-NACK if it does not successfully decode the corresponding TB after decoding the associated PSCCH targeted to the RxUE. When sidelink HARQ feedback is enabled for groupcast, it is supported to use TxUE-RxUE (TX-RX) distance and/or reference signal received power (RSRP) in deciding whether to send HARQ feedback. In the case of non-CBG operation, two options are supported:.

Regarding the use of TX-RX geographical distance or RSRP in determining whether to send HARQ feedback for groupcasts, it has been agreed upon to support at least the use of TX-RX geographical distance. The support of layer <NUM> (L1) RSRP is an item for further study. Therefore, for at least option <NUM> based TX-RX distance-based HARQ feedback for groupcasts, a RxUE transmits HARQ feedback for the PSSCH if the TX-RX distance is smaller or equal to the communication range requirement. Otherwise, the RxUE does not transmit HARQ feedback for the PSSCH. TxUE's location is indicated by SCI associated with the PSSCH, and the TX-RX distance is estimated by RxUE based on its own location and TxUE's location. The communication range requirement used for a particular PSSCH is known after decoding the SCI associated with the PSSCH.

<FIG> illustrates a diagram <NUM> of an example groupcast operation. As shown in <FIG>, a UE <NUM> is stopped at a first street with a plurality of UEs (including UEs <NUM>, <NUM>, <NUM>, and <NUM>) moving on a cross street. UE <NUM> is operating as a TxUE and makes transmissions to the UEs of the plurality of UEs. As an example, UE <NUM> makes a transmission <NUM> to UE <NUM> and a transmission <NUM> to UE <NUM>. UE <NUM> receives transmission <NUM> and sends an ACK <NUM> to acknowledge successful reception of transmission <NUM>. Similarly, UE <NUM> receives transmission <NUM> and sends an ACK <NUM> to acknowledge successful reception of transmission <NUM>. As another example, UE <NUM> is unable to correctly receive transmission <NUM> and sends a NACK <NUM> to indicate unsuccessful reception of transmission <NUM>.

<FIG> illustrates a diagram <NUM> of an example usage of distance-based groupcast option <NUM> operation. As shown in <FIG>, a UE <NUM> is stopped at a first street with a plurality of UEs (including UEs <NUM> and <NUM>) moving on a cross street. UE <NUM> is operating as a TxUE. A dashed circle <NUM> represents a communication range requirement, where if a RxUE receives a transmission from the TxUE AND the RxUE is within the communication range, the RxUE sends HARQ feedback (based on its ability to decode the transmission). UE <NUM> makes a transmission <NUM> to UE <NUM>, and UE <NUM> successfully receives transmission <NUM>, hence, UE <NUM> transmits an ACK <NUM> to UE <NUM>. UE <NUM> also makes a transmission <NUM> to UE <NUM>, but UE <NUM> is unable to successfully receive transmission <NUM>. Hence, UE <NUM> sends a NACK <NUM> to indicate unsuccessful reception of transmission <NUM>. UE <NUM> further makes a transmission <NUM> to UE <NUM>. However, UE <NUM> is outside of the communication range. Therefore, transmission <NUM> is an irrelevant message and UE <NUM> does not send HARQ feedback, independent of whether or not transmission <NUM> was successfully received.

<FIG> illustrates a diagram <NUM> of an example deployment of distance-based groupcast option <NUM> operation. An example deployment of distance-based groupcast option <NUM> operation is a traffic-based deployment with the TxUE <NUM> being a street signal. Street signal <NUM> may groupcast its status, such as red light, green light, or yellow light, to RxUEs located within communication range <NUM>. RxUEs within communication range <NUM> send HARQ feedback in accordance with the decoding of transmissions made by TxUE <NUM>. However, UEs that are not in communication range <NUM> do not send HARQ feedback regardless of their ability to successfully receive transmissions made by TxUE <NUM>.

When distance-based groupcast option <NUM> is used by a UE group, the RxUE (that is part of the UE group) sends a NACK if it has not correctly received the packet AND if it is within a specified distance from the TxUE. However, if the RxUE does not know its location (e.g., due to loss of the Global Navigation Satellite System (GNSS) signal, for example), the RxUE has no idea if it needs to send HARQ feedback. If the RxUE sends nothing in this situation, is interpreted as either the RxUE is too far away (the RxUE is not within the communication range requirement of the TxUE) OR that the RxUE is within a given distance and the packet was received correctly, neither of which is correct. Sending a NACK in this situation is also not correct, because the ReUE may actually not be within the communication range requirement and actions subsequently taken by the TxUE (such as re-transmitting a packet to the group) may be unnecessary and wasteful. Therefore, there is a need for the RxUE to notify the TxUE that distance-based groupcast option <NUM> needs to be disabled.

According to an example embodiment, methods and apparatus are provided for disabling of option <NUM> HARQ feedback. There may be several situations when it becomes necessary to disable option <NUM> HARQ feedback. They include: <NUM>) the RxUE temporarily loses its location information, and <NUM>) the RxUE is not able to access its location. In either situation, it is necessary to disable option <NUM> HARQ feedback because incorrect operation can lead to incorrect results (when the RxUE sends no HARQ feedback) or unnecessary re-transmissions (when the RxUE sends a NACK).

According to an example embodiment, in the situation when the RxUE loses its location information, the RxUE disables distance-based groupcast option <NUM> operation. In this situation, the RxUE may have been operating in distance-based groupcast option <NUM> mode, but at a given point in time, the RxUE loses its distance-based information (the RxUE may lose the GNSS signal, for example) and disables the distance-based groupcast option <NUM> operation. In an embodiment, the RxUE disables the distance-based groupcast option <NUM> operation for itself. In an embodiment, the RxUE disables the distance-based groupcast option <NUM> operation by sending an indication disabling the distance-based groupcast option <NUM> operation.

<FIG> illustrates a flow diagram of example operations <NUM> occurring in a RxUE operating in distance-based groupcast option <NUM> mode. Operations <NUM> may be indicative of operations occurring in a RxUE as the RxUE operates in distance-based groupcast option <NUM> mode.

Operations <NUM> begin with the RxUE receiving a SCI message indicating that the RxUE has a downlink grant to receive a packet (block <NUM>). The SCI message also indicates that distance-based groupcast option <NUM> mode is used. As an example, the SCI message includes a flag or <NUM>-bit indicator indicating that HARQ is used, a field indicating that a second stage SCI is for distance-based groupcast option <NUM> mode, and the second stage SCI indicating the communication range for reporting HARQ feedback.

The RxUE performs a check to determine if location information is available (block <NUM>). The RxUE may check to determine if it has current location information, where current location information is location information that may be less than a specified age, for example.

If the RxUE does have location information, the RxUE evaluates the distance between itself and the TxUE, and if the distance is greater than the communication range (indicated in the SCI message, for example), the RxUE reports nothing. The communication range is an example of a distance threshold. In general, a distance threshold may be a distance measurement (based on GNSS information, for example). But other forms of distance thresholds may also be used. As an example, signal strength or signal quality information may be used to infer or estimate the distance. In such a situation, if the signal strength or signal quality is determined to be below a signal threshold, the distance between the RxUE and the TxUE may be considered to be greater than the communication range.

However, if the distance is less than (or less than or equal to) the communication range AND if the RxUE has not successfully received the packet associated with the downlink grant, the RxUE sends a NACK (block <NUM>). In an embodiment, if the distance is less than (or less than or equal to) the communication range AND if the RxUE has successfully received the packet associated with the downlink grant, the RxUE sends nothing. In an embodiment, if the distance is less than (or less than or equal to) the communication range AND if the RxUE has successfully received the packet associated with the downlink grant, the RxUE sends an ACK.

If the RxUE does not have location information, the RxUE sends an indication that location information is unavailable (block <NUM>). If the RxUE does not have location information, the RxUE does not know if it is within the communication range. Hence, the RxUE does not know if has to report HARQ feedback.

There may be several ways to send the indication that location information is unavailable, they include:.

In the situation where the PHY layer message is used, a new SCI format may be used.

In case of unicast, or generally speaking, when the transmission is symmetric, with each UE transmitting a similar amount of data with similar periodicity, then after receiving a message, the RxUE will become the TxUE. In such a case, the RxUE (now the TxUE) will send an SCI to the TxUE (now the RxUE). The RxUE can then indicate in the SCI that option <NUM> is not to be used because of location information being unavailable.

In an embodiment, when the RxUE is checking to determine if location information is available, the RxUE considers information in addition to a single SCI message. As an example, the RxUE considers location information to be unavailable if it is unavailable for a specified number of consecutive slots (e.g., <NUM> or <NUM> consecutive slots, but other values are possible), a specified number of slots out of a number of slots (e.g., <NUM> slots out of the last <NUM> slots, but other values are possible). In this embodiment, timers or counters may be used to determine if location information is available. While the location information is still considered to be available (although not at the time of reception of the latest SCI), the most recent location information is used for block <NUM>, for example. Alternatively, the RxUE is considered to be in range. Alternatively, the RxUE is considered to be out of range.

Location information may be unavailable before the communication of a PC5 RRC or a capability exchange, if some UEs are not able to provide location information at all (see the discussion presented below). If, by default, UEs are assumed to be capable of providing location information and incapability needs to be signaled, the TxUE may indicate option <NUM> HARQ to RxUEs in the group including the RxUE before the RxUE indicates its incapability. In an alternate embodiment, until the PC5 RRC exchange or similar method of capability exchange occurs, the RxUE may behave as if location information is available, and either consider itself to be in range (the RxUE sending NACK if the packet is not received correctly and nothing if received correctly) or out of range (the RxUE sends nothing).

In an alternate embodiment, the RxUE behavior when the RxUE does not have location information available is undefined. The RxUE may decide to behave as if it is in range, or out of range. The RxUE may send nothing in response to the packet transmission, or the RxUE may send NACK if the packet is not successfully received. In an alternate embodiment, the undefined UE behavior is used prior to a PC5 RRC capability exchange. In an alternate embodiment, the RxUE determines if it is in range by substituting its unknown location with the location of another UE or the access node, if it was last in coverage of or in close range to that UE or access node.

Although the discussion presented herein focuses on location and location information, the example embodiments are also operable with range. As an example, if a RxUE knows that it is within a given range of the TxUE (either through location information or derivation from other information, such as RSRP or received signal strength indicator (RSSI) measurements, or if the RxUE does not know if it is within range, the RxUE may behave as discussed above for situations when the RxUE knows its location or if the location information is unavailable. Therefore, the discussion of location and location information should not be construed as being limiting to the scope of the example embodiments.

According to an example embodiment, in the situation when the RxUE does not have access to its location, the RxUE indicates that if it is able to obtain its location or if it is able to perform distance-based HARQ feedback. In such a situation, the RxUE is not able perform distance-based groupcast operation at all until it is able to obtain its location. Hence, if the RxUE is unable to obtain its location, the RxUE cannot perform distance-based groupcast operation. In an embodiment, the RxUE indicates if it is able to obtain its location. In an embodiment, the RxUE indicates if it can perform distance-based HARQ feedback operation. In an embodiment, the RxUE sends an RRC signaling message. The message may indicate that the RxUE does not have location information. Alternatively, the RxUE may send a message to be suspended from the group (the group participating in the groupcast) for a specified time period or until a further message is received. Alternatively, the RxUE may send a message to leave the group. The RRC signaling message may be sent using PC5 RRC signaling when the group including the RxUE is established.

The RxUE performs a check to determine if location information is available (block <NUM>). The RxUE may check to determine if it has access to the location information, for example.

If the RxUE does have location information, the RxUE evaluates the distance between itself and the TxUE, and if the distance is greater than the communication range (indicated in the SCI message, for example), the RxUE reports nothing. However, if the distance is less than (or less than or equal to) the communication range AND if the RxUE has not successfully received the packet associated with the downlink grant, the RxUE sends a NACK (block <NUM>). In an embodiment, if the distance is less than (or less than or equal to) the communication range AND if the RxUE has successfully received the packet associated with the downlink grant, the RxUE sends nothing. In an embodiment, if the distance is less than (or less than or equal to) the communication range AND if the RxUE has successfully received the packet associated with the downlink grant, the RxUE sends an ACK.

If the RxUE does not have the location information, the RxUE sends an indication that it is unable to perform distance-based groupcast operation (block <NUM>). If the RxUE does not have access to the location information, the RxUE is not able to participate to distance-based groupcast operation, so the RxUE informs the TxUE that the RxUE is unable to participate in distance-based groupcast operation. The RxUE sends an RRC signaling message. The message may indicate that the RxUE does not have location information. Alternatively, the RxUE may send a message to be suspended from the group (the group participating in the groupcast) for a specified time period or until a further message is received. Alternatively, the RxUE may send a message to leave the group. The RRC signaling message may be sent using PC5 RRC signaling when the group including the RxUE is established.

Although the discussion presented herein does not focus on packet priority, the example embodiments are operable when packet priority is considered. As an example, the rules applied to HARQ feedback may depend upon the priority level. For instance, for a high priority packet, if the RxUE does not have location information and if the packet was not successfully received, the RxUE may still send a NACK (given that the packet is a high priority packet). Similarly, for a low priority packet when the RxUE does not have location information, the RxUE may behave as described previously.

In an embodiment, the RxUE always transmits a NACK if location information is unavailable even if the packet is successfully received. In this situation, the RxUE may be implicitly indicating to the TxUE that the RxUE does not want to operate in distance-based groupcast option <NUM> mode.

<FIG> illustrates a flow diagram of example operations <NUM> occurring in a RxUE operating in distance-based groupcast option <NUM> mode highlighting packet priority based operation. Operations <NUM> may be indicative of operations occurring in a RxUE as the RxUE operates in distance-based groupcast option <NUM> mode, and highlights packet priority based operation.

If the RxUE does have location information, the RxUE evaluates the distance between itself and the TxUE, and if the distance is less than (or less than or equal to) the communication range (as indicated in the SCI message), the RxUE reports HARQ feedback based on the success or failure of receiving the packet associated with the downlink grant (block <NUM>).

If the RxUE does not have location information, the RxUE performs a check to determine if the priority of the packet associated with the downlink grant meets a priority threshold (block <NUM>). The priority threshold may be specified in a technical standard, or by an operator of the communication system. Alternatively, the RxUEs and the TxUEs may collaborate to determine the priority threshold.

If the priority threshold is met, the RxUE sends a NACK if the packet is not received (block <NUM>). If the priority threshold is not met, the RxUE does not send a NACK if the packet is not received (block <NUM>). The difference in behavior (sending a NACK or not sending a NACK) based on priority may be helpful in ensuring the delivery of high priority packets at the expense of potentially unnecessary re-transmissions.

<FIG> illustrates an example communication system <NUM>. In general, the system <NUM> enables multiple wireless or wired users to transmit and receive data and other content. The system <NUM> may implement one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), or non-orthogonal multiple access (NOMA).

In this example, the communication system <NUM> includes electronic devices (ED) 910a-910c, radio access networks (RANs) 920a-920b, a core network <NUM>, a public switched telephone network (PSTN) <NUM>, the Internet <NUM>, and other networks <NUM>. While certain numbers of these components or elements are shown in <FIG>, any number of these components or elements may be included in the system <NUM>.

The EDs 910a-910c are configured to operate or communicate in the system <NUM>. For example, the EDs 910a-910c are configured to transmit or receive via wireless or wired communication channels. Each ED 910a-910c represents any suitable end user device and may include such devices (or may be referred to) as a user equipment or device (UE), wireless transmit or receive unit (WTRU), mobile station, fixed or mobile subscriber unit, cellular telephone, personal digital assistant (PDA), smartphone, laptop, computer, touchpad, wireless sensor, or consumer electronics device.

The RANs 920a-920b here include base stations 970a-970b, respectively. Each base station 970a-970b is configured to wirelessly interface with one or more of the EDs 910a-910c to enable access to the core network <NUM>, the PSTN <NUM>, the Internet <NUM>, or the other networks <NUM>. For example, the base stations 970a-970b may include (or be) one or more of several well-known devices, such as a base transceiver station (BTS), a NodeB (NodeB), an evolved NodeB (eNodeB), a Next Generation (NG) NodeB (gNB), a Home NodeB, a Home eNodeB, a site controller, an access point (AP), or a wireless router. The EDs 910a-910c are configured to interface and communicate with the Internet <NUM> and may access the core network <NUM>, the PSTN <NUM>, or the other networks <NUM>.

In the embodiment shown in <FIG>, the base station 970a forms part of the RAN 920a, which may include other base stations, elements, or devices. Also, the base station 970b forms part of the RAN 920b, which may include other base stations, elements, or devices. Each base station 970a-970b operates to transmit or receive wireless signals within a particular geographic region or area, sometimes referred to as a "cell. " In some embodiments, multiple-input multiple-output (MIMO) technology may be employed having multiple transceivers for each cell.

The base stations 970a-970b communicate with one or more of the EDs 910a-910c over one or more air interfaces <NUM> using wireless communication links. The air interfaces <NUM> may utilize any suitable radio access technology.

It is contemplated that the system <NUM> may use multiple channel access functionality, including such schemes as described above. In particular embodiments, the base stations and EDs implement <NUM> New Radio (NR), LTE, LTE-A, or LTE-B. Of course, other multiple access schemes and wireless protocols may be utilized.

The RANs 920a-920b are in communication with the core network <NUM> to provide the EDs 910a-910c with voice, data, application, Voice over Internet Protocol (VoIP), or other services. Understandably, the RANs 920a-920b or the core network <NUM> may be in direct or indirect communication with one or more other RANs (not shown). The core network <NUM> may also serve as a gateway access for other networks (such as the PSTN <NUM>, the Internet <NUM>, and the other networks <NUM>). In addition, some or all of the EDs 910a-910c may include functionality for communicating with different wireless networks over different wireless links using different wireless technologies or protocols. Instead of wireless communication (or in addition thereto), the EDs may communicate via wired communication channels to a service provider or switch (not shown), and to the Internet <NUM>.

The ED <NUM> also includes at least one transceiver <NUM>. The transceiver <NUM> is configured to modulate data or other content for transmission by at least one antenna or NIC (Network Interface Controller) <NUM>. The transceiver <NUM> is also configured to demodulate data or other content received by the at least one antenna <NUM>. Each transceiver <NUM> includes any suitable structure for generating signals for wireless or wired transmission or processing signals received wirelessly or by wire. Each antenna <NUM> includes any suitable structure for transmitting or receiving wireless or wired signals. One or multiple transceivers <NUM> could be used in the ED <NUM>, and one or multiple antennas <NUM> could be used in the ED <NUM>. Although shown as a single functional unit, a transceiver <NUM> could also be implemented using at least one transmitter and at least one separate receiver.

The ED <NUM> further includes one or more input/output devices <NUM> or interfaces (such as a wired interface to the Internet <NUM>). The input/output devices <NUM> facilitate interaction with a user or other devices (network communications) in the network. Each input/output device <NUM> includes any suitable structure for providing information to or receiving information from a user, such as a speaker, microphone, keypad, keyboard, display, or touch screen, including network interface communications.

In addition, the ED <NUM> includes at least one memory <NUM>. The memory <NUM> stores instructions and data used, generated, or collected by the ED <NUM>. For example, the memory <NUM> could store software or firmware instructions executed by the processing unit(s) <NUM> and data used to reduce or eliminate interference in incoming signals. Each memory <NUM> includes any suitable volatile or non-volatile storage and retrieval device(s). Any suitable type of memory may be used, such as random access memory (RAM), read only memory (ROM), hard disk, optical disc, subscriber identity module (SIM) card, memory stick, secure digital (SD) memory card, and the like.

Each transceiver <NUM> includes any suitable structure for generating signals for wireless or wired transmission to one or more EDs or other devices. Each transceiver <NUM> further includes any suitable structure for processing signals received wirelessly or by wire from one or more EDs or other devices. Although shown combined as a transceiver <NUM>, a transmitter and a receiver could be separate components. Each antenna <NUM> includes any suitable structure for transmitting or receiving wireless or wired signals. While a common antenna <NUM> is shown here as being coupled to the transceiver <NUM>, one or more antennas <NUM> could be coupled to the transceiver(s) <NUM>, allowing separate antennas <NUM> to be coupled to the transmitter and the receiver if equipped as separate components. Each memory <NUM> includes any suitable volatile or non-volatile storage and retrieval device(s). Each input/output device <NUM> facilitates interaction with a user or other devices (network communications) in the network. Each input/output device <NUM> includes any suitable structure for providing information to or receiving/providing information from a user, including network interface communications.

<FIG> is a block diagram of a computing system <NUM> that may be used for implementing the devices and methods disclosed herein. For example, the computing system can be any entity of UE, access network (AN), mobility management (MM), session management (SM), user plane gateway (UPGW), or access stratum (AS). Specific devices may utilize all of the components shown or only a subset of the components, and levels of integration may vary from device to device. Furthermore, a device may contain multiple instances of a component, such as multiple processing units, processors, memories, transmitters, receivers, etc. The computing system <NUM> includes a processing unit <NUM>. The processing unit includes a central processing unit (CPU) <NUM>, memory <NUM>, and may further include a mass storage device <NUM>, a video adapter <NUM>, and an I/O interface <NUM> connected to a bus <NUM>.

The video adapter <NUM> and the I/O interface <NUM> provide interfaces to couple external input and output devices to the processing unit <NUM>. As illustrated, examples of input and output devices include a display <NUM> coupled to the video adapter <NUM> and a mouse, keyboard, or printer <NUM> coupled to the I/O interface <NUM>. Other devices may be coupled to the processing unit <NUM>, and additional or fewer interface cards may be utilized. For example, a serial interface such as Universal Serial Bus (USB) (not shown) may be used to provide an interface for an external device.

The processing unit <NUM> also includes one or more network interfaces <NUM>, which may comprise wired links, such as an Ethernet cable, or wireless links to access nodes or different networks. The network interfaces <NUM> allow the processing unit <NUM> to communicate with remote units via the networks. For example, the network interfaces <NUM> may provide wireless communication via one or more transmitters/transmit antennas and one or more receivers/receive antennas. In an embodiment, the processing unit <NUM> is coupled to a local-area network <NUM> or a wide-area network for data processing and communications with remote devices, such as other processing units, the Internet, or remote storage facilities.

It should be appreciated that one or more steps of the embodiment methods provided herein may be performed by corresponding units or modules. For example, a signal may be transmitted by a transmitting unit or a transmitting module. A signal may be received by a receiving unit or a receiving module. A signal may be processed by a processing unit or a processing module. Other steps may be performed by a determining unit or module, or an evaluating unit or module. The respective units or modules may be hardware, software, or a combination thereof. For instance, one or more of the units or modules may be an integrated circuit, such as field programmable gate arrays (FPGAs) or application-specific integrated circuits (ASICs).

Claim 1:
A method implemented by a first communication device (<NUM>; <NUM>, <NUM>, <NUM>, <NUM>, <NUM>; <NUM>, <NUM>, <NUM>, <NUM>; <NUM>, <NUM>), the method comprising:
receiving (<NUM>; <NUM>; <NUM>), by the first communication device (<NUM>; <NUM>, <NUM>, <NUM>, <NUM>, <NUM>; <NUM>, <NUM>, <NUM>, <NUM>; <NUM>, <NUM>), a first indicator indicating distance based HARQ feedback operation with negative acknowledgement only and a first sidelink message grant; and
determining (<NUM>; <NUM>; <NUM>), by the first communication device (<NUM>; <NUM>, <NUM>, <NUM>, <NUM>, <NUM>; <NUM>, <NUM>, <NUM>, <NUM>; <NUM>, <NUM>), that location information associated with the first communication device (<NUM>; <NUM>, <NUM>, <NUM>, <NUM>, <NUM>; <NUM>, <NUM>, <NUM>, <NUM>; <NUM>, <NUM>) is unavailable, and based thereon, characterized by
transmitting (<NUM>), by the first communication device (<NUM>; <NUM>, <NUM>, <NUM>, <NUM>, <NUM>; <NUM>, <NUM>, <NUM>, <NUM>; <NUM>, <NUM>), a second indicator indicating that the location information is unavailable.