Patent Description:
Examples of such multiple-access systems include fourth generation (<NUM>) systems such as a Long Term Evolution (LTE) systems or LTE-Advanced (LTE-A) systems, and fifth generation (<NUM>) systems which may be referred to as New Radio (NR) systems. These systems may employ technologies such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal frequency division multiple access (OFDMA), or discrete Fourier transform-spread-OFDM (DFT-S-OFDM).

Base stations and UEs may support error correction schemes to improve the chances that transmissions are correctly received. HARQ is one example of an error correction scheme that increases the likelihood that information is received correctly over a wireless communications link. In HARQ, when a transmitting device receives an indication or otherwise determines that a receiving device failed to successfully decode a transmission of information, the transmitting device may retransmit the information to the receiving device. In some cases, however, it may be challenging for devices, such as base stations and UEs, to balance a number of HARQ retransmissions with latency in a wireless communications system. <CIT> discloses a method for scheduling data retransmissions, a method for use in a data retransmission scheme and a method for updating a soft buffer of a base station in a mobile communication system during a soft-handover. <CIT> discloses a method for transmitting a packet from a transmitter to a receiver in a wireless communication system which begins by building a packet by a transport format combination (TFC) selection process.

Some wireless communications systems may support hybrid automatic repeat request (HARQ) schemes to improve the likelihood that information is received correctly over a wireless communications link. In HARQ, when a transmitting device determines that a receiving device failed to successfully decode a transmission of information, the transmitting device may retransmit the information to the receiving device. In some cases, HARQ techniques may be used for communications associated with different types of services. In such cases, to keep the latency of communications within a latency budget for a particular type of service, wireless devices may utilize the techniques described herein to dynamically terminate HARQ retransmissions. For instance, a transmitting device may avoid retransmitting information when an amount of time that has elapsed since an original transmission of the information has exceeded the latency budget.

Methods, apparatus and a computer program are described in the appended claims.

Some wireless communications systems may support error correction schemes to improve the likelihood that information is correctly received by a receiving device. One example of an error correction scheme is a hybrid automatic repeat request (HARQ) scheme. In HARQ, when a transmitting device determines that a receiving device failed to successfully decode information transmitted to the receiving device (e.g., based on receiving a negative acknowledgement (NACK) or failing to receive HARQ feedback), the transmitting device may retransmit the information to the receiving device. In some cases, HARQ techniques may be used for communications associated with different types of services. In such cases, however, if a number of HARQ retransmissions is not limited for communications associated with a type of service, and HARQ retransmissions are scheduled after the latency budget corresponding to the type of service is exceeded, the retransmitted information may be useless and resources allocated for such retransmissions may be wasted.

Accordingly, some wireless communications systems may support techniques for configuring a maximum number of HARQ retransmissions for HARQ procedures at a base station and a user equipment (UE) (e.g., for different types of services). In some cases, the base station may signal an indication of the maximum number of retransmissions to a UE (e.g., via radio resource control (RRC) signaling). As such, a transmitting device may avoid retransmitting information to a receiving device after the transmitting device has retransmitted the information the maximum number of times. Further, after a receiving device receives the maximum number of retransmissions, the receiving device may pass the information received in an original transmission and other retransmissions (i.e., up to the maximum number of retransmissions) to upper layers for processing, and the receiving device may avoid monitoring or waiting for additional retransmissions.

In some cases, however, the relationship between a maximum number of retransmissions and latency may vary. For instance, in asynchronous HARQ, the intervals between previous transmissions (or retransmissions) and subsequent retransmissions may vary across transmissions. Similarly, for communications using time division duplexing (TDD), the intervals between previous transmissions (or retransmissions) and subsequent retransmission may also vary across transmissions (e.g., for different TDD configurations). As a result, when a transmitting device retransmits information to a receiving device the maximum number of times, the latency associated with the transmissions of the information may or may not exceed a latency budget (e.g., depending on the varying intervals between transmissions), which may be detrimental to a wireless communications system.

As described herein, a wireless communications system may support efficient techniques for dynamically configuring a maximum number of HARQ retransmissions within a latency budget. For example, a transmitting device may determine whether to retransmit information to a receiving device based on a latency budget corresponding to a type of service associated with the data, and the receiving device may determine whether to monitor for a retransmission of the information based on the latency budget. Thus, the maximum number of retransmissions in a HARQ scheme for different types of services may be configured dynamically depending on the latency budget of the different types of services, which may improve the efficiency of the HARQ scheme.

Aspects of the disclosure introduced above are described below in the context of a wireless communications system. Examples of processes and signaling exchanges that support a dynamic termination of HARQ retransmissions are then described. Aspects of the disclosure are further illustrated by and described with reference to apparatus diagrams, system diagrams, and flowcharts that relate to a dynamic termination of HARQ retransmissions.

<FIG> illustrates an example of a wireless communications system <NUM> that supports a dynamic termination of HARQ retransmissions in accordance with various aspects of the present disclosure. The wireless communications system <NUM> includes base stations <NUM>, UEs <NUM>, and a core network <NUM>. In some examples, the wireless communications system <NUM> may be a Long Term Evolution (LTE) network, an LTE-Advanced (LTE-A) network, or a New Radio (NR) network. In some cases, wireless communications system <NUM> may support various types of services, including services for enhanced mobile broadband (eMBB) communications, ultra-reliable (e.g., mission critical) communications, low latency communications, ultra-reliable low latency communications (URLLC), or communications with low-cost and low-complexity devices.

The wireless communications system <NUM> may include, for example, a heterogeneous LTE/LTE-A or NR network in which different types of base stations <NUM> provide coverage for various geographic coverage areas <NUM>.

The term "cell" refers to a logical communication entity used for communication with a base station <NUM> (e.g., over a carrier), and may be associated with an identifier for distinguishing neighboring cells (e.g., a physical cell identifier (PCID), a virtual cell identifier (VCID), etc.) operating via the same or a different carrier. In some examples, a carrier may support multiple cells, and different cells may be configured according to different protocol types (e.g., machine-type communication (MTC), narrowband Internet-of-Things (NB-IoT), eMBB, or others) that may provide access for different types of devices.

A UE <NUM> may also be referred to as a mobile device, a wireless device, a remote device, a handheld device, a subscriber device, or some other suitable terminology, where the "device" may also be referred to as a unit, a station, a terminal, or a client.

Some UEs <NUM> may be designed to collect information or enable an automated behavior of machines.

In some cases, wireless communications system <NUM> may be a packet-based network that operates according to a layered protocol stack. A Radio Link Control (RLC) layer may, in some cases, perform packet segmentation and reassembly to communicate over logical channels. The MAC layer may also use HARQ to provide retransmission at the MAC layer to improve link efficiency. In the control plane, the RRC protocol layer may provide establishment, configuration, and maintenance of an RRC connection between a UE <NUM> and a base station <NUM> or core network <NUM> supporting radio bearers for user plane data.

HARQ feedback may include the transmission of an acknowledgement (ACK) from a receiving device to indicate that data (or other information) received from the transmitting device was successfully decoded, and the transmission of a negative acknowledgement (NACK) from a receiving device to indicate that the receiving device failed to successfully decode the data (or other information) received from the transmitting device.

In HARQ, when a transmitting device determines that a receiving device failed to successfully decode information transmitted to the receiving device, the transmitting device may retransmit the information to the receiving device. In some cases, the information may be associated with a type of service (e.g., a low latency service), and the type of service may be associated with a block error rate (BLER) target (e.g., <NUM>-<NUM> or <NUM>-<NUM>) and a latency budget (e.g., <NUM> or <NUM>). The BLER target may correspond to a reliability target for the information, and the latency budget may correspond to a time period during which transmissions can be used by a receiving device. In some cases, to satisfy the BLER target, it may be appropriate for a transmitting device to retransmit information to a receiving device multiple times. However, after a certain number of retransmissions, a latency budget associated with the information being retransmitted may be exceeded, and a receiving device may not be able to use the retransmitted information after the latency budget is exceeded. That is, after a latency budget is exceeded, further retransmissions of the information may be wasteful.

Accordingly, some wireless communications systems may support techniques for configuring a maximum number of HARQ retransmissions for HARQ procedures at transmitting and receiving devices (e.g., for different types of services). Thus, a transmitting device may retransmit information to a receiving device until the transmitting device receives an ACK or until the transmitting device retransmits the information the maximum number of times (e.g., based on receiving one or more NACKs from the receiving device). In some cases, there may be a direct relationship between a maximum number of retransmissions and an amount of time that has elapsed since an original transmission (i.e., latency). That is, as the maximum number of retransmissions is incremented, the amount of time since an original transmission is increased by a constant. This direct relationship between the maximum number of retransmissions and latency may be seen in communications using synchronous HARQ or for communications using FDD where a retransmission interval (i.e., a time interval between retransmissions) may be fixed and the latency may be accurately deduced from the number of retransmissions.

In other cases, however, the relationship between a number of retransmissions and latency may vary. For example, in communications using asynchronous HARQ and different TDD configurations, the retransmission intervals may vary across transmissions. For example, an interval between a first transmission and a second transmission may be different from an interval between the second transmission and a third transmission. Further, the intervals between transmissions may vary across HARQ procedures. For example, an interval between a first transmission and a second transmission in one HARQ procedure may be different from an interval between a first transmission and a second transmission in another HARQ procedure. As a result, the latency associated with a fixed number of retransmissions may be unpredictable.

In such cases, if a fixed maximum number of retransmissions is configured for a particular service, the latency of communications associated with the type of service may or may not exceed the latency budget corresponding to the type of service depending on the intervals between transmissions in a HARQ procedure. If the latency exceeds the latency budget and another retransmission is scheduled (e.g., because the maximum number of retransmissions was not reached), the resources configured for the retransmission may be wasted since the retransmission may not be used by the receiving device. Alternatively, if the latency fails to exceed the latency budget but the maximum number of retransmissions was reached, another retransmission may not be scheduled, and the BLER target may not be satisfied. Wireless communications system <NUM> may support efficient techniques for dynamically configuring a maximum number of retransmissions to improve the chances of satisfying a BLER target and remaining within a latency budget for communications using a HARQ scheme.

<FIG> illustrates an example of a wireless communications system <NUM>-a that supports a dynamic termination of HARQ retransmissions in accordance with various aspects of the present disclosure. Wireless communications system <NUM>-a includes base station <NUM>-a and UE <NUM>-a, which may be examples of the corresponding devices described with reference to <FIG>. Base station <NUM>-a may communicate with UEs <NUM> (including UE <NUM>-a) within coverage area <NUM>-a. For example, base station <NUM>-a may communicate with UE <NUM>-a on resources of a carrier <NUM>-a.

Wireless communications system <NUM>-a may implement aspects of wireless communications system <NUM>. For example, wireless communications system <NUM>-a may support a HARQ scheme for communications between base station <NUM>-a and UE <NUM>-a. In HARQ, when a transmitting device (e.g., base station <NUM>-a or UE <NUM>-a) determines that a receiving device (e.g., base station <NUM>-a or UE <NUM>-a) failed to decode a transmission or retransmission of information, the transmitting device may retransmit the information to the receiving device. In some cases, however, after a certain number of retransmissions, an amount of time that has elapsed since an original transmission may exceed a latency budget, and another retransmission may be unnecessary and wasteful. To increase the efficiency of the HARQ scheme, the transmitting device may use the techniques described herein to determine whether to retransmit information to the receiving device. Similarly, the receiving device may determine whether to monitor for a retransmission of the information using the techniques described herein.

In particular, the transmitting device may determine whether to retransmit information to the receiving device based on an absolute latency value corresponding to a type of service associated with the information. Similarly, the receiving device may determine whether to monitor for a retransmission of the information based on the absolute latency value. The absolute latency value may correspond to a latency budget that indicates a duration (e.g., <NUM>, <NUM>, <NUM>, etc.) during which transmissions or retransmissions of data may be used by a receiving device. After this latency budget is exceeded, a receiving device may not be able to use any transmissions or retransmissions of the information. As such, any resources allocated for further transmissions or retransmissions of the information after the latency budget is exceeded may be wasted.

In some cases, base station <NUM>-a and UE <NUM>-a may identify an absolute latency value corresponding to a type of service associated with information to be transmitted or received based on a table that indicates absolute latency values associated with different types of services. The table may be saved at the base station <NUM>-a and UE <NUM>-a or may be otherwise available to the base station <NUM>-a and UE <NUM>-a. In other cases, base station <NUM>-a may have access to the absolute latency values associated with different types of services (e.g., based on the table described above), and base station <NUM>-a may signal the absolute latency values <NUM> corresponding to different types of services to UE <NUM>-a.

In addition, base station <NUM>-a and UE <NUM>-a may also identify orders or redundancy versions to be used in transmissions in a HARQ procedure for different types of services based on a table that indicates redundancy versions associated with different types of services. The table may be saved at the base station <NUM>-a and UE <NUM>-a or may be otherwise available to the base station <NUM>-a and UE <NUM>-a. Alternatively, base station <NUM>-a may have access to the orders of redundancy versions associated with different types of services (e.g., based on the table described above), and base station <NUM>-a may signal the orders of the redundancy versions corresponding to different types of services to UE <NUM>-a (e.g., via RRC signaling).

Once a transmitting device and a receiving device identifies redundancy versions associated with different types of services, these devices may be able to transmit and receive information in a HARQ procedure based on the redundancy versions. In addition, once a transmitting device and a receiving device identifies the absolute latency values associated with different types of services, these devices may be able to determine whether to retransmit information or monitor for a retransmission of the information based on the absolute latency value corresponding to a type of service associated with the information. As an example, a transmitting device may transmit information to a receiving device and may determine that the receiving device failed to successfully decode the information. Thus, the transmitting device may identify an absolute latency value corresponding to a type of service associated with the information, and the transmitting device may determine whether to retransmit the data based on the absolute latency value.

For instance, the transmitting device may identify an amount of time (or an estimate of the amount of time) that has elapsed since an original transmission of the information, and the transmitting device may determine whether to retransmit the information based on whether this amount of time (or the estimate of the amount of time) exceeds the absolute latency value or latency budget. If the transmitting device determines that the amount of time (or the estimate of the amount of time) that has elapsed since the original transmission exceeds the absolute latency value or latency budget, the transmitting device may avoid retransmitting the information to the receiving device. Otherwise, the transmitting device may retransmit the information to the receiving device.

Similarly, a receiving device may identify an amount of time (or an estimate of the amount of time) that has elapsed since an original transmission of the information, and the receiving device may determine whether to monitor for a retransmission of the information based on whether this amount of time (or the estimate of the amount of time) exceeds the absolute latency value or latency budget. If the receiving device determines that the amount of time (or the estimate of the amount of time) that has elapsed since the original transmission exceeds the absolute latency value or latency budget, the receiving device may avoid monitoring or waiting for a retransmission of the information, and the receiving device may pass the corresponding information received in previous transmissions to upper layers for processing. Otherwise, the receiving device may monitor or wait for a retransmission of the information from the transmitting device.

<FIG> illustrates an example of a wireless communications system <NUM>-b that supports a dynamic termination of HARQ retransmissions in accordance with various aspects of the present disclosure. Wireless communications system <NUM>-b includes base station <NUM>-b and UE <NUM>-b, which may be examples of the corresponding devices described with reference to <FIG>. Base station <NUM>-b may communicate with UEs <NUM> (including UE <NUM>-b) within coverage area <NUM>-b. For example, base station <NUM>-b may communicate with UE <NUM>-b on resources of a carrier <NUM>-b. In some cases, base station <NUM>-b may transmit DCI <NUM> to UE <NUM>-b within a physical downlink control channel (PDCCH) <NUM>. The DCI <NUM> may be used to schedule a downlink transmission of data in a physical downlink shared channel (PDSCH) <NUM> or an uplink transmission of data in a physical uplink shared channel (PUSCH) <NUM>.

Wireless communications system <NUM>-b may implement aspects of wireless communications system <NUM>. For example, wireless communications system <NUM>-b may support a HARQ scheme for communications between base station <NUM>-b and UE <NUM>-b. In HARQ, when a transmitting device (e.g., base station <NUM>-b or UE <NUM>-b) determines that a receiving device (e.g., base station <NUM>-b or UE <NUM>-b) failed to decode a transmission or retransmission of information, the transmitting device may retransmit the information to the receiving device. In some cases, however, after a certain number of retransmissions, an amount of time that has elapsed since an original transmission may exceed a latency budget, and another retransmission may be unnecessary and wasteful. To increase the efficiency of the HARQ scheme, the transmitting device may use the techniques described herein to determine whether to retransmit the information to the receiving device. Similarly, the receiving device may determine whether to monitor for a retransmission of the information using the techniques described herein.

Base station <NUM>-b may schedule an uplink or downlink transmission of information using DCI <NUM>. Base station <NUM>-b may then determine whether a subsequent retransmission of information (i.e., after the scheduled transmission) would cause the latency of the transmissions of the information to exceed a latency budget. If base station <NUM>-b determines that the latency of the transmissions of the information would fail to exceed the latency budget after the subsequent retransmission, base station <NUM>-b may transmit an indication in DCI <NUM> that the scheduled uplink or downlink transmission is not a final transmission of the information. However, if base station <NUM>-b determines that the latency of the transmissions of the information would exceed the latency budget after the subsequent retransmission, base station <NUM>-b may transmit an indication in DCI <NUM> that the scheduled uplink or downlink transmission is a final transmission of the information.

For uplink communications, if base station <NUM>-b indicates that a scheduled uplink transmission of information is a final transmission of the information, UE <NUM>-b may transmit the information in the scheduled uplink transmission to base station <NUM>-b and base station <NUM>-b may avoid scheduling the UE <NUM>-b for a retransmission of the information. As such, base station <NUM>-b may process the information received in the transmission and in previous transmissions, and base station <NUM>-b may avoid monitoring or waiting for a retransmission of the information. For downlink communications, if base station <NUM>-b indicates that a scheduled downlink transmission of information is a final transmission of the information, base station <NUM>-b may transmit the information in the scheduled downlink transmission to UE <NUM>-b, and base station <NUM>-b may avoid scheduling a retransmission of the information. As such, UE <NUM>-b may determine that the received transmission is a final transmission of the information, process the information received in the transmission and in previous transmissions, and avoid monitoring or waiting for a retransmission of the information.

In some cases, if a latency budget corresponding to a type of service associated with information to be transmitted allows for a single transmission of the information, base station <NUM>-b may allocate resources for the single transmission based on a BLER target associated with the type of service. In one example, if a first number of resources available for the single transmission is greater than a second number of resources to be used to satisfy the BLER target, base station <NUM>-b may allocate the second number of resources for the single transmission such that the BLER target may be satisfied. In another example, if a first number of resources available for the single transmission is less than a second number of resources to be used to satisfy the BLER target, base station <NUM>-b may allocate the first number of resources (i.e., all the available resources) for the single transmission (e.g., when the single transmission is prioritized over other transmissions for which resources may be allocated). In yet another example, if a first number of resources available for the single transmission is less than a second number of resources to be used to satisfy the BLER target, base station <NUM>-b may allocate less resources than the first number of resources (e.g., less resources than the available resources or no resources) for the single transmission (e.g., when other transmissions for which resources may be allocated are prioritized over the single transmission). In each of the three examples described above, the base station <NUM>-b may indicate that the single transmission is the final transmission of the information in DCI <NUM>.

<FIG> illustrates an example of a process flow <NUM> that supports a dynamic termination of HARQ retransmissions in accordance with various aspects of the present disclosure. Process flow <NUM> illustrates aspects of techniques performed by base station <NUM>-c, which may be an example of a base station <NUM> described with reference to <FIG> and <FIG>. Process flow <NUM> also illustrates aspects of techniques performed by a UE <NUM>-c, which may be an example of a UE <NUM> described with reference to <FIG> and <FIG>.

At <NUM>, base station <NUM>-c may transmit RRC signaling to UE <NUM>-c to configure UE <NUM>-c for communications with the base station <NUM>-c (e.g., to provide configurations for control and data channels). In some cases, the RRC signaling may indicate absolute latency values corresponding to different types of services (e.g., eMBB services, MTC services, and different types of low latency services). At <NUM>, base station <NUM>-c may transmit data to UE <NUM>-c, and UE <NUM>-c may receive the data from base station <NUM>-c. UE <NUM>-c may attempt and fail to decode the data, and, at <NUM>, UE <NUM>-c may transmit a NACK to base station <NUM>-c to indicate that the UE <NUM>-c was not able to successfully decode the data. Thus, in the example of <FIG>, base station <NUM>-c may receive the NACK and determine that UE <NUM>-c failed to decode the data. In other examples, however, base station <NUM>-c may determine that UE <NUM>-c failed to decode the data based on failing to receive HARQ feedback for the data transmitted at <NUM>.

After transmitting the NACK, UE <NUM>-c may use the techniques described herein to determine whether to monitor for a retransmission of the data or to avoid monitoring for the retransmission and pass the data received at <NUM> to higher layers for processing. In particular, at <NUM>, UE <NUM>-c may identify an absolute latency value corresponding to a type of service associated with the data received at <NUM>, and UE <NUM>-c may determine whether to monitor for a retransmission of the data based on the absolute latency value. UE <NUM>-c may identify the absolute latency value corresponding to the type of service based on an indication of the absolute latency value in the RRC signaling received at <NUM> or based on a table (e.g., available to the UE <NUM>-c) that indicates absolute latency values corresponding to different types of services.

If UE <NUM>-c determines that a latency value associated with one or more transmissions of the data (e.g., at <NUM>) has exceeded the absolute latency value, UE <NUM>-c may pass the data received at <NUM> to higher layers for processing and avoid monitoring for the retransmission of the data. But if UE <NUM>-c determines that the latency value associated with the one or more transmissions of the data fails to exceed the absolute latency value, UE <NUM>-c may monitor for the retransmission of the data. The latency value associated with the one or more transmissions of the data may correspond to an amount of time (or an estimate of the amount of time) that has elapsed since the original transmission of the data.

Similarly, after receiving the NACK, base station <NUM>-c may use the techniques described herein to determine whether to retransmit the data or avoid retransmitting the data to UE <NUM>-c. In particular, at <NUM>, base station <NUM>-c may identify an absolute latency value corresponding to a type of service associated with the data transmitted at <NUM>, and base station <NUM>-c may determine whether to retransmit the data based on the absolute latency value. Base station <NUM>-c may identify the absolute latency value corresponding to the type of service based on a table (e.g., available to the base station <NUM>-c) that indicates absolute latency values corresponding to different types of services.

If base station <NUM>-c determines that a latency value associated with one or more transmissions of the data (e.g., at <NUM>) has exceeded the absolute latency value, base station <NUM>-c may avoid retransmitting the data to UE <NUM>-c. But if base station <NUM>-c determines that the latency value associated with the one or more transmissions of the data fails to exceed the absolute latency value, base station <NUM>-c may retransmit the data to UE <NUM>-c. The latency value associated with the one or more transmissions of the data may correspond to an amount of time (or an estimate of the amount of time) that has elapsed since the original transmission of the data.

In some cases, base station <NUM>-c may determine to retransmit the data to UE <NUM>-c, and, at <NUM>, base station <NUM>-c may retransmit the data to UE <NUM>-c. Similarly, UE <NUM>-c may determine to monitor or wait for a retransmission of the data from base station <NUM>-c, and, at <NUM>, UE <NUM>-c may receive the retransmission of the data from base station <NUM>-c. The above techniques may be repeated (e.g., including another retransmission of the data at <NUM>) until a latency (e.g., the latency value) of the transmissions of the data exceeds the latency requirement (e.g., the absolute latency value corresponding to a type of service associated with the data). In such cases, base station <NUM>-c may avoid retransmitting the data to UE <NUM>-c, and UE <NUM>-c may avoid monitoring or waiting for the retransmission.

Because base station <NUM>-c may determine whether to retransmit data to UE <NUM>-c based on the absolute latency value or the latency budget (e.g., rather than a fixed maximum number of retransmissions), the maximum number of retransmissions of the data may be determined dynamically, and base station <NUM>-c may be able to provide a maximum number of retransmissions within a latency budget. Similarly, because UE <NUM>-c may determine whether to monitor or wait for a retransmission of data from base station <NUM>-c based on the absolute latency value or the latency budget (e.g., rather than a fixed maximum number of retransmissions), the maximum number of retransmissions of the data may be determined dynamically, and UE <NUM>-c may be able to receive a maximum number of retransmissions within a latency budget. Thus, the techniques described above may facilitate an efficient use of resources as a maximum number of retransmissions within a latency budget may be provided to attempt to satisfy a BLER target while avoiding unnecessary retransmissions.

Although the techniques described are directed to downlink data transmissions, it is to be understood that the same techniques may be applied for uplink data transmissions. For example, UE <NUM>-c may determine whether to retransmit data to base station <NUM>-c based on an absolute latency value corresponding to a type of service associated with the data, and base station <NUM>-c may determine whether to monitor for a retransmission of the data based on the absolute latency value. As described herein, monitoring for a retransmission of data may include waiting to receive the retransmission of the data to combine (e.g., soft combine) the retransmitted data with previously received data as part of a HARQ procedure.

<FIG> illustrates an example of a process flow <NUM> that supports a dynamic termination of HARQ retransmissions in accordance with various aspects of the present disclosure. Process flow <NUM> illustrates aspects of techniques performed by base station <NUM>-d, which may be an example of a base station <NUM> described with reference to <FIG> and <FIG>. Process flow <NUM> also illustrates aspects of techniques performed by a UE <NUM>-d, which may be an example of a UE <NUM> described with reference to <FIG> and <FIG>.

At <NUM>, base station <NUM>-d may transmit DCI to UE <NUM>-d to schedule the UE <NUM>-d for a downlink transmission of data (e.g., to allocate resources for UE <NUM>-d to monitor for the downlink transmission). In some cases, the DCI may also indicate (e.g., using a single bit) whether the scheduled transmission is a final transmission of the data. For example, a base station <NUM>-d may determine that further retransmissions of the data after the scheduled transmission would cause the base station <NUM>-d to exceed a latency budget. As such, the base station <NUM>-d may determine to avoid further retransmissions of the data, and the base station <NUM>-d may transmit an indication that the scheduled transmission is a final transmission of the data. Otherwise, base station <NUM>-d may transmit an indication that the scheduled transmission is not a final transmission of the data, and the base station <NUM>-a may potentially retransmit the data to UE <NUM>-d.

At <NUM>, base station <NUM>-d may transmit the data to UE <NUM>-d, and UE <NUM>-d may receive the data from base station <NUM>-d. UE <NUM>-d may attempt and fail to decode the data, and, at <NUM>, UE <NUM>-d may transmit a NACK to base station <NUM>-d to indicate that the UE <NUM>-d was not able to successfully decode the data. Thus, in the example of <FIG>, base station <NUM>-d may receive the NACK and determine that UE <NUM>-d failed to decode the data. In other examples, however, base station <NUM>-d may determine that UE <NUM>-d failed to decode the data based on failing to receive HARQ feedback for the data transmitted at <NUM>.

After transmitting the NACK, UE <NUM>-d may use the techniques described herein to determine whether to monitor for a retransmission of the data or to avoid monitoring for the retransmission and pass the data received at <NUM> to higher layers for processing. In particular, at <NUM>, UE <NUM>-d may determine whether the transmission of the data at <NUM> was the final transmission of the data based on the indication in the DCI, and UE <NUM>-d may determine whether to monitor for a retransmission of the data based on the determination. If UE <NUM>-d determines that the DCI indicated that the transmission of the data at <NUM> was the final transmission, UE <NUM>-d may pass the data received at <NUM> to higher layers for processing, and UE <NUM>-d may avoid monitoring for the retransmission. Otherwise, UE <NUM>-d may wait for a retransmission of the data.

In some cases, base station <NUM>-d may determine to retransmit the data to UE <NUM>-d, and, at <NUM>, base station <NUM>-d may retransmit the data to UE <NUM>-d. Similarly, UE <NUM>-d may determine to monitor or wait for a retransmission of the data from base station <NUM>-d, and, at <NUM>, UE <NUM>-d may receive the retransmission of the data from base station <NUM>-d. The above techniques may be repeated (e.g., including another retransmission of the data at <NUM>) until base station <NUM>-d determines that a retransmission of data following a scheduled transmission of the data would exceed a latency budget. In such cases, the base station <NUM>-d may indicate that a scheduled transmission of data is a final transmission of the data. Specifically, the base station <NUM>-c may transmit the indication of whether the scheduled transmission of the data is a final transmission of the data in the DCI used to schedule the transmission.

Because the indication of whether a transmission of data is a final transmission of the data is transmitted in the DCI, the maximum number of retransmissions of the data may be determined dynamically, and base station <NUM>-d may be able to provide a maximum number of retransmissions within a latency budget. For example, base station <NUM>-d may determine whether a retransmission of the data after a scheduled transmission would exceed a latency budget (e.g., based on an estimate of the latency after the retransmission), and base station <NUM>-d may transmit an indication of whether the scheduled transmission is a final transmission based on the determination. Thus, the techniques described above may facilitate an efficient use of resources as a maximum number of retransmissions within a latency budget may be provided to attempt to satisfy a BLER target while avoiding unnecessary retransmissions.

Although the techniques described above are directed to downlink data transmissions, it is to be understood that the same techniques may be applied for uplink data transmissions. For example, UE <NUM>-c may determine whether a scheduled uplink transmission is a final transmission of the data based on an indication in the DCI that schedules the uplink transmission. If the DCI indicates that the scheduled uplink transmission is a final transmission, UE <NUM>-c may avoid retransmitting the data after the scheduled transmission, and base station <NUM>-d may avoid monitoring for the data after the scheduled transmission. As described herein, monitoring for a retransmission of data may include waiting to receive the retransmission of the data to combine (e.g., soft combine) the retransmitted data with previously received data as part of a HARQ procedure.

<FIG> shows a block diagram <NUM> of a wireless device <NUM> that supports a dynamic termination of HARQ retransmissions in accordance with aspects of the present disclosure. Wireless device <NUM> may be an example of aspects of a UE <NUM> as described herein. Wireless device <NUM> may include receiver <NUM>, UE communications manager <NUM>, and transmitter <NUM>. Wireless device <NUM> may also include a processor. Each of these components may be in communication with one another (e.g., via one or more buses).

Receiver <NUM> may receive information such as packets, user data, or control information associated with various information channels (e.g., control channels, data channels, and information related to a dynamic termination of HARQ retransmissions, etc.). Information may be passed on to other components of the device. The receiver <NUM> may be an example of aspects of the transceiver <NUM> described with reference to <FIG>. The receiver <NUM> may utilize a single antenna or a set of antennas.

UE communications manager <NUM> may be an example of aspects of the UE communications manager <NUM> described with reference to <FIG>. UE communications manager <NUM> and/or at least some of its various sub-components may be implemented in hardware, software executed by a processor, firmware, or any combination thereof. If implemented in software executed by a processor, the functions of the UE communications manager <NUM> and/or at least some of its various sub-components may be executed by a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), an field-programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described in the present disclosure.

The UE communications manager <NUM> and/or at least some of its various sub-components may be physically located at various positions, including being distributed such that portions of functions are implemented at different physical locations by one or more physical devices. In some examples, UE communications manager <NUM> and/or at least some of its various sub-components may be a separate and distinct component in accordance with various aspects of the present disclosure. In other examples, UE communications manager <NUM> and/or at least some of its various sub-components may be combined with one or more other hardware components, including but not limited to an I/O component, a transceiver, a network server, another computing device, one or more other components described in the present disclosure, or a combination thereof in accordance with various aspects of the present disclosure.

In some aspects, receiver <NUM> may receive data from a base station, the data associated with a type of service. UE communications manager <NUM> may transmit, to the base station, an indication that decoding of the data was unsuccessful, identify an absolute latency value based on transmitting the indication, the absolute latency value corresponding to the type of service associated with the data, and monitor or avoid monitoring for a retransmission of the data from the base station based on the identified absolute latency value.

In other aspects, transmitter <NUM> may transmit data to a base station, the data associated with a type of service. The UE communications manager <NUM> may determine that the base station failed to successfully decode the data, identify an absolute latency value based on the determining, the absolute latency value corresponding to the type of service that is associated with the data, and retransmit or avoid retransmitting the data to the base station based on the identified absolute latency value.

In yet other aspects, the UE communications manager <NUM> may receive DCI that schedules an uplink or downlink transmission of data and receive, in the DCI, an indication of whether the uplink or downlink transmission is a final transmission of the data. Transmitter <NUM> may then transmit the data in the uplink transmission or receiver <NUM> may receive the data in the downlink transmission based on the DCI.

<FIG> shows a block diagram <NUM> of a wireless device <NUM> that supports dynamic termination of HARQ retransmissions in accordance with aspects of the present disclosure. Wireless device <NUM> may be an example of aspects of a wireless device <NUM> or a UE <NUM> as described with reference to <FIG>. Wireless device <NUM> may include receiver <NUM>, UE communications manager <NUM>, and transmitter <NUM>. Wireless device <NUM> may also include a processor. Each of these components may be in communication with one another (e.g., via one or more buses).

Receiver <NUM> may receive information such as packets, user data, or control information associated with various information channels (e.g., control channels, data channels, and information related to dynamic termination of HARQ retransmissions, etc.). Information may be passed on to other components of the device. The receiver <NUM> may be an example of aspects of the transceiver <NUM> described with reference to <FIG>. The receiver <NUM> may utilize a single antenna or a set of antennas.

UE communications manager <NUM> may be an example of aspects of the UE communications manager <NUM> described with reference to <FIG>. UE communications manager <NUM> may include HARQ manager <NUM>, latency manager <NUM>, and DCI manager <NUM>.

In some aspects, receiver <NUM> may receive data from a base station, the data associated with a type of service. HARQ manager <NUM> may transmit, to the base station, an indication that decoding of the data was unsuccessful. Latency manager <NUM> may identify an absolute latency value based on transmitting the indication, the absolute latency value corresponding to the type of service associated with the data. HARQ manager <NUM> may monitor or avoid monitoring for a retransmission of the data from the base station based on the identified absolute latency value.

In some cases, latency manager <NUM> may receive RRC signaling that indicates the absolute latency value corresponding to the type of service that is associated with the data, where the absolute latency value is identified based on the RRC signaling. In other cases, latency manager <NUM> may identify the absolute latency value based on a table that indicates absolute latency values corresponding to different types of services. In some cases, a maximum number of retransmissions of the data is based on the absolute latency value corresponding to the type of service associated with the data.

In some cases, latency manager <NUM> may determine that a latency value associated with one or more transmissions of the data fails to exceed the absolute latency value. In such cases, HARQ manager <NUM> may monitor for the retransmission of the data from the base station based on the determining. In other cases, latency manager <NUM> may determine that a latency value associated with one or more transmissions of the data has exceeded the absolute latency value. In such cases, HARQ manager <NUM> may avoid monitoring for the retransmission of the data from the base station based on the determining.

In other aspects, transmitter <NUM> may transmit data to a base station, the data associated with a type of service. HARQ manager <NUM> may determine that the base station failed to successfully decode the data. In some cases, determining that the base station failed to successfully decode the data includes receiving, from the base station, an indication that decoding of the data was unsuccessful. Latency manager <NUM> may identify an absolute latency value based on the determining, the absolute latency value corresponding to the type of service that is associated with the data. HARQ manager <NUM> may retransmit or avoid retransmitting the data to the base station based on the identified absolute latency value.

In some cases, latency manager <NUM> may receive RRC signaling that indicates the absolute latency value corresponding to the type of service that is associated with the data, where the absolute latency value is identified based on the RRC signaling. Latency manager <NUM> may identify the absolute latency value based on a table that indicates absolute latency values corresponding to different types of services. In some cases, a maximum number of retransmissions of the data is based on the absolute latency value corresponding to the type of service associated with the data.

In some cases, latency manager <NUM> may determine that a latency value associated with one or more transmissions of the data fails to exceed the absolute latency value. In such cases, HARQ manager <NUM> may retransmit the data to the base station based on the determining. In other cases, latency manager <NUM> may determine that a latency value associated with one or more transmissions of the data has exceeded the absolute latency value. In such cases, HARQ manager <NUM> may avoid retransmitting the data to the base station based on the determining.

In yet other aspects, DCI manager <NUM> may receive DCI that schedules an uplink or downlink transmission of data. DCI manager <NUM> may receive, in the DCI, an indication of whether the uplink or downlink transmission is a final transmission of the data. Transmitter <NUM> may then transmit the data in the uplink transmission or receiver <NUM> may receive the data in the downlink transmission based on the DCI. In some cases, an amount of resources allocated for the uplink transmission or the downlink transmission is based on a BLER target of a type of service associated with the data. In some cases, the amount of resources allocated for the uplink transmission or the downlink transmission is further based on an amount of resources available for the uplink transmission or the downlink transmission.

<FIG> shows a diagram of a system <NUM> including a device <NUM> that supports dynamic termination of HARQ retransmissions in accordance with aspects of the present disclosure. Device <NUM> may be an example of or include the components of wireless device <NUM>, wireless device <NUM>, or a UE <NUM> as described above, e.g., with reference to <FIG> and <FIG>. Device <NUM> may include components for bi-directional voice and data communications including components for transmitting and receiving communications, including UE communications manager <NUM>, processor <NUM>, memory <NUM>, software <NUM>, transceiver <NUM>, antenna <NUM>, and I/O controller <NUM>. These components may be in electronic communication via one or more buses (e.g., bus <NUM>). Device <NUM> may communicate wirelessly with one or more base stations <NUM>.

Processor <NUM> may include an intelligent hardware device, (e.g., a general-purpose processor, a DSP, a central processing unit (CPU), a microcontroller, an ASIC, an FPGA, a programmable logic device, a discrete gate or transistor logic component, a discrete hardware component, or any combination thereof). In some cases, processor <NUM> may be configured to operate a memory array using a memory controller. In other cases, a memory controller may be integrated into processor <NUM>. Processor <NUM> may be configured to execute computer-readable instructions stored in a memory to perform various functions (e.g., functions or tasks supporting dynamic termination of HARQ retransmissions).

Software <NUM> may include code to implement aspects of the present disclosure, including code to support dynamic termination of HARQ retransmissions. Software <NUM> may be stored in a non-transitory computer-readable medium such as system memory or other memory. In some cases, the software <NUM> may not be directly executable by the processor but may cause a computer (e.g., when compiled and executed) to perform functions described herein.

<FIG> shows a block diagram <NUM> of a wireless device <NUM> that supports dynamic termination of HARQ retransmissions in accordance with aspects of the present disclosure. Wireless device <NUM> may be an example of aspects of a base station <NUM> as described herein. Wireless device <NUM> may include receiver <NUM>, base station communications manager <NUM>, and transmitter <NUM>. Wireless device <NUM> may also include a processor. Each of these components may be in communication with one another (e.g., via one or more buses).

Base station communications manager <NUM> may be an example of aspects of the base station communications manager <NUM> described with reference to <FIG>. Base station communications manager <NUM> and/or at least some of its various sub-components may be implemented in hardware, software executed by a processor, firmware, or any combination thereof. If implemented in software executed by a processor, the functions of the base station communications manager <NUM> and/or at least some of its various sub-components may be executed by a general-purpose processor, a DSP, an ASIC, an FPGA or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described in the present disclosure.

The base station communications manager <NUM> and/or at least some of its various sub-components may be physically located at various positions, including being distributed such that portions of functions are implemented at different physical locations by one or more physical devices. In some examples, base station communications manager <NUM> and/or at least some of its various sub-components may be a separate and distinct component in accordance with various aspects of the present disclosure. In other examples, base station communications manager <NUM> and/or at least some of its various sub-components may be combined with one or more other hardware components, including but not limited to an I/O component, a transceiver, a network server, another computing device, one or more other components described in the present disclosure, or a combination thereof in accordance with various aspects of the present disclosure.

In some aspects, receiver <NUM> may receive data from a UE, the data associated with a type of service. Base station communications manager <NUM> may transmit, to the UE, an indication that decoding of the data was unsuccessful, identify an absolute latency value based on transmitting the indication, the absolute latency value corresponding to the type of service associated with the data, and monitor or avoid monitoring for a retransmission of the data from the UE based on the identified absolute latency value.

In other aspects, transmitter <NUM> may transmit data to a UE, the data associated with a type of service. The base station communications manager <NUM> may determine that the UE failed to successfully decode the data, identify an absolute latency value based on the determining, the absolute latency value corresponding to the type of service that is associated with the data, and retransmit or avoid retransmitting the data to the UE based on the identified absolute latency value.

In yet other aspects, the base station communications manager <NUM> may transmit DCI that schedules an uplink or downlink transmission of data and transmit, in the DCI, an indication of whether the uplink or downlink transmission is a final transmission of the data. Transmitter <NUM> may then transmit the data in the downlink transmission or receiver <NUM> may receive the data in the uplink transmission based on the DCI.

<FIG> shows a block diagram <NUM> of a wireless device <NUM> that supports dynamic termination of HARQ retransmissions in accordance with aspects of the present disclosure. Wireless device <NUM> may be an example of aspects of a wireless device <NUM> or a base station <NUM> as described with reference to <FIG>. Wireless device <NUM> may include receiver <NUM>, base station communications manager <NUM>, and transmitter <NUM>. Wireless device <NUM> may also include a processor. Each of these components may be in communication with one another (e.g., via one or more buses).

Base station communications manager <NUM> may be an example of aspects of the base station communications manager <NUM> described with reference to <FIG>. Base station communications manager <NUM> may include HARQ manager <NUM>, latency manager <NUM>, DCI manager <NUM>, and resource allocator <NUM>.

In some aspects, receiver <NUM> may receive data from a UE, the data associated with a type of service. HARQ manager <NUM> may transmit, to the UE, an indication that decoding of the data was unsuccessful. Latency manager <NUM> may identify an absolute latency value based on transmitting the indication, the absolute latency value corresponding to the type of service associated with the data. In some cases, latency manager <NUM> may identify the absolute latency value based on a table that indicates absolute latency values corresponding to different types of services. HARQ manager <NUM> may monitor or avoid monitoring for a retransmission of the data from the UE based on the identified absolute latency value.

In some cases, latency manager <NUM> may determine that a latency value associated with one or more transmissions of the data fails to exceed the absolute latency value. In such cases, HARQ manager <NUM> may monitor for the retransmission of the data from the UE based on the determining. In other cases, latency manager <NUM> may determine that a latency value associated with one or more transmissions of the data has exceeded the absolute latency value. In such cases, HARQ manager <NUM> may avoid monitoring for the retransmission of the data from the UE based on the determining. In some cases, a maximum number of retransmissions of the data is based on the absolute latency value corresponding to the type of service associated with the data.

In other aspects, transmitter <NUM> may transmit data to a UE, the data associated with a type of service. HARQ manager <NUM> may determine that the UE failed to successfully decode the data. In some cases, determining that the UE failed to successfully decode the data includes receiving, from the UE, an indication that decoding of the data was unsuccessful. Latency manager <NUM> may identify an absolute latency value based on the determining, the absolute latency value corresponding to the type of service that is associated with the data. In some cases, latency manager <NUM> may identify the absolute latency value based on a table that indicates absolute latency values corresponding to different types of services. HARQ manager <NUM> may retransmit or avoid retransmitting the data to the UE based on the identified absolute latency value.

In some cases, latency manager <NUM> may determine that a latency value associated with one or more transmissions of the data fails to exceed the absolute latency value. In such cases, HARQ manager <NUM> may retransmit the data to the UE based on the determining. In other cases, latency manager <NUM> may determine that a latency value associated with one or more transmissions of the data has exceeded the absolute latency value. In such cases, HARQ manager <NUM> may avoid retransmitting the data to the UE based on the determining. In some cases, a maximum number of retransmissions of the data is based on the absolute latency value corresponding to the type of service associated with the data.

In yet other aspects, DCI manager <NUM> may transmit DCI that schedules an uplink or downlink transmission of data and transmit, in the DCI, an indication of whether the uplink or downlink transmission is a final transmission of the data. Transmitter <NUM> may then transmit the data in the downlink transmission or receiver <NUM> may receive the data in the uplink transmission based on the DCI.

Resource allocator <NUM> may determine a BLER target of a type of service associated with the data, and resource allocator <NUM> may allocate resources for the final transmission based on the BLER target. In one example, resource allocator <NUM> may identify a first amount of resources to be used for the final transmission to satisfy the BLER target, determine that a second amount of resources available for the final transmission is greater than or equal to the first amount of resources, and allocate the first amount of resources for the final transmission. In another example, resource allocator <NUM> may identify a first amount of resources to be used for the final transmission to satisfy the BLER target, determine that a second amount of resources available for the final transmission is less than the first amount of resources, and allocate the second amount of resources for the final transmission. In yet another example, resource allocator <NUM> may identify a first amount of resources to be used for the final transmission to satisfy the BLER target, determine that a second amount of resources available for the final transmission is less than the first amount of resources, and allocate less resources than the second amount of resources for the final transmission.

<FIG> shows a diagram of a system <NUM> including a device <NUM> that supports dynamic termination of HARQ retransmissions in accordance with aspects of the present disclosure. Device <NUM> may be an example of or include the components of base station <NUM> as described above, e.g., with reference to <FIG>. Device <NUM> may include components for bi-directional voice and data communications including components for transmitting and receiving communications, including base station communications manager <NUM>, processor <NUM>, memory <NUM>, software <NUM>, transceiver <NUM>, antenna <NUM>, network communications manager <NUM>, and inter-station communications manager <NUM>. These components may be in electronic communication via one or more buses (e.g., bus <NUM>). Device <NUM> may communicate wirelessly with one or more UEs <NUM>.

Processor <NUM> may include an intelligent hardware device, (e.g., a general-purpose processor, a DSP, a CPU, a microcontroller, an ASIC, an FPGA, a programmable logic device, a discrete gate or transistor logic component, a discrete hardware component, or any combination thereof). In some cases, processor <NUM> may be configured to operate a memory array using a memory controller. In other cases, a memory controller may be integrated into processor <NUM>. Processor <NUM> may be configured to execute computer-readable instructions stored in a memory to perform various functions (e.g., functions or tasks supporting dynamic termination of HARQ retransmissions).

Inter-station communications manager <NUM> may manage communications with other base station <NUM>, and may include a controller or scheduler for controlling communications with UEs <NUM> in cooperation with other base stations <NUM>. In some examples, inter-station communications manager <NUM> may provide an X2 interface within an Long Term Evolution (LTE)/LTE-A wireless communication network technology to provide communication between base stations <NUM>.

<FIG> shows a flowchart illustrating a method <NUM> for dynamic termination of HARQ retransmissions in accordance with aspects of the present disclosure. The operations of method <NUM> may be implemented by a UE <NUM> or its components as described herein. For example, the operations of method <NUM> may be performed by a UE communications manager as described with reference to <FIG>. In some examples, a UE <NUM> may execute a set of codes to control the functional elements of the device to perform the functions described below. Additionally or alternatively, the UE <NUM> may perform aspects of the functions described below using special-purpose hardware.

At <NUM> the UE <NUM> may receive data at a UE from a base station, the data associated with a type of service. The operations of <NUM> may be performed according to the methods described herein. In certain examples, aspects of the operations of <NUM> may be performed by a receiver as described with reference to <FIG>.

At <NUM> the UE <NUM> may transmit, to the base station, an indication that decoding of the data was unsuccessful. The operations of <NUM> may be performed according to the methods described herein. In certain examples, aspects of the operations of <NUM> may be performed by a HARQ manager as described with reference to <FIG>.

At <NUM> the UE <NUM> may identify an absolute latency value based at least in part on transmitting the indication, the absolute latency value corresponding to the type of service associated with the data. The operations of <NUM> may be performed according to the methods described herein. In certain examples, aspects of the operations of <NUM> may be performed by a latency manager as described with reference to <FIG>.

At <NUM> the UE <NUM> may monitor or avoiding monitoring for a retransmission of the data from the base station based at least in part on the identified absolute latency value. The operations of <NUM> may be performed according to the methods described herein. In certain examples, aspects of the operations of <NUM> may be performed by a HARQ manager as described with reference to <FIG>.

At <NUM> the UE <NUM> may transmit data from a UE to a base station, the data associated with a type of service. The operations of <NUM> may be performed according to the methods described herein. In certain examples, aspects of the operations of <NUM> may be performed by a transmitter as described with reference to <FIG>.

At <NUM> the UE <NUM> may determine that the base station failed to successfully decode the data. The operations of <NUM> may be performed according to the methods described herein. In certain examples, aspects of the operations of <NUM> may be performed by a HARQ manager as described with reference to <FIG>.

At <NUM> the UE <NUM> may identify an absolute latency value based at least in part on the determining, the absolute latency value corresponding to the type of service that is associated with the data. The operations of <NUM> may be performed according to the methods described herein. In certain examples, aspects of the operations of <NUM> may be performed by a latency manager as described with reference to <FIG>.

At <NUM> the UE <NUM> may retransmit or avoiding retransmitting the data to the base station based at least in part on the identified absolute latency value. The operations of <NUM> may be performed according to the methods described herein. In certain examples, aspects of the operations of <NUM> may be performed by a HARQ manager as described with reference to <FIG>.

At <NUM> the UE <NUM> may receive DCI that schedules an uplink or downlink transmission of data. The operations of <NUM> may be performed according to the methods described herein. In certain examples, aspects of the operations of <NUM> may be performed by a DCI manager as described with reference to <FIG>.

At <NUM> the UE <NUM> may receive, in the DCI, an indication of whether the uplink or downlink transmission is a final transmission of the data. The operations of <NUM> may be performed according to the methods described herein. In certain examples, aspects of the operations of <NUM> may be performed by a DCI manager as described with reference to <FIG>.

At <NUM> the UE <NUM> may transmit the data in the uplink transmission or receiving the data in the downlink transmission based at least in part on the DCI. The operations of <NUM> may be performed according to the methods described herein. In certain examples, aspects of the operations of <NUM> may be performed by a transmitter as described with reference to <FIG>.

<FIG> shows a flowchart illustrating a method <NUM> for dynamic termination of HARQ retransmissions in accordance with aspects of the present disclosure. The operations of method <NUM> may be implemented by a base station <NUM> or its components as described herein. For example, the operations of method <NUM> may be performed by a base station communications manager as described with reference to <FIG>. In some examples, a base station <NUM> may execute a set of codes to control the functional elements of the device to perform the functions described below. Additionally or alternatively, the base station <NUM> may perform aspects of the functions described below using special-purpose hardware.

At <NUM> the base station <NUM> may receive data at a base station from a UE, the data associated with a type of service. The operations of <NUM> may be performed according to the methods described herein. In certain examples, aspects of the operations of <NUM> may be performed by a receiver as described with reference to <FIG>.

At <NUM> the base station <NUM> may transmit, to the UE, an indication that decoding of the data was unsuccessful. The operations of <NUM> may be performed according to the methods described herein. In certain examples, aspects of the operations of <NUM> may be performed by a HARQ manager as described with reference to <FIG>.

At <NUM> the base station <NUM> may identify an absolute latency value based at least in part on transmitting the indication, the absolute latency value corresponding to the type of service associated with the data. The operations of <NUM> may be performed according to the methods described herein. In certain examples, aspects of the operations of <NUM> may be performed by a latency manager as described with reference to <FIG>.

At <NUM> the base station <NUM> may monitor or avoiding monitoring for a retransmission of the data from the UE based at least in part on the identified absolute latency value. The operations of <NUM> may be performed according to the methods described herein. In certain examples, aspects of the operations of <NUM> may be performed by a HARQ manager as described with reference to <FIG>.

At <NUM> the base station <NUM> may transmit data from a base station to a UE, the data associated with a type of service. The operations of <NUM> may be performed according to the methods described herein. In certain examples, aspects of the operations of <NUM> may be performed by a transmitter as described with reference to <FIG>.

At <NUM> the base station <NUM> may determine that the UE failed to successfully decode the data. The operations of <NUM> may be performed according to the methods described herein. In certain examples, aspects of the operations of <NUM> may be performed by a HARQ manager as described with reference to <FIG>.

At <NUM> the base station <NUM> may identify an absolute latency value based at least in part on the determining, the absolute latency value corresponding to the type of service that is associated with the data. The operations of <NUM> may be performed according to the methods described herein. In certain examples, aspects of the operations of <NUM> may be performed by a latency manager as described with reference to <FIG>.

At <NUM> the base station <NUM> may retransmit or avoiding retransmitting the data to the UE based at least in part on the identified absolute latency value. The operations of <NUM> may be performed according to the methods described herein. In certain examples, aspects of the operations of <NUM> may be performed by a HARQ manager as described with reference to <FIG>.

At <NUM> the base station <NUM> may transmit DCI that schedules an uplink or downlink transmission of data. The operations of <NUM> may be performed according to the methods described herein. In certain examples, aspects of the operations of <NUM> may be performed by a DCI manager as described with reference to <FIG>.

At <NUM> the base station <NUM> may transmit, in the DCI, an indication of whether the uplink or downlink transmission is a final transmission of the data. The operations of <NUM> may be performed according to the methods described herein. In certain examples, aspects of the operations of <NUM> may be performed by a DCI manager as described with reference to <FIG>.

At <NUM> the base station <NUM> may transmit the data in the downlink transmission or receiving the data in the uplink transmission based at least in part on the DCI. The operations of <NUM> may be performed according to the methods described herein. In certain examples, aspects of the operations of <NUM> may be performed by a transmitter as described with reference to <FIG>.

Claim 1:
A method (<NUM>) for wireless communication performed by a first wireless device, the method comprising:
receiving (<NUM>) data at the first wireless device from a second wireless device, the data associated with a type of service;
transmitting (<NUM>), to the second wireless device, an indication that decoding of the data was unsuccessful;
identifying (<NUM>) an absolute latency value based at least in part on transmitting the indication, the absolute latency value corresponding to the type of service associated with the data;
monitoring or avoiding monitoring (<NUM>) for a retransmission of the data from the second wireless device based at least in part on the identified absolute latency value; and
wherein a maximum number of retransmissions of the data is based at least in part on the absolute latency value corresponding to the type of service associated with the data and on variable retransmission intervals.