WO2019098937A1

WO2019098937A1 - Harq requests and responses

Info

Publication number: WO2019098937A1
Application number: PCT/SE2018/051192
Authority: WO
Inventors: Robert Baldemair; Jung-Fu Cheng; Daniel Larsson
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2017-11-17
Filing date: 2018-11-16
Publication date: 2019-05-23
Anticipated expiration: 2020-05-17

Abstract

Apparatuses and methods are disclosed for hybrid automatic repeat request, HARQ, requests and responses. In one embodiment, a method for a requesting node including signalling to a responding node a request condition indicator, the request condition indicator associated with a configuration of at least one HARQ request condition and the request condition indicator instructing the responding node to prepare and send at least one HARQ acknowledgment/non-acknowledgement, A/N, message according to the at least one HARQ request condition. In one embodiment, a method for a responding node includes receiving a request condition indicator, the request condition indicator associated with a configuration of at least one HARQ, request condition; and based at least in part on the received request condition indicator, preparing and sending at least one HARQ A/N message according to the at least one HARQ request condition.

Description

HARQ REQUESTS AND RESPONSES

TECHNICAL FIELD

Wireless communication and in particular, providing flexible hybrid automatic repeat request acknowledgement/non-acknowledgement (HARQ A/N) message handling.

BACKGROUND

Modern wireless communication systems such as HSPA (High Speed Packet Access (HSPA), Long Term Evolution (LTE) and 5GNew Radio (NR) employ a Hybrid ARQ (Automatic Repeat Request) protocol in their MAC (Medium Access Control) layer. The HARQ protocol is used to enhance transmission reliability.

In the system, a wireless device (WD) is notified by the network of downlink data transmission by the physical downlink control channel (PDCCH). Upon reception of a PDCCH in a particular subframe n , a WD is required to decode the corresponding physical downlink shared channel (PDSCH) and to send

acknowledgement/non-acknowledgment (ACK/NACK) feedback in a subsequent subframe n+k. The ACK/NACK feedback informs the network node, such as an eNodeB, whether the corresponding PDSCH was decoded correctly. When the network node detects an ACK feedback, it can proceed to send new data blocks to the WD. When a NACK is detected by the network node, coded bits corresponding to the original data block will be retransmitted. When the retransmission is based on repetition of previously sent coded bits, it is said to be operating in a Chase combining HARQ protocol. When the retransmission contains coded bits unused in previous transmission attempts, it is said to be operating in an incremental redundancy HARQ protocol.

CBG-based HARQ feedback

In LTE and NR a transport block is segmented into multiple code blocks if the transport block exceeds a certain size. For error detection each code block as well as the transport block have its own cyclic redundancy check (CRC). In LTE the HARQ feedback is based on the decoding status of the transport block, i.e., a single HARQ feedback bit is generated per transport block. NR supports this operation mode. In addition, NR also supports code block group (CBG) HARQ feedback. Here one or multiple code blocks are grouped into a CBG and one HARQ feedback bit is generated for each CBG. This is useful since only a fraction of the transport blocks needs to be retransmitted if only one or few CBG are in error.

In a flexible duplex system without a fixed downlink (DL), i.e., network node to wireless device and uplink (UL), i.e., wireless device to network node, transmission pattern, the network control node (e.g., a gNB in the NR system) determines the DL and UL transmission directions based on the balance of DL and UL traffic the control node sees. In such flexible duplex system, a fixed HARQ ACK/NACK (A/N) feedback timing is not feasible. It may further be difficult for the control node to plan ahead and provide the feedback timings to the controlled nodes (e.g., a WD in the NR system) to send back HARQ A/N feedback.

SUMMARY

Some embodiments advantageously provide methods, systems, and

apparatuses for providing flexible HARQ A/N message handling.

To address the complicated HARQ A/N feedback timing planning, a HARQ A/N feedback request mechanism can be executed after several data transmissions have taken place.

Some embodiments enable a network control node to configure a set of HARQ A/N request conditions. One nonlimiting example of conditions are different ranges of HARQ process identifications (IDs). A nonlimiting example size of the HARQ A/N request condition set is four, which allows efficient signaling using two bits.

With the set of HARQ A/N request conditions, a requesting node can signal to a responding node to prepare and send back HARQ A/N according to the requested conditions. In a first application of the embodiment, a gNB in the NR system can send such request condition indicator to instruct the WD to send HARQ A/N corresponding to a specific range of HARQ process IDs. In a second application of the embodiment, a WD capable of and configured to perform UL transmissions without explicit grants from the gNB (e.g., in an unlicensed band operation mode) can indicate such HARQ A/N request condition indicator after it has transmitted a burst of UL data. According to one aspect, a requesting node configured to communicate with a responding node is provided, the requesting node comprising a radio interface and processing circuitry configured to cause the requesting node to signal to the responding node, a request condition indicator, the request condition indicator associated with a configuration of at least one hybrid automatic repeat request,

HARQ, request condition and the request condition indicator instructing the responding node to prepare and send at least one HARQ acknowledgment/non acknowledgement, A/N, message according to the at least one HARQ request condition. The at least one HARQ A/N message may be sent to the requesting node.

In some embodiments of this aspect, the requesting node is a network node, and the processing circuitry is further configured to communicate the configuration of the at least one HARQ request condition to the responding node. In the embodiments of this aspect where the requesting node is a network node, the radio interface may be configured to communicate a downlink, DL, transmission and the signaling of the request condition indicator may be associated with the DL transmission. The DL transmission may be communicated to the responding node. In some embodiments of this aspect, the requesting node is a wireless device, WD, and the WD is further configured to, e.g. via the radio interface, receive the configuration of the at least one HARQ request condition from the responding node. In the embodiments of this aspect where the requesting node is a wireless device, WD, the radio interface may be configured to communicate an uplink, UL, transmission and the signaling of the request condition indicator may be associated with the UL transmission. The UL transmission may be communicated to the responding node. In some embodiments of this aspect, the at least one HARQ request condition includes a set of HARQ request conditions and the signalled request condition indicator indicates at least one HARQ request condition of the set of HARQ request conditions. In some embodiments of this aspect, the configuration of the at least one HARQ request condition includes at least one range of HARQ process identifiers, IDs, for which the responding node is to prepare and send the at least one HARQ A/N message. In some embodiments of this aspect, the at least one range includes a non-contiguous range of HARQ process IDs for which the responding node is to prepare and send the at least one HARQ A/N message. In some embodiments of this aspect, the at least one range includes a contiguous range HARQ process IDs for which the responding node is to prepare and send the at least one HARQ A/N message. In some embodiments of this aspect, the at least one HARQ request condition includes a request to prepare and send the at least one HARQ A/N message for all HARQ process IDs associated with a communication channel. In some embodiments of this aspect, the at least one HARQ request condition includes a request that no HARQ A/N message is to be prepared and sent for any HARQ process IDs associated with a communication channel. In some embodiments of this aspect, the processing circuitry is configured to at least one of receive and configure the at least one HARQ request condition via at least one of higher layer signaling and radio resource control, RRC, signaling. In some embodiments of this aspect, the radio interface is further configured to receive the at least one HARQ A/N message according to the at least one HARQ request condition. In some embodiments of this aspect, the at least one HARQ A/N message is a HARQ feedback message with a bit length, the bit length based at least in part on a number of HARQ processes or HARQ process IDs satisfying the at least one HARQ request condition indicated by the request condition indicator. In some embodiments of this aspect, the at least one HARQ A/N message is a HARQ feedback message with a bit length, the bit length based at least in part on at least one of a codeword configuration and a code block group, CBG, configuration.

In some embodiments of this aspect, the at least one HARQ A/N message is associated with at least one HARQ process identifier and a predetermined time period and if a communication associated with the at least one HARQ process identifier is not received within the predetermined time period, a HARQ non-acknowledgement is reported for the at least one HARQ process identifier.

According to another aspect, a method performed by a requesting node configured to communicate with a responding node is provided, the method comprising signaling to the responding node, a request condition indicator, the request condition indicator associated with a configuration of at least one hybrid automatic repeat request, HARQ, request condition and the request condition indicator instructing the responding node to prepare and send at least one HARQ

acknowledgment/non-acknowledgement, A/N, message according to the at least one HARQ request condition. The at least one HARQ A/N message may be sent to the requesting node.

In some embodiments of this aspect, the method further comprises the requesting node communicating the configuration of the at least one HARQ request condition to the responding node, the requesting node being a network node. In the embodiments of this aspect where the requesting node is a network node, the method may further comprise communicating a downlink, DL, transmission and the signaling of the request condition indicator may be associated with the DL transmission. The DL transmission may be communicated to the responding node. In some

embodiments of this aspect, the method further comprises the requesting node receiving the configuration of the at least one HARQ request condition from the responding node, the requesting node being a wireless device, WD. In the

embodiments of this aspect where the requesting node is a wireless device, WD, the method may further comprise the requesting node communicating an uplink, UL, transmission, the signaling of the request condition indicator associated with the UL transmission. The UL transmission may be communicated to the responding node. In some embodiments of this aspect, the at least one HARQ request condition includes a set of HARQ request conditions and the signalled request condition indicator indicates at least one HARQ request condition of the set of HARQ request conditions. In some embodiments of this aspect, the configuration of the at least one HARQ request condition includes at least one range of HARQ process identifiers, IDs, for which the responding node is to prepare and send the at least one HARQ A/N message. In some embodiments of this aspect, the at least one range includes a non contiguous range of HARQ process IDs for which the responding node is to prepare and send the at least one HARQ A/N message. In some embodiments of this aspect, the at least one range includes a contiguous range HARQ process IDs for which the responding node is to prepare and send the at least one HARQ A/N message. In some embodiments of this aspect, the at least one HARQ request condition includes a request to prepare and send the at least one HARQ A/N message for all HARQ process IDs associated with a communication channel. In some embodiments of this aspect, the at least one HARQ request condition includes a request that no HARQ A/N message is to be prepared and sent for any HARQ process IDs associated with a communication channel. In some embodiments of this aspect, the configuration of the at least one HARQ request condition is performed by at least one of receiving and configuring the at least one HARQ request condition via at least one of higher layer signaling and radio resource control, RRC, signaling. In some embodiments of this aspect, the method further includes receiving the at least one HARQ A/N message according to the at least one HARQ request condition. In some embodiments of this aspect, the at least one HARQ A/N message is a HARQ feedback message with a bit length, the bit length based at least in part on a number of HARQ processes or HARQ process IDs satisfying the at least one HARQ request condition indicated by the request condition indicator. In some embodiments of this aspect, the at least one HARQ A/N message is a HARQ feedback message with a bit length, the bit length based at least in part on at least one of a codeword configuration and a code block group, CBG, configuration.

According to another aspect, a responding node configured to communicate with a requesting node is provided, the responding node comprising a radio interface and processing circuitry configured to receive a request condition indicator, the request condition indicator associated with a configuration of at least one hybrid automatic repeat request, HARQ, request condition and based at least in part on the received request condition indicator, prepare and send at least one HARQ

acknowledgment/non-acknowledgement, A/N, message according to the at least one HARQ request condition. The request condition indicator may be received from the requesting node, and the at least one HARQ A/N message may be sent to the requesting node.

In some embodiments of this aspect, the radio interface is further configured to receive the configuration of the at least one HARQ request condition from the requesting node, the requesting node being a network node and the responding node being a wireless device, WD. In the embodiments of this aspect where the responding node is a wireless device, WD, the radio interface may be configured to receive a downlink, DL, transmission and the signaling of the request condition indicator may be associated with the DL transmission. The DL

transmission may be received from the requesting node. In some embodiments of this aspect, the responding node is a network node, and the processing circuitry is further configured to communicate the configuration of the at least one HARQ request condition to the requesting node being a wireless device, WD. In the embodiments of this aspect where the responding node is a network node, the request condition indicator may be associated with an uplink, UL, transmission. The UL transmission may be received from the requesting node. In some embodiments of this aspect, the at least one HARQ request condition includes a set of HARQ request conditions and the received request condition indicator indicates at least one HARQ request condition of the set of HARQ request conditions. In some embodiments of this aspect, the configuration of the at least one HARQ request condition includes at least one range of HARQ process identifiers, IDs, for which the responding node is to prepare and send the at least one HARQ A/N message. In some embodiments of this aspect, the at least one range includes a non-contiguous range of HARQ process IDs for which the responding node is to prepare and send the at least one HARQ A/N message. In some embodiments of this aspect, the at least one range includes a contiguous range HARQ process IDs for which the responding node is to prepare and send the at least one HARQ A/N message. In some embodiments of this aspect, the at least one HARQ request condition includes a request to prepare and send the at least one HARQ A/N message for all HARQ process IDs associated with a communication channel. In some embodiments of this aspect, the at least one HARQ request condition includes a request that no HARQ A/N message is to be prepared and sent for any HARQ process IDs associated with a communication channel. In some embodiments of this aspect, the configuration of the at least one HARQ request condition is performed by at least one of receiving and configuring via at least one of higher layer signaling and radio resource control, RRC, signaling. In some embodiments of this aspect, the at least one HARQ A/N message is a HARQ feedback message with a bit length, the bit length based at least in part on a number of HARQ processes or HARQ process IDs satisfying the at least one HARQ request condition indicated by the request condition indicator. In some embodiments of this aspect, the at least one HARQ A/N message is a HARQ feedback message with a bit length, the bit length based at least in part on at least one of a codeword configuration and a code block group, CBG, configuration.

According to another aspect, a method performed by a responding node is provided, the method comprising receiving a request condition indicator, the request condition indicator associated with a configuration of at least one hybrid automatic repeat request, HARQ, request condition; and based at least in part on the received request condition indicator, preparing and sending at least one HARQ

In some embodiments of this aspect, the method further includes receiving the configuration of the at least one HARQ request condition from the requesting node, the requesting node being a network node and the responding node being a wireless device, WD. In the embodiments of this aspect where the responding node is a wireless device, WD, the method may further comprise receiving a downlink, DL, transmission and the request condition indicator may be associated with the DL transmission. The DL transmission may be received from the requesting node. In some embodiments of this aspect where the responding node is a network node, the method may further comprise communicating the configuration of the at least one HARQ request condition to the requesting node being a wireless device, WD. In the embodiments of this aspect where, the responding node is a network node the request condition indicator may be associated with an uplink, UL, transmission. The UL transmission may be received from the requesting node. In some embodiments of this aspect, the at least one HARQ request condition includes a set of HARQ request conditions and the received request condition indicator indicates at least one HARQ request condition of the set of HARQ request conditions. In some embodiments of this aspect, the configuration of the at least one HARQ request condition includes at least one range of HARQ process identifiers, IDs, for which the responding node is to prepare and send the at least one HARQ A/N message. In some embodiments of this aspect, the at least one range includes a non-contiguous range of HARQ process IDs for which the responding node is to prepare and send the at least one HARQ A/N message. In some embodiments of this aspect, the at least one range includes a contiguous range HARQ process IDs for which the responding node is to prepare and send the at least one HARQ A/N message. In some embodiments of this aspect, the at least one HARQ request condition includes a request to prepare and send the at least one HARQ A/N message for all HARQ process IDs associated with a communication channel. In some embodiments of this aspect, the at least one HARQ request condition includes a request that no HARQ A/N message is to be prepared and sent for any HARQ process IDs associated with a communication channel. In some embodiments of this aspect, the configuration of the at least one HARQ request condition is performed by at least one of receiving and configuring via at least one of higher layer signaling and radio resource control, RRC, signaling. In some embodiments of this aspect, the at least one HARQ A/N message is a HARQ feedback message with a bit length, the bit length based at least in part on a number of HARQ processes or HARQ process IDs satisfying the at least one HARQ request condition indicated by the request condition indicator. In some embodiments of this aspect, the at least one HARQ A/N message is a HARQ feedback message with a bit length, the bit length based at least in part on at least one of a codeword configuration and a code block group, CBG, configuration.

In some embodiments of this aspect, the at least one HARQ A/N message is associated with at least one HARQ process identifier and a predetermined time period and if a communication associated with the at least one HARQ process identifier is not received within the predetermined time period, a HARQ non-acknowledgement is reported for the at least one HARQ process identifier. BRIEF DESCRIPTION OF THE DRAWINGS

A more complete understanding of the present embodiments, and the attendant advantages and features thereof, will be more readily understood by reference to the following detailed description when considered in conjunction with the accompanying drawings wherein:

FIG. 1 is a schematic diagram of an exemplary network architecture illustrating a communication system connected via an intermediate network to a host computer according to the principles in the present disclosure;

FIG. 2 is a block diagram of a host computer communicating via a network node with a wireless device over an at least partially wireless connection according to some embodiments of the present disclosure;

FIG. 3 is a block diagram of an alternative embodiment of a host computer according to some embodiments of the present disclosure;

FIG. 4 is a block diagram of an alternative embodiment of a network node according to some embodiments of the present disclosure;

FIG. 5 is a block diagram of an alternative embodiment of a wireless device according to some embodiments of the present disclosure;

FIG. 6 is a flowchart illustrating an exemplary method implemented in a communication system including a host computer, a network node and a wireless device according to some embodiments of the present disclosure;

FIG. 7 is a flowchart illustrating an exemplary method implemented in a communication system including a host computer, a network node and a wireless device according to some embodiments of the present disclosure;

FIG. 8 is a flowchart illustrating an exemplary method implemented in a communication system including a host computer, a network node and a wireless device according to some embodiments of the present disclosure;

FIG. 9 is a flowchart illustrating an exemplary method implemented in a communication system including a host computer, a network node and a wireless device according to some embodiments of the present disclosure;

FIG. 10 is a flowchart of an exemplary process in a transmitting node for configuring HARQ A/N messages according to some embodiments of the present disclosure; FIG. 11 is a flowchart of an exemplary process in a receiving node for configuring HARQ A/N messages according to some embodiments of the present disclosure;

FIG. 12 illustrates an example of a HARQ feedback association according to some embodiments of the present disclosure;

FIG. 13 illustrates an example of feedback for slot- and non-slot-based transmissions multiplexed into the same HARQ codebook according to some embodiments of the present disclosure;

FIG. 14 illustrates an example of feedback for the non-slot-based transmission transmitted separately in a PUCCH resource in the same slot interval according to some embodiments of the present disclosure;

FIG. 15 illustrates an example of an Elapsed Slot Counter (ESC) set to zero in the DCI of the first scheduled DL assignment according to some embodiments of the present disclosure;

FIG. 16 illustrates an example with the WD configured with three component carriers with mixed slot- and non-slot-based transmissions, where, at each PDCCH time, the total DAI is set to the total number of scheduled DL assignments including this PDCCH time according to some embodiments of the present disclosure; and

FIG. 17 illustrates an example with the WD configured with three component carriers with mixed slot- and non-slot-based transmissions, where the total DAI is set predictively to a larger value than the highest counter DAI of the current PDCCH time, and, as a result, the same total value (and especially the last total DAI) is transmitted several times according to some embodiments of the present disclosure.

DETAILED DESCRIPTION

Before describing in detail exemplary embodiments, it is noted that the embodiments reside primarily in combinations of apparatus components and processing steps related to providing flexible HARQ A/N message handling.

Accordingly, components have been represented where appropriate by conventional symbols in the drawings, showing only those specific details that are pertinent to understanding the embodiments so as not to obscure the disclosure with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein. Like numbers refer to like elements throughout the description.

As used herein, relational terms, such as“first” and“second,”“top” and “bottom,” and the like, may be used solely to distinguish one entity or element from another entity or element without necessarily requiring or implying any physical or logical relationship or order between such entities or elements. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the concepts described herein. As used herein, the singular forms“a”,“an” and“the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises,”“comprising,”“includes” and/or“including” when used herein, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

In embodiments described herein, the joining term,“in communication with” and the like, may be used to indicate electrical or data communication, which may be accomplished by physical contact, induction, electromagnetic radiation, radio signaling, infrared signaling or optical signaling, for example. One having ordinary skill in the art will appreciate that multiple components may interoperate and modifications and variations are possible of achieving the electrical and data communication.

In some embodiments described herein, the term“coupled,”“connected,” and the like, may be used herein to indicate a connection, although not necessarily directly, and may include wired and/or a wireless connections.

The term“network node” used herein can be any kind of network node comprised in a radio network which may further comprise any of base station (BS), radio base station, base transceiver station (BTS), base station controller (BSC), radio network controller (RNC), g Node B (gNB), evolved Node B (eNB or eNodeB), Node B, multi-standard radio (MSR) radio node such as MSR BS, multi-cell/multicast coordination entity (MCE), relay node, donor node controlling relay, radio access point (AP), transmission points, transmission nodes, Remote Radio Unit (RRU) Remote Radio Head (RRH), a core network node (e.g., mobile management entity (MME), self-organizing network (SON) node, a coordinating node, positioning node, MDT node, etc.), an external node (e.g., 3rd party node, a node external to the current network), nodes in distributed antenna system (DAS), a spectrum access system (SAS) node, an element management system (EMS), etc. The network node may also comprise test equipment. The term“radio node” used herein may be used to also denote a wireless device (WD) such as a wireless device (WD) or a radio network node.

In some embodiments, the non-limiting terms wireless device (WD) or a user equipment (UE) are used interchangeably. The WD herein can be any type of wireless device capable of communicating with a network node or another WD over radio signals, such as a TIE. The WD may also be a radio communication device, target device, device to device (D2D) WD, machine type WD or WD capable of machine to machine communication (M2M), low-cost and/or low-complexity WD, a sensor equipped with WD, Tablet, mobile terminals, smart phone, laptop embedded equipped (LEE), laptop mounted equipment (LME), ETSB dongles, Customer Premises Equipment (CPE), an Internet of Things (IoT) device, or a Narrowband IoT (NB-IOT) device etc.

Also in some embodiments the generic term“radio network node” is used. It can be any kind of a radio network node which may comprise any of base station, radio base station, base transceiver station, base station controller, network controller, RNC, evolved Node B (eNB), Node B, gNB, Multi-cell/multicast Coordination Entity (MCE), relay node, access point, radio access point, Remote Radio ETnit (RRET) Remote Radio Head (RRH).

Note that although terminology from one particular wireless system, such as, for example, 3GPP LTE, may be used in this disclosure, this should not be seen as limiting the scope of the disclosure to only the aforementioned system. Other wireless systems, including without limitation Wide Band Code Division Multiple Access (WCDMA), Worldwide Interoperability for Microwave Access (WiMax), ETltra Mobile Broadband (EGMB) and Global System for Mobile Communications (GSM), may also benefit from exploiting the ideas covered within this disclosure.

Note further, that functions described herein as being performed by a wireless device or a network node may be distributed over a plurality of wireless devices and/or network nodes. In other words, it is contemplated that the functions of the network node and wireless device described herein are not limited to performance by a single physical device and, in fact, can be distributed among several physical devices.

Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs. It will be further understood that terms used herein should be interpreted as having a meaning that is consistent with their meaning in the context of this specification and the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.

Embodiments provide for configuring HARQ A/N messages by selecting a range of HARQ processes for which HARQ A/N messages are to be sent. Returning to the drawing figures, in which like elements are referred to by like reference designators, there is shown in FIG. 1 a schematic diagram of a communication system, according to an embodiment, including a communication system 10, such as a 3GPP-type cellular network, which comprises an access network 12, such as a radio access network, and a core network 14. The access network 12 comprises a plurality of network nodes l6a, l6b, l6c (referred to collectively as network nodes 16), such as NBs, eNBs, gNBs or other types of wireless access points, each defining a

corresponding coverage area l8a, 18b, l8c (referred to collectively as coverage areas 18). Each network node l6a, l6b, l6c is connectable to the core network 14 over a wired or wireless connection 20. A first wireless device (WD) 22a located in coverage area l8a is configured to wirelessly connect to, or be paged by, the corresponding network node l6c. A second WD 22b in coverage area 18b is wirelessly connectable to the corresponding network node l6a. While a plurality of WDs 22a, 22b

(collectively referred to as wireless devices 22) are illustrated in this example, the disclosed embodiments are equally applicable to a situation where a sole WD is in the coverage area or where a sole WD is connecting to the corresponding network node 16. Note that although only two WDs 22 and three network nodes 16 are shown for convenience, the communication system may include many more WDs 22 and network nodes 16. The communication system 10 may itself be connected to a host computer 24, which may be embodied in the hardware and/or software of a standalone server, a cloud-implemented server, a distributed server or as processing resources in a server farm. The host computer 24 may be under the ownership or control of a service provider, or may be operated by the service provider or on behalf of the service provider. The connections 26, 28 between the communication system 10 and the host computer 24 may extend directly from the core network 14 to the host computer 24 or may extend via an optional intermediate network 30. The intermediate network 30 may be one of, or a combination of more than one of, a public, private or hosted network. The intermediate network 30, if any, may be a backbone network or the Internet. In some embodiments, the intermediate network 30 may comprise two or more sub-networks (not shown).

The communication system of FIG. 1 as a whole enables connectivity between one of the connected WDs 22a, 22b and the host computer 24. The connectivity may be described as an over-the-top (OTT) connection. The host computer 24 and the connected WDs 22a, 22b are configured to communicate data and/or signaling via the OTT connection, using the access network 12, the core network 14, any intermediate network 30 and possible further infrastructure (not shown) as intermediaries. The OTT connection may be transparent in the sense that at least some of the participating communication devices through which the OTT connection passes are unaware of routing of uplink and downlink communications. For example, a network node 16 may not or need not be informed about the past routing of an incoming downlink communication with data originating from a host computer 24 to be forwarded (e.g., handed over) to a connected WD 22a. Similarly, the network node 16 need not be aware of the future routing of an outgoing uplink communication originating from the WD 22a towards the host computer 24.

A network node 16 is configured to include a request configuration unit 32 which is configured to configure at least one HARQ A/N request condition. In one embodiment, the request configuration unit 32 is configured to signal to the responding node (e.g., WD 22), a request condition indicator, the request condition indicator associated with a configuration of at least one hybrid automatic repeat request, HARQ, request condition and the request condition indicator instructing the responding node to prepare and send at least one HARQ acknowledgment/non acknowledgement, A/N, message according to the at least one HARQ request condition.

A wireless device 22 is also configured to include a request configuration unit 34 which is configured according to the at least one HARQ A/N request condition. In one embodiment, the request configuration unit 34 is configured to receive a request condition indicator, the request condition indicator associated with a configuration of at least one hybrid automatic repeat request, HARQ, request condition; and based at least in part on the received request condition indicator, prepare and send at least one HARQ acknowledgment/non-acknowledgement, A/N, message according to the at least one HARQ request condition.

Example implementations, in accordance with an embodiment, of the WD 22, network node 18 and host computer 24 discussed in the preceding paragraphs will now be described with reference to FIG. 2. In a communication system 10, a host computer 24 comprises hardware (HW) 38 including a communication interface 40 configured to set up and maintain a wired or wireless connection with an interface of a different communication device of the communication system 10. The host computer 24 further comprises processing circuitry 42, which may have storage and/or processing capabilities. The processing circuitry 42 may include a processor 44 and memory 46. In particular, in addition to a traditional processor and memory, the processing circuitry 42 may comprise integrated circuitry for processing and/or control, e.g., one or more processors and/or processor cores and/or FPGAs (Field Programmable Gate Array) and/or ASICs (Application Specific Integrated Circuitry) adapted to execute instructions. The processor 44 may be configured to access (e.g., write to and/or read from) memory 46, which may comprise any kind of volatile and/or nonvolatile memory, e.g., cache and/or buffer memory and/or RAM (Random Access Memory) and/or ROM (Read-Only Memory) and/or optical memory and/or EPROM (Erasable Programmable Read-Only Memory).

Processing circuitry 42 may be configured to control any of the methods and/or processes described herein and/or to cause such methods, and/or processes to be performed, e.g., by host computer 24. Processor 44 corresponds to one or more processors 44 for performing host computer 24 functions described herein. The host computer 24 includes memory 46 that is configured to store data, programmatic software code and/or other information described herein. In some embodiments, the software 48 and/or the host application 50 may include instructions that, when executed by the processor 44 and/or processing circuitry 42, causes the processor 44 and/or processing circuitry 42 to perform the processes described herein with respect to host computer 24. The instructions may be software associated with the host computer 24.

The software 48 may be executable by the processing circuitry 42. The software 48 includes a host application 50. The host application 50 may be operable to provide a service to a remote user, such as a WD 22 connecting via an OTT connection 52 terminating at the WD 22 and the host computer 24. In providing the service to the remote user, the host application 50 may provide user data which is transmitted using the OTT connection 52. In one embodiment, the host computer 24 may be configured for providing control and functionality to a service provider and may be operated by the service provider or on behalf of the service provider. The processing circuitry 42 of the host computer 24 may configure the host computer 24 to enable the service provider to observe, monitor, control, transmit data to and/or receive data from the network node 16 and or the wireless device 22.

The communication system 10 further includes a network node 16 provided in a communication system 10 and comprising hardware 58 enabling it to communicate with the host computer 24 and with the WD 22. The hardware 58 may include a communication interface 60 for setting up and maintaining a wired or wireless connection with an interface of a different communication device of the

communication system 10, as well as a radio interface 62 for setting up and maintaining at least a wireless connection 64 with a WD 22 located in a coverage area 18 served by the network node 16. The radio interface 62 may be formed as or may include, for example, one or more RF transmitters, one or more RF receivers, and/or one or more RF transceivers. The communication interface 60 may be configured to facilitate a connection 66 to the host computer 24. The connection 66 may be direct or it may pass through a core network 14 of the communication system 10 and/or through one or more intermediate networks 30 outside the communication system 10. In the embodiment shown, the hardware 58 of the network node 16 further includes processing circuitry 68. The processing circuitry 68 may include a processor 70 and a memory 72. In particular, in addition to a traditional processor and memory, the processing circuitry 68 may comprise integrated circuitry for processing and/or control, e.g., one or more processors and/or processor cores and/or FPGAs (Field Programmable Gate Array) and/or ASICs (Application Specific Integrated Circuitry) adapted to execute instructions. The processor 70 may be configured to access (e.g., write to and/or read from) the memory 72, which may comprise any kind of volatile and/or nonvolatile memory, e.g., cache and/or buffer memory and/or RAM (Random Access Memory) and/or ROM (Read-Only Memory) and/or optical memory and/or EPROM (Erasable Programmable Read-Only Memory).

Thus, the network node 16 further has software 74 stored internally in, for example, memory 72, or stored in external memory (e.g., database) accessible by the network node 16 via an external connection. The software 74 may be executable by the processing circuitry 68. The processing circuitry 68 may be configured to control any of the methods and/or processes described herein and/or to cause such methods, and/or processes to be performed, e.g., by network node 16. Processor 70

corresponds to one or more processors 70 for performing network node 16 functions described herein The memory 72 is configured to store data, programmatic software code and/or other information described herein. In some embodiments, the software 74 may include instructions that, when executed by the processor 70 and/or processing circuitry 68, causes the processor 70 and/or processing circuitry 68 to perform the processes described herein with respect to network node 16. For example, processing circuitry 68 of the network node 16 may include request configuration unit 32 configured to configure the at least one HARQ A/N request condition. The radio interface 62 is configured to signal to a wireless device a request condition indicator to instruct the wireless device to prepare and send HARQ A/N messages according to at least one request condition.

The communication system 10 further includes the WD 22 already referred to. The WD 22 may have hardware 80 that may include a radio interface 82 configured to set up and maintain a wireless connection 64 with a network node 16 serving a coverage area 18 in which the WD 22 is currently located. The radio interface 82 may be formed as or may include, for example, one or more RF transmitters, one or more RF receivers, and/or one or more RF transceivers.

The hardware 80 of the WD 22 further includes processing circuitry 84. The processing circuitry 84 may include a processor 86 and memory 88. In particular, in addition to a traditional processor and memory, the processing circuitry 84 may comprise integrated circuitry for processing and/or control, e.g., one or more processors and/or processor cores and/or FPGAs (Field Programmable Gate Array) and/or ASICs (Application Specific Integrated Circuitry) adapted to execute instructions. The processor 86 may be configured to access (e.g., write to and/or read from) memory 88, which may comprise any kind of volatile and/or nonvolatile memory, e.g., cache and/or buffer memory and/or RAM (Random Access Memory) and/or ROM (Read-Only Memory) and/or optical memory and/or EPROM (Erasable Programmable Read-Only Memory).

Thus, the WD 22 may further comprise software 90, which is stored in, for example, memory 88 at the WD 22, or stored in external memory (e.g., database) accessible by the WD 22. The software 90 may be executable by the processing circuitry 84. The software 90 may include a client application 92. The client application 92 may be operable to provide a service to a human or non-human user via the WD 22, with the support of the host computer 24. In the host computer 24, an executing host application 50 may communicate with the executing client application 92 via the OTT connection 52 terminating at the WD 22 and the host computer 24. In providing the service to the user, the client application 92 may receive request data from the host application 50 and provide user data in response to the request data. The OTT connection 52 may transfer both the request data and the user data. The client application 92 may interact with the user to generate the user data that it provides.

The processing circuitry 84 may be configured to control any of the methods and/or processes described herein and/or to cause such methods, and/or processes to be performed, e.g., by WD 22. The processor 86 corresponds to one or more processors 86 for performing WD 22 functions described herein. The WD 22 includes memory 88 that is configured to store data, programmatic software code and/or other information described herein. In some embodiments, the software 90 and/or the client application 92 may include instructions that, when executed by the processor 86 and/or processing circuitry 84, causes the processor 86 and/or processing circuitry 84 to perform the processes described herein with respect to WD 22. For example, the processing circuitry 84 of the wireless device 22 may include a request configuration unit 34 configured to configure the at least one HARQ A/N request condition. The radio interface 82 is configured to receive a request condition indicator from a network node instructing the wireless device to prepare and return HARQ A/N messages according to a request condition and to send the HARQ A/N messages according to the request condition.

Having described some of the hardware that may perform by a WD 22 and/or a network node 16 according to the techniques and functions discussed herein, some embodiments for a requesting node and a responding node are described, which may be performed by either or both of the WD 22 and/or the network node 16 depending, for example, on whether the HARQ is requested by a network node 16 for a downlink, DL, communication (communications from the network node 16 to the WD 22) or whether the HARQ is requested by a WD 22 for an uplink, UL, communication (communications from the WD 22 to the network node 16, e.g., unlicensed band embodiments with grant-free UL transmissions).

In some embodiments, one or both of the network node 16 and/or WD 22 may be configured as a requesting node. In such embodiments, the requesting node (e.g., network node 16 and/or WD 22) is configured to communicate with a responding node (e.g., network node 16 and/or WD 22), the requesting node (e.g., network node and/or WD 22) comprising a radio interface (e.g., radio interface 62 or 82) and processing circuitry (e.g., processing circuitry 68 or 84) configured to cause the requesting node (e.g., network node 16 and/or WD 22) to signal to the responding node (e.g., network node 16 and/or WD 22), a request condition indicator, the request condition indicator associated with a configuration of at least one hybrid automatic repeat request, HARQ, request condition and the request condition indicator instructing the responding node (e.g., network node 16 and/or WD 22) to prepare and send at least one HARQ acknowledgment/non-acknowledgement, A/N, message according to the at least one HARQ request condition. The at least one HARQ A/N message may be sent to the requesting node. In some embodiments, the requesting node is a network node 16, and the processing circuitry 68 is further configured to communicate the configuration of the at least one HARQ request condition to the responding node (e.g., WD 22). In the embodiments of this aspect where the requesting node is a network node, the radio interface may be configured to communicate a downlink, DL, transmission and the signaling of the request condition indicator may be associated with the DL

transmission. The DL transmission may be communicated to the responding node. In some embodiments of this aspect, the requesting node is a wireless device, WD, and the WD is further configured to, e.g. via the radio interface, receive the configuration of the at least one HARQ request condition from the responding node.

In some embodiments, the requesting node is a wireless device, WD 22, and the radio interface 82 is configured to communicate an uplink, UL, transmission, the signaling of the request condition indicator associated with the UL transmission. The UL transmission may be communicated to the responding node.

In some embodiments, the at least one HARQ request condition includes a set of HARQ request conditions and the signalled request condition indicator indicates at least one HARQ request condition of the set of HARQ request conditions. In some embodiments, the configuration of the at least one HARQ request condition includes at least one range of HARQ process identifiers, IDs, for which the responding node is to prepare and send the at least one HARQ A/N message. In some embodiments, the at least one range includes a non-contiguous range of HARQ process IDs for which the responding node is to prepare and send the at least one HARQ A/N message. In some embodiments, the at least one range includes a contiguous range HARQ process IDs for which the responding node is to prepare and send the at least one HARQ A/N message. In some embodiments, the at least one HARQ request condition includes a request to prepare and send the at least one HARQ A/N message for all HARQ process identifiers, IDs, associated with a communication channel. In some embodiments, the at least one HARQ request condition includes a request that no HARQ A/N message is to be prepared and sent for any HARQ process identifiers,

IDs, associated with a communication channel. In some embodiments, the processing circuitry (e.g., processing circuitry 68 or 84) is configured to at least one of receive and configure the at least one HARQ request condition via at least one of higher layer signaling and radio resource control, RRC, signaling. In some embodiments, the radio interface (e.g., radio interface 62 or 82) is further configured to receive the at least one HARQ A/N message according to the at least one HARQ request condition. In some embodiments, the at least one HARQ A/N message is a HARQ feedback message with a bit length, the bit length based at least in part on a number of HARQ processes identifiers, IDs, satisfying the at least one HARQ request condition indicated by the request condition indicator. In some embodiments, the at least one HARQ A/N message is a HARQ feedback message with a bit length, the bit length based at least in part on at least one of a codeword configuration and a code block group, CBG, configuration.

In some embodiments, the at least one HARQ A/N message is associated with at least one HARQ process identifier and a predetermined time period and if a communication associated with the at least one HARQ process identifier is not received within the predetermined time period, a HARQ non-acknowledgement is reported e.g., in the at least one HARQ A/N message for the at least one HARQ process identifier.

In some embodiments, one or both of the network node 16 and/or WD 22 may be configured as a responding node (e.g., responding to a HARQ request). In such embodiments, the responding node (e.g., network node 16 and/or WD 22) is configured to communicate with a requesting node (e.g., network node 16 and/or WD 22), the responding node (e.g., network node 16 and/or WD 22) comprising a radio interface (e.g. radio interface 62 or 82) and processing circuitry (e.g., processing circuitry 68 or 84) configured to receive a request condition indicator, the request condition indicator associated with a configuration of at least one hybrid automatic repeat request, HARQ, request condition; and based at least in part on the received request condition indicator, prepare and send at least one HARQ

In some embodiments, the radio interface (e.g., radio interface 62 or 82) is further configured to receive the configuration of the at least one HARQ request condition from the requesting node (e.g., network node 16 and/or WD 22), the requesting node being a network node 16 and the responding node being a wireless device, WD 22. In the embodiments of this aspect where the responding node is a wireless device, WD, 22 the radio interface may be configured to receive a downlink, DL, transmission and the signaling of the request condition indicator may be associated with the DL transmission. The DL transmission may be received from the requesting node, e.g. the network node 16. In some embodiments of this aspect, the responding node is a network node 16, and the processing circuitry 68 is further configured to communicate the configuration of the at least one HARQ request condition to the requesting node being a wireless device, WD 22.

In some embodiments, the responding node is a network node 16 and the request condition indicator is associated with an uplink, UL, transmission. The UL transmission may be received from the requesting node, e.g. the WD 22.

In some embodiments, the at least one HARQ request condition includes a set of HARQ request conditions and the received request condition indicator indicates at least one HARQ request condition of the set of HARQ request conditions. In some embodiments, the configuration of the at least one HARQ request condition includes at least one range of HARQ process identifiers, IDs, for which the responding node (e.g., network node 16 and/or WD 22) is to prepare and send the at least one HARQ A/N message. In some embodiments, the at least one range includes a non contiguous range of HARQ process IDs for which the responding node (e.g., network node 16 and/or WD 22) is to prepare and send the at least one HARQ A/N message. In some embodiments, the at least one range includes a contiguous range HARQ process IDs for which the responding node (e.g., network node 16 and/or WD 22) is to prepare and send the at least one HARQ A/N message. In some embodiments, the at least one HARQ request condition includes a request to prepare and send the at least one HARQ A/N message for all HARQ process identifiers, IDs, associated with a communication channel. In some embodiments, the at least one HARQ request condition includes a request that no HARQ A/N message is to be prepared and sent for any HARQ process identifiers, IDs, associated with a communication channel. In some embodiments, the configuration of the at least one HARQ request condition is performed by at least one of receiving and configuring via at least one of higher layer signaling and radio resource control, RRC, signaling. In some embodiments, the at least one HARQ A/N message is a HARQ feedback message with a bit length, the bit length based at least in part on a number of HARQ processes identifiers, IDs, satisfying the at least one HARQ request condition indicated by the request condition indicator. In some embodiments, the at least one HARQ A/N message is a HARQ feedback message with a bit length, the bit length based at least in part on at least one of a codeword configuration and a code block group, CBG, configuration.

In some embodiments, the at least one HARQ A/N message is associated with at least one HARQ process identifier and a predetermined time period and if a communication associated with the at least one HARQ process identifier is not received within the predetermined time period, a HARQ non-acknowledgement is reported e.g. in the at least one HARQ A/N message for the at least one HARQ process identifier.

In some embodiments, the inner workings of the network node 16, WD 22, and host computer 24 may be as shown in FIG. 2 and independently, the surrounding network topology may be that of FIG. 1.

In FIG. 2, the OTT connection 52 has been drawn abstractly to illustrate the communication between the host computer 24 and the wireless device 22 via the network node 16, without explicit reference to any intermediary devices and the precise routing of messages via these devices. Network infrastructure may determine the routing, which it may be configured to hide from the WD 22 or from the service provider operating the host computer 24, or both. While the OTT connection 52 is active, the network infrastructure may further take decisions by which it dynamically changes the routing (e.g., on the basis of load balancing consideration or

reconfiguration of the network).

The wireless connection 64 between the WD 22 and the network node 16 is in accordance with the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of OTT services provided to the WD 22 using the OTT connection 52, in which the wireless connection 64 may form the last segment. More precisely, the teachings of some of these embodiments may improve the data rate, latency, and/or power consumption and thereby provide benefits such as reduced user waiting time, relaxed restriction on file size, better responsiveness, extended battery lifetime, etc.

In some embodiments, a measurement procedure may be provided for the purpose of monitoring data rate, latency and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring the OTT connection 52 between the host computer 24 and WD 22, in response to variations in the measurement results. The measurement procedure and/or the network functionality for reconfiguring the OTT connection 52 may be implemented in the software 48 of the host computer 24 or in the software 90 of the WD 22, or both. In embodiments, sensors (not shown) may be deployed in or in association with communication devices through which the OTT connection 52 passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which software 48, 90 may compute or estimate the monitored quantities. The reconfiguring of the OTT connection 52 may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not affect the network node 16, and it may be unknown or imperceptible to the network node 16. Some such procedures and functionalities may be known and practiced in the art. In certain embodiments, measurements may involve proprietary WD signaling facilitating the host computer’s 24 measurements of throughput, propagation times, latency and the like. In some embodiments, the measurements may be implemented in that the software 48, 90 causes messages to be transmitted, in particular empty or ‘dummy’ messages, using the OTT connection 52 while it monitors propagation times, errors, etc.

Although FIGS. 1 and 2 show various“units” such as request configuration unit 32 and request configuration unit 34 as being within a respective processor, it is contemplated that these units may be implemented such that a portion of the unit is stored in a corresponding memory within the processing circuitry. In other words, the units may be implemented in hardware or in a combination of hardware and software within the processing circuitry.

FIG. 3 is a block diagram of an alternative host computer 24, which may be implemented at least in part by software modules containing software executable by a processor to perform the functions described herein. The host computer 24 includes a communication interface module 94 configured to set up and maintain a wired or wireless connection with an interface of a different communication device of the communication system 10. The memory module 95 is configured to store data, programmatic software code and/or other information described herein.

FIG. 4 is a block diagram of an alternative network node 16, which may be implemented at least in part by software modules containing software executable by a processor to perform the functions described herein. The network node 16 includes a radio interface module 96 configured for setting up and maintaining at least a wireless connection 64 with a WD 22 located in a coverage area 18 served by the network node 16. The network node 16 also includes a communication interface module 97 configured for setting up and maintaining a wired or wireless connection with an interface of a different communication device of the communication system 10. The communication interface module 97 may also be configured to facilitate a connection 66 to the host computer 24. The memory module 98 that is configured to store data, programmatic software code and/or other information described herein. The request configuration module 99 configured to configure the at least one HARQ A/N request condition. The radio interface module 96 is configured to signal to a wireless device a request condition indicator to instruct the wireless device to prepare and send HARQ A/N messages according to at least one request condition.

FIG. 5 is a block diagram of an alternative wireless device 22, which may be implemented at least in part by software modules containing software executable by a processor to perform the functions described herein. The WD 22 includes a radio interface module 100 configured to set up and maintain a wireless connection 64 with a network node 16 serving a coverage area 18 in which the WD 22 is currently located. The memory module 101 is configured to store data, programmatic software code and/or other information described herein. The request configuration module 102 is configured to configure the at least one HARQ A/N request condition. The radio interface 83 is configured to receive a request condition indicator from a network node 16 instructing the wireless device to prepare and return HARQ A/N messages according to a request condition and to send the HARQ A/N messages according to the request condition. FIG. 6 is a flowchart illustrating an exemplary method implemented in a communication system, such as, for example, the communication system of FIGS. 1 and 2, in accordance with one embodiment. The communication system may include a host computer 24, a network node 16 and a WD 22, which may be those described with reference to FIG. 2. In a first step of the method, the host computer 24 provides user data (block S100). The“user data” may be data and information described herein as implementing the described functionality.

In an optional substep of the first step, the host computer 24 provides the user data by executing a host application, such as, for example, the host application 74 (block S102). In a second step, the host computer 24 initiates a transmission carrying the user data to the WD 22 (block S104). In an optional third step, the network node 16 transmits to the WD 22 the user data which was carried in the transmission that the host computer 22 initiated, in accordance with the teachings of the embodiments described throughout this disclosure (block S106). In an optional fourth step, the WD 22 executes a client application, such as, for example, the client application 114, associated with the host application 74 executed by the host computer 24 (block S108).

FIG. 7 is a flowchart illustrating an exemplary method implemented in a communication system, such as, for example, the communication system of FIG. 1, in accordance with one embodiment. The communication system may include a host computer 24, a network node 16 and a WD 22, which may be those described with reference to FIGS. 1 and 2. In a first step of the method, the host computer 24 provides user data (block Sl 10). In an optional substep (not shown) the host computer 24 provides the user data by executing a host application, such as, for example, the host application 74. In a second step, the host computer 24 initiates a transmission carrying the user data to the WD 22 (block Sl 12). The transmission may pass via the network node 16, in accordance with the teachings of the embodiments described throughout this disclosure. In an optional third step, the WD 22 receives the user data carried in the transmission (block Sl 14).

FIG. 8 is a flowchart illustrating an exemplary method implemented in a communication system, such as, for example, the communication system of FIG. 1, in accordance with one embodiment. The communication system may include a host computer 24, a network node 16 and a WD 22, which may be those described with reference to FIGS. 1 and 2. In an optional first step of the method, the WD 22 receives input data provided by the host computer 24 (block Sl 16). In an optional substep of the first step, the WD 22 executes the client application 114, which provides the user data in reaction to the received input data provided by the host computer 24 (block Sl 18). Additionally or alternatively, in an optional second step, the WD 22 provides user data (block S120). In an optional substep of the second step, the WD provides the user data by executing a client application, such as, for example, client application 114 (block S122). In providing the user data, the executed client application 114 may further consider user input received from the user. Regardless of the specific manner in which the user data was provided, the WD 22 may initiate, in an optional third substep, transmission of the user data to the host computer 24 (block S124). In a fourth step of the method, the host computer 24 receives the user data transmitted from the WD 22, in accordance with the teachings of the embodiments described throughout this disclosure (block S126).

FIG. 9 is a flowchart illustrating an exemplary method implemented in a communication system, such as, for example, the communication system of FIG. 1, in accordance with one embodiment. The communication system may include a host computer 24, a network node 16 and a WD 22, which may be those described with reference to FIGS. 1 and 2. In an optional first step of the method, in accordance with the teachings of the embodiments described throughout this disclosure, the network node 16 receives user data from the WD 22 (block S128). In an optional second step, the network node 16 initiates transmission of the received user data to the host computer 24 (block S130). In a third step, the host computer 24 receives the user data carried in the transmission initiated by the network node 16 (block S132).

FIG. 10 is a flowchart of an exemplary process performed by a requesting node for configuring and requesting HARQ A/N messages according to some embodiments of the present disclosure. In one embodiment, an example method is performed by a requesting node (e.g., network node 16 and/or WD 22) configured to communicate with a responding node (e.g., network node 16 and/or WD 22). The example method may be performed by any of the hardware for a requesting node (such as radio interface 62, processing circuitry 68 and request configuration unit 32 for embodiments in which the requesting node is the network node 16, or radio interface 82, processing circuitry 84, and/or request configuration unit 34 in embodiments in which the requesting node is the WD 22). The example method for a requesting node includes signaling (block S134) to the responding node, a request condition indicator, the request condition indicator associated with a configuration of at least one hybrid automatic repeat request, HARQ, request condition and the request condition indicator instructing the responding node to prepare and send at least one HARQ acknowledgment/non-acknowledgement, A/N, message according to the at least one HARQ request condition.

In some embodiments, the method further includes the requesting node communicating the configuration of the at least one HARQ request condition to the responding node, the requesting node being a network node 16. In some

embodiments, the method further includes the requesting node communicating an uplink, UL, transmission, the signaling of the request condition indicator associated with the UL transmission and the requesting node being a wireless device, WD 22. In some embodiments, the at least one HARQ request condition includes a set of HARQ request conditions and the signalled request condition indicator indicates at least one HARQ request condition of the set of HARQ request conditions. In some

embodiments, the configuration of the at least one HARQ request condition includes at least one range of HARQ process identifiers, IDs, for which the responding node is to prepare and send the at least one HARQ A/N message. In some embodiments, the at least one range includes a non-contiguous range of HARQ process IDs for which the responding node is to prepare and send the at least one HARQ A/N message. In some embodiments, the at least one range includes a contiguous range HARQ process IDs for which the responding node is to prepare and send the at least one HARQ A/N message. In some embodiments, the at least one HARQ request condition includes a request to prepare and send the at least one HARQ A/N message for all HARQ process identifiers, IDs, associated with a communication channel. In some embodiments, the at least one HARQ request condition includes a request that no HARQ A/N message is to be prepared and sent for any HARQ process identifiers,

IDs, associated with a communication channel. In some embodiments, the configuration of the at least one HARQ request condition is performed by at least one of receiving and configuring the at least one HARQ request condition via at least one of higher layer signaling and radio resource control, RRC, signaling. In some embodiments, the method further includes receiving the at least one HARQ A/N message according to the at least one HARQ request condition. In some

embodiments, the at least one HARQ A/N message is a HARQ feedback message with a bit length, the bit length based at least in part on a number of HARQ processes identifiers, IDs, satisfying the at least one HARQ request condition indicated by the request condition indicator. In some embodiments, the at least one HARQ A/N message is a HARQ feedback message with a bit length, the bit length based at least in part on at least one of a codeword configuration and a code block group, CBG, configuration.

In some embodiments, the at least one HARQ A/N message is associated with at least one HARQ process identifier and a predetermined time period and if a communication associated with the at least one HARQ process identifier is not received within the predetermined time period, a HARQ non-acknowledgement is reported for the at least one HARQ process identifier.

In another embodiment, the process includes configuring, via the request configuration unit 32 or 34, at a transmitting node such as network node 16 or WD 22, at least one hybrid automatic repeat request, HARQ, acknowledgment/non

acknowledgement, A/N, request condition. The process also includes signaling, via a radio interface 62 or 82, to a receiving node, such as network node 16 or WD 22, a request condition indicator to instruct the receiving node to prepare and send HARQ A/N messages according to at the least one HARQ request condition.

FIG. 11 is a flowchart of an exemplary process in a responding node for responding to a request for HARQ A/N messages according to some embodiments of the present disclosure. In one embodiment, an example method is performed by a responding node (e.g., network node 16 and/or WD 22) configured to communicate with a requesting node (e.g., network node 16 and/or WD 22). The example method may be performed by any of the hardware for a responding node (such as radio interface 62, processing circuitry 68 and request configuration unit 32 for

embodiments in which the responding mode is the network node 16, or radio interface 82, processing circuitry 84, and/or request configuration unit 34 in embodiments in which the responding node is the WD 22). The example method performed by a responding node includes receiving (block S136) a request condition indicator, the request condition indicator associated with a configuration of at least one hybrid automatic repeat request, HARQ, request condition; and based at least in part on the received request condition indicator, preparing and sending (block S 138) at least one HARQ acknowledgment/non-acknowledgement, A/N, message according to the at least one HARQ request condition.

In some embodiments, the method further includes receiving the configuration of the at least one HARQ request condition from the requesting node, the requesting node being a network node 16 and the responding node 22 being a wireless device, WD 22. In some embodiments, the responding node is a network node 16 and the request condition indicator is associated with an uplink, UL, transmission. In some embodiments, the at least one HARQ request condition includes a set of HARQ request conditions and the received request condition indicator indicates at least one HARQ request condition of the set of HARQ request conditions. In some

embodiments, the configuration of the at least one HARQ request condition includes at least one range of HARQ process identifiers, IDs, for which the responding node (e.g., network node 16 and/or WD 22) is to prepare and send the at least one HARQ A/N message. In some embodiments, the at least one range includes a non contiguous range of HARQ process IDs for which the responding node (e.g., network node 16 and/or WD 22) is to prepare and send the at least one HARQ A/N message.

In some embodiments, the at least one range includes a contiguous range HARQ process IDs for which the responding node (e.g., network node 16 and/or WD 22) is to prepare and send the at least one HARQ A/N message. In some embodiments, the at least one HARQ request condition includes a request to prepare and send the at least one HARQ A/N message for all HARQ process identifiers, IDs, associated with a communication channel. In some embodiments, the at least one HARQ request condition includes a request that no HARQ A/N message is to be prepared and sent for any HARQ process identifiers, IDs, associated with a communication channel. In some embodiments, the configuration of the at least one HARQ request condition is performed by at least one of receiving and configuring via at least one of higher layer signaling and radio resource control, RRC, signaling. In some embodiments, the at least one HARQ A/N message is a HARQ feedback message with a bit length, the bit length based at least in part on a number of HARQ processes or HARQ process identifiers, IDs, satisfying the at least one HARQ request condition indicated by the request condition indicator. In some embodiments, the at least one HARQ A/N message is a HARQ feedback message with a bit length, the bit length based at least in part on at least one of a codeword configuration and a code block group, CBG, configuration.

In one embodiment, the process includes receiving, via a radio interface 62 or 82, at a receiving node, such as network node 16 or WD 22, a request condition indicator from another node instructing the other node device to prepare and return hybrid automatic repeat request, HARQ, acknowledgment/ non-acknowledgement, A/N, messages according to a request condition (block S138). The process also includes sending, via the radio interface 62 or 82, the HARQ A/N messages according to the request condition (block S140).

To enable the flexible HARQ A/N feedback scheme, a network node 16, i.e., a network control node such as the gNB in the NR system, configures a set of HARQ A/N request conditions via higher layer signaling. One nonlimiting example of higher layer signaling is radio resource control (RRC) layer signaling.

Let

represents the number of HARQ processes for the

communication link. Such a parameter

can be determined from stored values according to the system specification. The parameter can also be configured by the network control node via higher layer signaling.

In a first exemplary embodiment, the HARQ A/N request conditions are composed of range and limits of the HARQ process IDs. A set of four HARQ A/N request conditions can be configured as follows: • HRCO: the HARQ A/N for HARQ process

This represents a request for the HARQ A/N for all HARQ processes.

• HRC1 : the HARQ A/N for HARQ process

This represents a request for the HARQ A/N for the first half of the HARQ processes.

• HRC2: the HARQ A/N for HARQ process

...,

— l). This represents a request for the HARQ A/N for the second half of the HARQ processes.

• HRC3 : the HARQ A/N for HARQ process

... , #(3/V_pr^^Q/4— l). This represents a request for the HARQ A/N for the middle half of the HARQ processes.

As a nonlimiting example of the embodiment with

= 8, HRCO requests HARQ A/N corresponding to HARQ process #0, #1, #2, #3, #4, #5, #6 and #7; HRC1 requests HARQ A/N corresponding to HARQ process #0, #1, #2 and #3; HRC2 requests HARQ A/N corresponding to HARQ process #4, #5, #6 and #7; HRC3 requests HARQ A/N corresponding to HARQ process #2, #3, #4 and #5.

In a further exemplary embodiment, one of the HRC can be set to no request at this time.

In yet another exemplary embodiment, the HARQ A/N request conditions are composed of a range and limits of the HARQ process IDs as well as range of data transmission times.

In above examples all HARQ A/N request conditions contain a contiguous range of HARQ processes. Noncontiguous HARQ process IDs, e.g., all even or odd HAEQ process IDs, would be other examples.

The number of HARQ process IDs for the different HARQ A/N request conditions can be the same or different.

Two different WD behaviors are contemplated: 1) A WD 22 reports PDSCH decoding status (ACK/NACK) for a requested HARQ process ID, regardless of when PDSCH has been received for this HARQ process ID; 2) A WD 22 reports PDSCH decoding status (ACK/NACK) for a requested HARQ process ID, if PDSCH for this HARQ process has been received within a specified/configured time duration (time can be measured in absolute times, slots, symbols, subframes, e.g., last 4 slots, last

slots, etc). If no PDSCH has been received within this time duration a NACK is reported for this HARQ process. The latter scheme provides better robustness towards missed DL assignments.

With configured set of HARQ A/N request conditions, a requesting node can signal to a responding node to prepare and send back HARQ A/N according to the requested conditions. As described herein, a requesting node can include a network node 16 or a WD 22, and the responding node can be the other of the network node 16 or the WD 22.

In a first example application of the embodiment, a gNB in the NR system can send such request condition indicator to instruct the WD 22 to send HARQ A/N corresponding to a specific range of HARQ process IDs;

In a second application of the embodiment, a WD 22 capable of and configured to perform UL transmissions without explicit grants from the gNB (e.g., in an unlicensed band operation mode) can indicate such HARQ A/N request condition indicator.

The responding node prepares a HARQ A/N feedback of a length according to the received HRC and other configuration parameters. For instance, if the

communication link has been configured for transmitting one codeword per transmission time and without CBG based feedback, then the length of the feedback is the same as the number of HARQ processes satisfying the requested condition. For the nonlimiting example stated in the above, the responding node prepares a HARQ A/N feedback of length 4 if any of the HRC1, HRC2 or HRC3 is received. As another example, if the communication link has been configured for transmitting one codeword per transmission time and with 6 CBG per codeword, then the responding node prepares a HARQ A/N feedback of length 24 if any of the HRC1, HRC2 or HRC3 is received. As a further example, if the communication link has been configured for transmitting two codewords per transmission time and with 4 CBG per codeword, then the responding node prepares a HARQ A/N feedback of length 32 if any of the HRC1, HRC2 or HRC 3 is received. Some examples may include one or more of the following:

Example Al . A network node configured to communicate with a wireless device (WD), the network node comprising a radio interface and processing circuitry configured to:

configure a least one hybrid automatic repeat request, HARQ,

acknowledgment/non-acknowledgement, A/N, request condition; and

signal to the wireless device a request condition indicator to instruct the wireless device to prepare and send HARQ A/N messages according to at least one request condition.

Example A2. The network node of Example Al, wherein the request condition indicates a specific range of HARQ process IDs for which the WD is to send the HARQ A/N.

Example A3. The network node of Example A2, wherein the range is a non contiguous set of ranges.

Example A4. The network node of Example Al, wherein the request condition indicates a request for HARQ A/N for all HARQ processes.

Example A5. The network node of Example Al, wherein the request condition indicates that no HARQ A/N is to be sent.

Example Bl. A communication system including a host computer, the host computer comprising:

processing circuitry configured to provide user data; and

a communication interface configured to forward the user data to a cellular network for transmission to a wireless device (WD),

the cellular network comprising a network node having a radio interface and processing circuitry, the network node’s processing circuitry configured to:

configure a least one hybrid automatic repeat request, HARQ, acknowledgment/non-acknowledgement, A/N, request condition;

Example B2. The communication system of Example Bl, further including the network node. Example B3. The communication system of Example B2, further including the WD, the WD being configured to communicate with the network node.

Example B4. The communication system of Example B3, wherein:

the processing circuitry of the host computer is configured to execute a host application, thereby providing the user data; and

the WD comprises processing circuitry configured to execute a client application associated with the host application.

Example Cl . A method implemented in a network node, the method comprising:

configuring a least one hybrid automatic repeat request, HARQ,

acknowledgment/non-acknowledgement, A/N, request condition; and

signaling to the wireless device a request condition indicator to instruct the wireless device to prepare and send HARQ A/N messages according to at least one request condition.

Example C2. The method of Example Cl, wherein the request condition indicates a specific range of HARQ process IDs for which the WD is to send the HARQ A/N.

Example C3. The method of Example C2, wherein the range is a non contiguous set of ranges.

Example C4. The method of Example Cl, wherein the request condition indicates a request for HARQ A/N for all HARQ processes.

Example C5. The method of Example Cl, wherein the request condition indicates that no HARQ A/N is to be sent.

Example Dl . A method implemented in a communication system including a host computer, a network node and a wireless device (WD), the method comprising: at the host computer, providing user data; and

at the host computer, initiating a transmission carrying the user data to the WD via a cellular network comprising the network node, the network node being configured to:

configure a least one hybrid automatic repeat request, HARQ, acknowledgment/non-acknowledgement, A/N, request condition; and signal to the wireless device a request condition indicator to instruct the wireless device to prepare and send HARQ A/N messages according to at least one request condition.

Example D2. The method of Example Dl, further comprising, at the network node, transmitting the user data.

Example D3. The method of Example D2, wherein the user data is provided at the host computer by executing a host application, the method further comprising, at the WD, executing a client application associated with the host application.

Example El . A wireless device (WD) configured to communicate with a network node, the WD comprising a radio interface and processing circuitry configured to:

receive a request condition indicator from the network node instructing the wireless device to prepare and return hybrid automatic repeat request, HARQ, acknowledgment/non-acknowledgement, A/N, messages according to a request condition; and

sending the HARQ A/N messages according to the request condition.

Example E2. The wireless device of Example El, wherein the request condition indicates a specific range of HARQ process IDs for which the WD is to send the HARQ A/N.

Example E3. The wireless device of Example E2, wherein the range is a non contiguous set of ranges.

Example E4. The wireless device of Example El, wherein the request condition indicates a request for HARQ A/N for all HARQ processes.

Example E5. The wireless device of Example El, wherein the request condition indicates that no HARQ A/N is to be sent.

Example F 1. A communication system including a host computer, the host computer comprising:

processing circuitry configured to provide user data; and

a communication interface configured to forward user data to a cellular network for transmission to a wireless device (WD);

the WD comprising a radio interface and processing circuitry, the WD’s processing circuitry configured to: receive a request condition indicator from the network node instructing the wireless device to prepare and return hybrid automatic repeat request, HARQ, acknowledgment/non-acknowledgement, A/N, messages according to a request condition; and

send the HARQ A/N messages according to the request condition.

Example F2. The communication system of Example Fl, further including the WD.

Example F3. The communication system of Example F2, wherein the cellular network further includes a network node configured to communicate with the

WD.

Example F4. The communication system of Example F2 or F3, wherein: the processing circuitry of the host computer is configured to execute a host application, thereby providing the user data; and

the WD’s processing circuitry is configured to execute a client application associated with the host application.

Example Gl . A method implemented in a wireless device (WD), the method comprising:

receiving a request condition indicator from the network node instructing the wireless device to prepare and return hybrid automatic repeat request, HARQ, acknowledgment/non-acknowledgement, A/N, messages according to a request condition; and

sending the HARQ A/N messages according to the request condition.

Example G2. The method of Example Gl, wherein the request condition indicates a specific range of HARQ process IDs for which the WD is to send the HARQ A/N.

Example G3. The method of Example G2, wherein the range is a non contiguous set of ranges.

Example G4. The method of Example Gl, wherein the request condition indicates a request for HARQ A/N for all HARQ processes.

Example G5. The method of Example Gl, wherein the request condition indicates that no HARQ A/N is to be sent. Example Hl . A method implemented in a communication system including a host computer, a network node and a wireless device (WD), the method comprising: at the host computer, providing user data; and

at the host computer, initiating a transmission carrying the user data to the WD via a cellular network comprising the network node, the WD being configured to:

sending the HARQ A/N messages according to the request condition.

Example H2. The method of Example Hl, further comprising, at the WD, receiving the user data from the network node.

Example II . A wireless device (WD) configured to communicate with a network node, the WD comprising a radio interface and processing circuitry configured to:

configure a least one hybrid automatic repeat request, HARQ,

acknowledgment/non-acknowledgement, A/N, request condition; and

Example 12. The WD of Example II, wherein the request condition indicates a specific range of HARQ process IDs for which the WD is to send the HARQ A/N.

Example 13. The WD of Example 12, wherein the range is a non-contiguous set of ranges.

Example 14. The WD of Example II, wherein the request condition indicates a request for HARQ A/N for all HARQ processes.

Example 15. The WD of Example II, wherein the request condition indicates that no HARQ A/N is to be sent.

Example Jl . A communication system including a host computer, the host computer comprising: a communication interface configured to receive user data originating from a transmission from a wireless device (WD) to a network node:

the WD comprising a radio interface and processing circuitry, the WD’s processing circuitry configured to:

configure a least one hybrid automatic repeat request, HARQ, acknowledgment/non-acknowledgement, A/N, request condition; and

Example J2. The communication system of Example Jl, further including the WD.

Example J3. The communication system of Example J2, further including the network node, wherein the network node comprises a radio interface configured to communicate with the WD and a communication interface configured to forward to the host computer the user data carried by a transmission from the WD to the network node.

Example J4. The communication system of Example J2 or J3, wherein: the processing circuitry of the host computer is configured to execute a host application; and

the WD’s processing circuitry is configured to execute a client application associated with the host application, thereby providing the user data.

Example J5. The communication system of Example J2 or J3, wherein: the processing circuitry of the host computer is configured to execute a host application, thereby providing request data; and

the WD’s processing circuitry is configured to execute a client application associated with the host application, thereby providing the user data in response to the request data.

Example Kl . A method implemented in a wireless device (WD), the method comprising:

configuring a least one hybrid automatic repeat request, HARQ,

acknowledgment/non-acknowledgement, A/N, request condition; and signaling to the wireless device a request condition indicator to instruct the wireless device to prepare and send HARQ A/N messages according to at least one request condition.

Example K2. The method of Example Kl, wherein the request condition indicates a specific range of HARQ process IDs for which the WD is to send the HARQ A/N.

Example K3. The method of Example K2, wherein the range is a non contiguous set of ranges.

Example K4. The method of Example Kl, wherein the request condition indicates a request for HARQ A/N for all HARQ processes.

Example K5. The method of Example Kl, wherein the request condition indicates that no HARQ A/N is to be sent.

Example K6. The method of Example Kl, further comprising:

providing user data; and

forwarding the user data to a host computer via the transmission to the network node.

Example Ll . A method implemented in a communication system including a host computer, a network node and a wireless device (WD), the method comprising: at the host computer, receiving user data transmitted to the network node from the WD, the WD configured to:

Example L2. The method of Example Ll, further comprising, at the WD, providing the user data to the network node.

Example L3. The method of Example L2, further comprising:

at the WD, executing a client application, thereby providing the user data to be transmitted; and

at the host computer, executing a host application associated with the client application. Example L4. The method of Example L2, further comprising:

at the WD, executing a client application; and

at the WD, receiving input data to the client application, the input data being provided at the host computer by executing a host application associated with the client application,

the user data to be transmitted being provided by the client application in response to the input data.

Example Ml . A network node configured to communicate with a wireless device (WD), the network node comprising a radio interface and processing circuitry configured to:

receive a request condition indicator from the network node instructing the wireless device to prepare and return hybrid automatic repeat request, HARQ, acknowledgment/non-acknowledgement, A/N, messages according to a request condition;

send the HARQ A/N messages according to the request condition.

Example M2. The network node of Example Ml, wherein the request condition indicates a specific range of HARQ process IDs for which the WD is to send the HARQ A/N.

Example M3. The network node of Example M2, wherein the range is a non contiguous set of ranges.

Example M4. The network node of Example Ml, wherein the request condition indicates a request for HARQ A/N for all HARQ processes.

Example M5. The network node of Example Ml, wherein the request condition indicates that no HARQ A/N is to be sent.

Example Nl . A communication system including a host computer, the host computer comprising: a communication interface configured to receive user data originating from a transmission from a wireless device (WD) to a network node, the network node comprising a radio interface and processing circuitry, the network node’s processing circuitry configured to:

send the HARQ A/N messages according to the request condition.

Example N2. The communication system of Example Nl, further including the network node.

Example N3. The communication system of Example N2, further including the WD, the WD being configured to communicate with the network node.

Example N4. The communication system of Example N3, wherein:

the processing circuitry of the host computer is configured to execute a host application; and

the WD is configured to execute a client application associated with the host application, thereby providing the user data to be received by the host computer.

Example 01. A method implemented in a network node, the method comprising:

sending the HARQ A/N messages according to the request condition.

Example 02. The method of Example 01, wherein the request condition indicates a specific range of HARQ process IDs for which the WD is to send the HARQ A/N.

Example 03. The method of Example 02, wherein the range is a non contiguous set of ranges.

Example 04. The method of Example 01, wherein the request condition indicates a request for HARQ A/N for all HARQ processes.

Example 05. The method of Example 01, wherein the request condition indicates that no HARQ A/N is to be sent.

Example Pl . A method implemented in a communication system including a host computer, a network node and a wireless device (WD), the method comprising: at the host computer, receiving, from the network node, user data originating from a transmission which the network node has received from the WD, the network node configured to:

send the HARQ A/N messages according to the request condition.

Example P2. The method of Example Pl, further comprising, at the network node, receiving the user data from the WD.

Example P3. The method of Example P2, further comprising, at the network node, initiating a transmission of the received user data to the host computer.

Example Ql . A network node, comprising:

a memory module configured to store at least one hybrid automatic repeat request, HARQ, acknowledgment/non-acknowledgement, A/N, request condition; a request configuration module configured to configure the at least one HARQ A/N request condition; and

a radio interface module configured to signal to a wireless device a request condition indicator to instruct the wireless device to prepare and send HARQ A/N messages according to at least one request condition.

Example Q2. A wireless device, comprising:

a memory module configured to store at least one hybrid automatic repeat request, HARQ, acknowledgment/non-acknowledgement, A/N, request condition; a radio interface module configured to:

receive a request condition indicator from a network node instructing the wireless device to prepare and return hybrid automatic repeat request, HARQ, acknowledgment/ non-acknowledgement, A/N, messages according to a request condition; and

send the HARQ A/N messages according to the request condition.

Some additional embodiments related to HARQ management may include one or more of the following techniques, methods and apparatuses described below. In this document, HARQ codebook design is discussed for single carrier and carrier aggregation with same/different TTI length, with/without CBG. Also we discuss the number of HARQ processes in the UL for different scenarios, and HARQ process sharing for slot-based transmission, mini-slot based transmission and UL transmission without UL grant. One or more of the following agreements were reached:

Agreements:

• For NR non-CA, both semi-static and dynamic HARQ-ACK codebook are supported by configuration

o Note: the“by-configuration” is also applicable to the CA case

Agreements:

• Dynamic HARQ-ACK codebook (per PUCCH group) for the case

without CBG configuration

- HARQ-ACK codebook determination based on counter DAI and total DAI

• Use LTE as starting point

• FFS details

Agreements:

• For the case when the semi-static HARQ-ACK codebook with HARQ- ACK multiplexing which includes HARQ-ACK corresponding to all the CBGs (including the non-scheduled CBG(s)) is used,

o NACK is reported for all the CBGs if TB CRC check is not passed while CB CRC check is passed for all the CBs >NACK is mapped for the empty CBG index if the number of CBs for a TB is smaller than the configured maximum number of CBGs

Agreements:

• ‘ Semi-static’ HARQ-ACK codebook (per PUCCH group) is at least determined by

- Configured number of DL Cells - The max number of TBs based on configuration for each DL cell

- Configured number of CBGs per TB per configured DL cell

- FFS: Handling of different numerology between UL and DL

- Details FFS

• Dynamic HARQ-ACK codebook (per PUCCH group) with CBG configuration at least for one serving cell

- Details FFS

No carrier aggregation no CBG

Dynamic HARO codebook

Option 1

NR supports dynamic indication of PUCCH resource and time and HARQ feedback for multiple PDSCH can be sent using a single HARQ codebook. PUCCH resource and time will be indicated in the scheduling DCI in case of a dynamic scheduled transmission. The association between PDSCH and PUCCH can be based on the PUCCH resource (PR) and time indicated in the scheduling DCI (AT); HARQ feedback of all PDSCHs which scheduling DCIs indicate same PUCCH resource and time are reported together. The latest PDSCH feedback that can be included is limited by the processing time the UE needs to prepare HARQ feedback, in the example in FIG. 12 the UE can report HARQ feedback on a short PUCCH in the next slot. The earliest PDSCH to include in the HARQ codebook for a given PUCCH resource is the first scheduled PDSCH after the time window of the last transmitted same PUCCH resource has been expired (in FIG. 12 PDSCH of slot n-l is reported on PUCCH resource m of slot n; PDSCH from slot n is therefore the first PDSCH to include in the HARQ codebook transmitted on PUCCH resource m in slot n+5). This time window does however not determine the HARQ codebook size, it just sets the time boundaries which DL can be included in the HARQ codebook.

FIG. 12 illustrates an example of HARQ feedback association (the black dot at the lower right comer of a text indicates to which arrow the text belongs). To index the HARQ codebook the DCI of each scheduling assignment contains a DAI that counts all previous DL assignments (including the current one) that should be included in the HARQ codebook. The DAI contained in the DCI of the latest DL assignment determines the HARQ codebook size. Even if UE misses some DL assignments it can still address the HARQ codebook correctly, as long as the DAI does not wrap around. One error case that remains despite DAI is if the UE misses the last DL assignment which determines the HARQ codebook size. One possibility to mitigate this error case is to use an extra robust PDCCH transmission of the DCI that schedules the last DL assignment. Normally DAI is taken e.g. mod-2 to limit feedback size, in the examples shown in FIGS. 12-14 no modulo operation has yet been applied.

The DAI mechanism also enables multiplexing of HARQ feedback from slot- and non-slot-based transmissions into the same HARQ codebook (and thus to transmit on the same PUCCH). FIG. 13 shows the case where HARQ feedback from slot- and non-slot-based (hatched box in FIG. 13) transmissions are included in the same HARQ codebook. The DCI for all transmissions in slot n and later indicate the same PUCCH resource (PR=m) and time (slot n+5) but the DAI is different for the two transmissions in slot interval n+3.

FIG. 13 illustrates an example feedback for slot- and non-slot-based transmissions are multiplexed into the same HARQ codebook (the black dot at the lower right comer of a text indicates to which arrow the text belongs).

If the gNB wants the UE to use a different (earlier) PUCCH resource for non slot-based scheduling (e.g. the non-slot-based DL transmission relates to low latency and requires early HARQ feedback) the gNB can indicate different PUCCH resource and time (and as consequence also different DAI values) in the scheduling DCI, see FIG. 14 (PR=m, slot n+5 for slot-based transmissions; PR=k, slot n+3 for non-slot- based transmission).

FIG. 14 illustrates feedback for the non-slot-based transmission, which is transmitted separately in a PUCCH resource in the same slot interval (the black dot at the lower right comer of a text indicates to which arrow the text belongs).

Option 2 Also here, PUCCH resource and time will be indicated in the scheduling DCI in case of a dynamically scheduled transmission. The association between PDSCH and PUCCH can be based on the PUCCH resource (PR) and time indicated in the scheduling DCI (DT); HARQ feedback of all PDSCHs which scheduling DCIs indicate same PUCCH resource and time are reported together in the same HARQ codebook.

Differently from Option 1, the HARQ codebook size is based on time, its size is equal to the number of slots between the first DL assignment associated with the HARQ codebook and the last possible DL assignment associated with the HARQ codebook (based on the processing time the UE needs to prepare HARQ feedback for the indicated PUCCH resource). In FIG. 12, the HARQ codebook size would be 3 (slot n-3 to slot n-l) for PUCCH in slot n and 5 (slot n to n+4) for PUCCH in slot n+5 (in this example has been assumed HARQ feedback in the next slot is feasible). When the UE misses the first DL assignments it determines a wrong HARQ codebook size and an error occurs. This error case can be handled by including a counter similar to DAI in the scheduling DCI which however does not count DL assignments but slots, starting with 0 for the first DL assignment associated with the current HARQ codebook (Elapsed Slot Counter, ESC). In DCIs for subsequent DL assignments, the ESC is set to the number of slots elapsed since the first DL assignment has been scheduled, see FIG. 15. Even if the UE misses the first (few) DL assignments, it can still determine the first slot associated with the HARQ codebook (and thus its size) based on the DCI of first detected DL assignment and the contained ESC, as long as the ESC has not wrapped around. A 2 bit field ESC protects against missed DL assignments in the first three slots. The indexing into the HARQ codebook is based on the ESC or on the PUCCH slot timing indicator (DT). One drawback of this scheme is that it is not straight forward how to combine HARQ feedback from slot and non slot-based transmissions into the same HARQ codebook: All DL assignments in the same slot would have the same slot timing indicator DT (or ESC) for PUCCH in their scheduling DCI leading to multi-to-one mapping between PDSCH and PUCCH. This could be fixed by indexing the HARQ codebook based on slot timing indicator (DT) and symbol offset of transmission. However, non-slot-based transmissions can be used to enable transmissions with very short delay, many more non-slot-based transmission opportunities might be configured during a slot interval than actually used. Time-based indexing of the HARQ codebook might lead to very large HARQ codebooks for non-slot-based transmissions; this codebook would thus preferably be used for slot-based transmissions.

FIG. 15 illustrates an Elapsed Slot Counter (ESC) set to zero in the DCI of the first scheduled DL assignment. In DCIs of later DL assignments, it is set to the number of slots that has elapsed since the first DL assignment has been scheduled.

Based on above discussion how to construct the dynamic HARQ codebooks it may be that Option 1 is preferable, in certain embodiments. While Option 2 is more robust to missed assignments than Option 1 (even if more than one DL assignment is missed in Option 2, the HARQ codebook size can be reconstructed), Option 1 enables multiplexing of HARQ feedback from slot- and non-slot-based transmissions. The error case in Option 1 due to a missed last DL assignment can be mitigated with an extra robust PDCCH transmission of the last scheduled DCI. Option 2 also leads to larger HARQ codebooks than Option 1 if not all slots (PDSCH) associated with the HARQ codebook are scheduled.

Proposal: HARQ feedback from slot- and non-slot-based transmissions can be multiplexed into same HARQ codebook.

Proposal: The dynamic (in time dimension) HARQ codebook for non-CA is based on a counter DAI that counts DL assignments.

Fixed HARQ codebook

Option 1

To avoid error cases of missed DL assignments the HARQ codebook size would have to be fixed. One option to achieve this is by semi- statically configuring the HARQ codebook size (HARQ codebook association window size). Alternatively, as set of HARQ codebook sizes can be semi-statically configured and an indicator in the DCI selects one of the preconfigured HARQ codebook sizes. The PUCCH resource would still be given by the PUCCH resource indicator (PR) and the slot timing indicator (AT) in the DCI. If the gNB determines during the course of the scheduling that the initially indicated HARQ codebook size is wrong it is possible to adjust the HARQ codebook size by indicating a different HARQ codebook size in the DCI. Indexing into the HARQ codebook is done based on the slot timing indicator (DT) contained in each scheduling DCI. As outlined in Section 0 for Option 1, time- based indexing of the HARQ codebook can be inefficient for non-slot-based transmissions and is preferably used together with slot-based transmissions.

Option 2

Another option for a fixed HARQ codebook is to base its size on the configured number of HARQ processes and index the HARQ codebook using the HARQ process ID. Assuming the same HARQ process pool is used for slots and non slot-based transmissions this option enables easy multiplexing of HARQ feedback of slot and non-slot-based transmissions. Drawback of this option is that the HARQ codebook size will be typically quite large. It could be considered to semi-statically configure a set of HARQ codebooks, each HARQ codebook containing fields for different (potentially differently many) HARQ process IDs. An indictor in the scheduling DCI would select one of the HARQ codebooks. As above, it would be possible to indicate different HARQ codebooks during one scheduling cycle, as long as the selected HARQ codebook contains fields for all scheduled HARQ processes. No DAI is used in this scheme.

Proposal: The fixed HARQ codebook for non-CA is based on number of configured HARQ processes. Indexing into the HARQ codebook is based on the HARQ process ID of the associated DL assignment.

With carrier aggregation, no CBG

Same TTI on all component carriers

Fixed HARQ codebook

A fixed HARQ codebook in the context of carrier aggregation can be interpreted twofold: Fixed in time and component carrier dimension, or dynamic in time and fixed in component carrier dimension.

A HARQ codebook fixed in time and component carrier dimension could be based on Option 1 of Section 0, the HARQ codebook size would be given by its configured HARQ association window and configured component carriers. Instead of a single bit (two in case of MIMO configuration with up to two transport blocks) always a bitmap with the size needed for feedback of all configured component carriers is inserted into the HARQ codebook as soon as at least one DCI scheduling a DL assignment is detected for a TTI. Indexing (selection of the bitmap) is based on the PUCCH slot timing indicator (DT).

Option 2 of Section 0 can be generalized to carrier aggregation, too. The HARQ codebook size is determined by the sum of configured HARQ processes across the configured component carriers. Indexing into the HARQ codebook is done by the component carrier index and the HARQ process ID. It should be noted that, in some embodiments, this scheme could be generalized to the case of non-slot-based transmissions, if slot- and non-slot-based transmission share the same pool of HARQ processes.

Drawback of HARQ codebooks which size is fixed in both dimensions (component carrier and time or HARQ process) is its large overhead. A HARQ codebook that is only fixed in component carrier dimension is therefore preferable. Both solutions outlined in Section 0 could be generalized to carrier aggregation. Instead of a single bit (two in case of MIMO configuration with up to two transport blocks) always a bitmap with the size needed for feedback of all configured component carriers is inserted into the HARQ codebook as soon as at least one DCI scheduling a DL assignment is detected for a TTI. All DCIs transmitted in the same TTI scheduling a DL assignments (and to be acknowledged on the same PUCCH) would contain the same DAI (Option 1, Section 0) or the same ESC (Option 2,

Section 0). Since the same DAI or ESC is potentially transmitted multiple times (DCIs of all DL assignments in the same TTI carry same DAI or ESC) the likelihood of errors due to missed DL assignments decreases.

Proposal: Support fixed (fixed in component carrier dimension, dynamic in time dimension) HARQ codebook for carrier aggregation with same TTI on all component carriers. For each TTI where at least one DCI scheduling a DL assignment is detected, the HARQ codebook entry is a bitmap which size is given by the configured number of component carriers and configured number of transport blocks on a component carrier. The same counter DAI value is inserted in all DCIs in a TTI scheduling a DL assignment (for one PUCCH).

Dynamic HARQ codebook It has been agreed in RAN 1 #90b to support a dynamic HARQ codebook for carrier aggregation. In case of same TTI across aggregated component carriers we think the counter/total DAI mechanism from LTE Rel-l3 is sufficient.

Proposal: For dynamic (dynamic in both component carrier and time dimension) HARQ codebook for carrier aggregation with same TTI on all component carriers: Re-use counter/total DAI mechanism from LTE feCA.

Different TTIs across component carriers

Fixed HARQ codebook

If the configured component carriers are associated with different TTIs (e.g. due to mixing of slot- and non-slot-based transmissions) a PDCCH occurrence on one component carrier does not necessarily overlap with PDCCH occurrences on other component carriers. To insert for each detected DL assignment a bitmap according to the number of configured component carriers is therefore grossly overdone since not even PDCCH opportunities might exist on other component carriers. Alternatively, a bitmap with the number of configured PDCCH occurrences can be inserted at each PDCCH time (when at least one DL assignment has been detected), however, this number would be time- varying resulting in a complex solution.

Another possibility would be to generalize Option 2 from Section 0 to carrier aggregation. Since entries are based on HARQ processes multiplexing of slot- and non-slot-based transmissions is simple as long as transmissions share the same HARQ process pool per carrier. However, as stated earlier, the resulting HARQ codebook will typically be very large.

A fixed codebook together with different TTIs across aggregated component carriers seems therefore not desirable.

Proposal: Do not support fixed (fixed in component carrier dimension) HARQ codebook for carrier aggregation with different TTIs across component carriers.

Dynamic HARQ codebook

An example applies the dynamic HARQ codebook using counter/total DAI mechanism to the case where the component carriers have different TTI lengths. In this example three component carriers are aggregated. At each PDCCH time, the total DAI is set to the total number of scheduled DL assignments including this PDCCH time. Most important for successful HARQ codebook decoding is the total DAI, if this number is wrong the decoding will likely fail. If the UE misses the middle hatched PDCCH with DAI (3,3) and the blue PDCCH with DAI (0,0) but receives the blue PDCCH with DAI (1,2) it can reconstruct the total HARQ codebook length and determine that it missed two PDCCH assignments. However, if the UE misses the last hatched PDCCH with DAI (3,3) it assumes a wrong HARQ codebook size and decoding likely fails. Even in case of same TTI length across component carriers the same problem exists but the likelihood that the highest total DAI is transmitted multiple times (and thus the likelihood that UE receives total DAI at least once) is higher if PDCCH occurrences are aligned (i.e. same TTI) than with unaligned PDCCH occurrences. To counteract this effect the scheduler can use a higher CCE aggregation level when transmitting the last DCI.

FIG. 16 illustrates a UE configured with three component carriers with mixed slot- and non-slot-based transmissions. At each PDCCH time, the total DAI is set to the total number of scheduled DL assignments including this PDCCH time.

To improve robustness it can be considered to predictively set the total DAI to a larger value than the highest counter DAI at the current PDCCH time. For example, in the modified example of FIG. 16, shown in FIG. 17, the gNB sets the total DAI field first to 3. After that the total DAI is subsequently increased to 5 and 8. The last total DAI 8 is transmitted twice, so even if the last DL assignment is missed the HARQ codebook size can be reconstructed. In this example the gNB did not correctly guess the HARQ codebook size correctly but overestimated it by 1. The UE assumes it missed the DL assignment and sends a NACK. In principal above behavior can already be implemented with LTE feCA counter/total DAI. In FIG. 16 and FIG. 17 the DAIs are shown without modulo-reduction to 2 bit. A 2 bit total DAI means the total DAI can be predictively increased by 3 before a wrap around occurs. It could be desirable to increase this range, this can either be achieved by increasing the total DAI bit field width or by maintaining its bit width but a total DAI increment 1 increases the HARQ codebook size by a larger unit, e.g. 2. In the latter case the HARQ codebook size would sometimes a bit too large (depends on the HARQ codebook increment size), but this feels a minor drawback.

FIG. 17 illustrates an example where a UE is configured with three component carriers with mixed slot- and non-slot-based transmissions. The total DAI is set predictively to a larger value than the highest counter DAI of the current PDCCH time. As a result, the same total value (and especially the last total DAI) is transmitted several times.

It has been proposed to independently determine HARQ codebook for slot- and non-slot-based transmissions. However, this may not simplify the problem since a HARQ codebook that can handle non-slot-based transmissions (and such a HARQ codebook is needed) can also handle slot-based transmissions. Further, by indicating different PUCCH for slot- and non-slot-based transmissions the proposed framework enables to split HARQ feedback of slot- and non-slot-based transmissions into two HARQ codebooks.

Proposal: Support dynamic (dynamic in both component carrier and time dimension) HARQ codebook for carrier aggregation with a mix of slot- and non-slot- based transmissions across component carriers. Re-use counter/total DAI mechanism from LTE feCA. Total DAI can predictively be set to a larger value than highest counter DAI of current PDCCH time. Consider an increased HARQ codebook size increment per total DAI increment.

Note that such a HARQ codebook can also handle carrier aggregation with mixed numerology. However, in Rel-l5, PDSCH associated with a HARQ codebook are limited to the same subcarrier spacing.

No carrier aggregation, with CBG

The same solution as outlined for the case with no CA, no CBG can be adopted here. Instead of a single or two bits (depending on MIMO configuration) a bitmap of fixed size is inserted for each detected DL assignment. The bitmap size is given by the MIMO configuration and the configured number of CBG.

Proposal: For dynamic (in time dimension) HARQ codebook for non-CA with CBG: Each entry in the HARQ codebook is a bitmap which size is given by the configured number of CBG and transport block on the component carrier. A counter DAI is inserted in the DCI counting DL assignments (including the current one).

With carrier aggregation, with CBG

It has been agreed to support a fixed HARQ codebook which size is at least determined by configured number of aggregated component carriers, max number of transport blocks per component carriers according to configuration, and configured number of CBG per component carrier.

The same solution as outlined for the case with no CA, no CBG can be adopted here. Each time at least one DCI scheduling a DL assignment is detected for a TTI a bitmap is inserted into the HARQ codebook containing HARQ feedback for all configured component carriers. This size of the bitmap is determined by by configured number of aggregated component carriers, max number of transport blocks per component carriers according to configuration, and configured number of CBG per component carrier. Not detected transport blokes and/or CBG are reported as NACK. The same DAI value is inserted in all DCIs within a slot scheduling a DL assignment.

Proposal: Support fixed (fixed in component carrier dimension, dynamic in time dimension) HARQ codebook for carrier aggregation with CBG and same TTI on all component carriers. For each TTI where at least one DCI scheduling a DL assignment is detected, the HARQ codebook entry is a bitmap which size is given by the configured number of component carriers, configured number of CBG and configured number of transport block on a component carrier. The same counter DAI value is inserted in all DCIs in a TTI scheduling a DL assignment (for one PUCCH).

The number of HARQ processes

Retransmissions are scheduled in a similar way as the original transmission. Hence, upon reception of a negative acknowledgement (for downlink data

transmissions) or detection of incorrectly received uplink data (for uplink data transmission), the gNodeB needs to schedule a retransmission.

The number of hybrid ARQ processes depends on the overall roundtrip time. For downlink data transmission this includes the UE processing time to generate the acknowledgement, network-side processing time for scheduling the retransmission, and front-haul delays in case remote radio units are used to separate the baseband processing from the actual transmission site.

The speed of light in an optical fiber is approximatively 2· 108 m/s. Hence, for a 15 km distance, which is not an unlikely distance, the two-way delay is 150 ps. The scheduling delays can be in a similar range, depending on implementation, network load, scheduling complexity in terms of quality-of-service handling, exploitation of channel conditions, multi-user MIMO aspects, etc. As a comparison, the slot length is 125 ps assuming 14 symbol slots and 120 kHz subcarrier spacing.

Coexistence with TD-LTE is another example where multiple hybrid- ARQ processes are needed as there, for coexistence reasons, can be multiple slots

(corresponding to LTE subframes) where it is not possible to transmit an uplink acknowledgement. For a typical case of TDD uplink-downlink allocation #2, there are four downlink slots followed by one uplink slot. In principle, four processes would be sufficient to handle this if the EGE is capable of‘same slot’ ACK, otherwise a couple of more processes are needed. Furthermore, LTE supports several uplink-downlink allocations, many of which are not used in practice, and it can be considered if coexistence with all these possibilities need to be able to support the peak data rate.

From the simplified discussion above, it is seen that the time from

transmission to retransmission can be in the order of several slots, motivating multiple hybrid- ARQ processes. At the same time, it is beneficial to keep the number of hybrid-ARQ processes small as NR is supposed to provide low latency. Furthermore, supporting different number of hybrid-ARQ processes for different numerologies would complicate the overall structure and a single number is preferable. It is therefore recommended to support 8 hybrid-ARQ processes in NR, i.e. use 3 bits for the hybrid-ARQ process number in the DCI.

HARQ process sharing

For the scheduling purpose either a slot or mini-slot can be scheduled on a specific carrier. To allow full flexibility in scheduling within a single carrier it would make sense to have the same HARQ processes being applicable for both mini-slots and slots. This allows the gNodeb to dynamically move between slot and mini-slot transmission and is in line with the general intention in RAN1 to harmonize slots and mini- slots into the same framework.

To be able to support different services it is assumed in the discussion that the TIE can be assigned with multiple PDSCH within the same subframe. In some embodiments, it may be sufficient to be able to handle two PDSCH for unicast simultaneously on one carrier for the UE To provide sufficient flexibility in the design no restriction should be made on the allocated frequency resource and time resource for the two PDSCH(s). Note however that a UE can be assigned with many consecutive PDSCH(s) in time within a slot if they do not overlap in time.

Furthermore, a simultaneous UL transmission without UL grant together with scheduled PDSCH(s) is possible. In transmission without UL grant, a retransmission based on a dynamic grant is useful to guarantee a successful retransmission by a dedicated channel. For better handling of HARQ retransmissions in this case it is desirable that the HARQ processes are shared between the scheduled transmissions and the UL transmission without UL grant. The assignment can be done by means of RRC signaling.

Proposal: HARQ process IDs are shared between slot, and mini-slot as well as both transmission with grant and UL transmission without UL grant.

Accordingly, HARQ codebook for NR has been discussed. The following are some proposals (the proposals in the text have been combined to the proposals below):

Proposal: Support dynamic (in time dimension) HARQ codebook for non-CA case.

Proposal: Support fixed (fixed in component carrier dimension, dynamic in time dimension) HARQ codebook for CA with same TTI on all component carriers. For each TTI where at least one DL assignment is detected, the HARQ codebook entry is a bitmap which size is given by the configured number of CC and MIMO configuration.

Proposal: Support dynamic (dynamic in both component carrier and time dimension) HARQ codebook for CA with same TTI on all component carriers. Re- use counter/total DAI mechanism from LTE feCA.

Proposal: Do not support fixed (fixed in component carrier dimension, dynamic in time dimension) HARQ codebook for CA with different TTIs across component carriers.

Proposal: Support dynamic (dynamic in both component carrier and time dimension) HARQ codebook for CA with different TTIs across component carriers. Re-use counter/total DAI mechanism from LTE feCA. Proposal: Support dynamic (in time dimension) HARQ codebook for non-CA case with CBG. Each entry in the HARQ codebook is a bitmap which size is given by the MIMO configuration and the configured maximum number of CBG.

Proposal: Support fixed (fixed in component carrier dimension, dynamic in time dimension) HARQ codebook for CA with CBG and same TTI on all component carriers. For each TTI where at least one DL assignment is detected, the HARQ codebook entry is a bitmap which size is given by the configured number of CC, configured maximum number of CBG, and MIMO configuration.

As will be appreciated by one of skill in the art, the concepts described herein may be embodied as a method, data processing system, and/or computer program product. Accordingly, the concepts described herein may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects all generally referred to herein as a “circuit” or“module.” Furthermore, the disclosure may take the form of a computer program product on a tangible computer usable storage medium having computer program code embodied in the medium that can be executed by a computer. Any suitable tangible computer readable medium may be utilized including hard disks, CD-ROMs, electronic storage devices, optical storage devices, or magnetic storage devices.

Some embodiments are described herein with reference to flowchart illustrations and/or block diagrams of methods, systems and computer program products. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer (to thereby create a special purpose computer), special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer program instructions may also be stored in a computer readable memory or storage medium that can direct a computer or other

programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture including instruction means which implement the function/act specified in the flowchart and/or block diagram block or blocks.

The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

It is to be understood that the functions/acts noted in the blocks may occur out of the order noted in the operational illustrations. For example, two blocks shown in succession may in fact be executed substantially concurrently or the blocks may sometimes be executed in the reverse order, depending upon the functionality/acts involved. Although some of the diagrams include arrows on communication paths to show a primary direction of communication, it is to be understood that

communication may occur in the opposite direction to the depicted arrows.

Computer program code for carrying out operations of the concepts described herein may be written in an object oriented programming language such as Java® or C++. However, the computer program code for carrying out operations of the disclosure may also be written in conventional procedural programming languages, such as the "C" programming language. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer. In the latter scenario, the remote computer may be connected to the user's computer through a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).

Many different embodiments have been disclosed herein, in connection with the above description and the drawings. It will be understood that it would be unduly repetitious and obfuscating to literally describe and illustrate every combination and subcombination of these embodiments. Accordingly, all embodiments can be combined in any way and/or combination, and the present specification, including the drawings, shall be construed to constitute a complete written description of all combinations and subcombinations of the embodiments described herein, and of the manner and process of making and using them, and shall support claims to any such combination or subcombination.

Abbreviations that may be used in the preceding description include:

Abbreviation Description

ARQ Automatic Repeat Request

CBG Code block group

CRC Cyclic Redundancy Check

DAI Downlink Assignment Indicator

DCI Downlink Control Information

LCD Largest Common Divisor

HARQ Hybrid Automatic Repeat Request

UCI Uplink Control Information

It will be appreciated by persons skilled in the art that the embodiments described herein are not limited to what has been particularly shown and described herein above. In addition, unless mention was made above to the contrary, it should be noted that all of the accompanying drawings are not to scale. A variety of modifications and variations are possible in light of the above teachings without departing from the scope of the following claims.

Claims

What is claimed is:

1. A requesting node (16, 22) configured to communicate with a responding node (22, 16), the requesting node (16, 22) comprising a radio interface (62, 82) and processing circuitry (68, 84) configured to cause the requesting node (16, 22) to:

signal to the responding node (22, 16), a request condition indicator, the request condition indicator associated with a configuration of at least one hybrid automatic repeat request, HARQ, request condition and the request condition indicator instructing the responding node (22, 16) to prepare and send at least one HARQ acknowledgment/non-acknowledgement, A/N, message according to the at least one HARQ request condition.

2. The requesting node (16, 22) of Claim 1, wherein the requesting node (16, 22) is a network node (16), and the processing circuitry (68) is further configured to communicate the configuration of the at least one HARQ request condition to the responding node (22, 16).

3. The requesting node (16, 22) of Claim 1, wherein the requesting node (16, 22) is a wireless device, WD (22), and the radio interface (82) is configured to communicate an uplink, UL, transmission, the signaling of the request condition indicator associated with the UL transmission.

4. The requesting node (16, 22) of any one of Claims 1-3, wherein the at least one HARQ request condition includes a set of HARQ request conditions and the signalled request condition indicator indicates at least one HARQ request condition of the set of HARQ request conditions.

5. The requesting node (16, 22) of any one of Claims 1-4, wherein the configuration of the at least one HARQ request condition includes at least one range of HARQ process identifiers, IDs, for which the responding node is to prepare and send the at least one HARQ A/N message.

6. The requesting node (16, 22) of Claim 5, wherein the at least one range includes a non-contiguous range of HARQ process IDs for which the responding node is to prepare and send the at least one HARQ A/N message.

7. The requesting node (16, 22) of Claim 5 or 6, wherein the at least one range includes a contiguous range HARQ process IDs for which the responding node is to prepare and send the at least one HARQ A/N message.

8. The requesting node (16, 22) of any one of Claims 1-7, wherein the at least one HARQ request condition includes a request to prepare and send the at least one HARQ A/N message for all HARQ process IDs associated with a communication channel.

9. The requesting node (16, 22) of any one of Claims 1-7, wherein the at least one HARQ request condition includes a request that no HARQ A/N message is to be prepared and sent for any HARQ process IDs associated with a communication channel.

10. The requesting node (16, 22) of any one of Claims 1-9, wherein the processing circuitry (68, 84) is configured to at least one of receive and configure the at least one HARQ request condition via at least one of higher layer signaling and radio resource control, RRC, signaling.

11. The requesting node (16, 22) of any one of Claims 1-10, wherein the radio interface (62, 82) is further configured to receive the at least one HARQ A/N message according to the at least one HARQ request condition.

12. The requesting node (16, 22) of any one of Claims 1-11, wherein the at least one HARQ A/N message is a HARQ feedback message with a bit length, the bit length based at least in part on a number of HARQ process IDs satisfying the at least one HARQ request condition indicated by the request condition indicator.

13. The requesting node (16, 22) of any one of Claims 1-12, wherein the at least one HARQ A/N message is a HARQ feedback message with a bit length, the bit length based at least in part on at least one of a codeword configuration and a code block group, CBG, configuration.

14. The requesting node (16, 22) of Claim 1, wherein the at least one HARQ A/N message is associated with at least one HARQ process identifier and a predetermined time period and if a communication associated with the at least one HARQ process identifier is not received within the predetermined time period, a HARQ non-acknowledgement is reported for the at least one HARQ process identifier.

15. A method performed by a requesting node (16, 22) configured to communicate with a responding node, the method comprising:

signaling (S134) to the responding node, a request condition indicator, the request condition indicator associated with a configuration of at least one hybrid automatic repeat request, HARQ, request condition and the request condition indicator instructing the responding node to prepare and send at least one HARQ acknowledgment/non-acknowledgement, A/N, message according to the at least one HARQ request condition.

16. The method of Claim 15, further comprising the requesting node (16, 22) communicating the configuration of the at least one HARQ request condition to the responding node, the requesting node (16, 22) being a network node (16).

17. The method of Claim 15, further comprising the requesting node (16, 22) communicating an uplink, UL, transmission, the signaling of the request condition indicator associated with the UL transmission and the requesting node (16, 22) being a wireless device, WD (22).

18. The method of any one of Claims 15-17, wherein the at least one HARQ request condition includes a set of HARQ request conditions and the signalled request condition indicator indicates at least one HARQ request condition of the set of HARQ request conditions.

19. The method of any one of Claims 15-18, wherein the configuration of the at least one HARQ request condition includes at least one range of HARQ process identifiers, IDs, for which the responding node is to prepare and send the at least one HARQ A/N message.

20. The method of Claim 19, wherein the at least one range includes a non contiguous range of HARQ process IDs for which the responding node is to prepare and send the at least one HARQ A/N message.

21. The method of Claim 19 or 20, wherein the at least one range includes a contiguous range HARQ process IDs for which the responding node is to prepare and send the at least one HARQ A/N message.

22. The method of any one of Claims 15-21, wherein the at least one HARQ request condition includes a request to prepare and send the at least one HARQ A/N message for all HARQ process IDs associated with a communication channel.

23. The method of any one of Claims 15-21 wherein the at least one HARQ request condition includes a request that no HARQ A/N message is to be prepared and sent for any HARQ process IDs associated with a communication channel.

24. The method of any one of Claims 15-23, wherein the configuration of the at least one HARQ request condition is performed by at least one of receiving and configuring the at least one HARQ request condition via at least one of higher layer signaling and radio resource control, RRC, signaling.

25. The method of any one of Claims 15-24, further comprising receiving the at least one HARQ A/N message according to the at least one HARQ request condition.

26. The method of any one of Claims 15-25, wherein the at least one HARQ A/N message is a HARQ feedback message with a bit length, the bit length based at least in part on a number of HARQ process IDs satisfying the at least one HARQ request condition indicated by the request condition indicator.

27. The method of any one of Claims 15-26, wherein the at least one HARQ A/N message is a HARQ feedback message with a bit length, the bit length based at least in part on at least one of a codeword configuration and a code block group, CBG, configuration.

28. The method of Claim 15, wherein the at least one HARQ A/N message is associated with at least one HARQ process identifier and a predetermined time period and if a communication associated with the at least one HARQ process identifier is not received within the predetermined time period, a HARQ non acknowledgement is reported for the at least one HARQ process identifier.

29. A responding node (22, 16) configured to communicate with a requesting node (16, 22), the responding node (16, 22) comprising a radio interface (62, 82) and processing circuitry (68, 84) configured to:

receive a request condition indicator, the request condition indicator associated with a configuration of at least one hybrid automatic repeat request, HARQ, request condition; and

based at least in part on the received request condition indicator, prepare and send at least one HARQ acknowledgment/non-acknowledgement, A/N, message according to the at least one HARQ request condition.

30. The responding node (22, 16) of Claim 29, wherein the radio interface is further configured to receive the configuration of the at least one HARQ request condition from the requesting node (16, 22), the requesting node (16, 22) being a network node (16) and the responding node (22, 16) being a wireless device, WD (22).

31. The responding node (22, 16) of Claim 29, wherein the responding node (22, 16) is a network node (16) and the received request condition indicator is associated with an uplink, UL, transmission.

32. The responding node (22, 16) of any one of Claims 29-31, wherein the at least one HARQ request condition includes a set of HARQ request conditions and the received request condition indicator indicates at least one HARQ request condition of the set of HARQ request conditions.

33. The responding node (22, 16) of any one of Claims 29-32, wherein the configuration of the at least one HARQ request condition includes at least one range of HARQ process identifiers, IDs, for which the responding node (22, 16) is to prepare and send the at least one HARQ A/N message.

34. The responding node (22, 16) of Claim 33, wherein the at least one range includes a non-contiguous range of HARQ process IDs for which the responding node (22, 16) is to prepare and send the at least one HARQ A/N message.

35. The responding node (22, 16) of Claim 33 or 34, wherein the at least one range includes a contiguous range HARQ process IDs for which the responding node (22, 16) is to prepare and send the at least one HARQ A/N message.

36. The responding node (22, 16) of any one of Claims 29-35, wherein the at least one HARQ request condition includes a request to prepare and send the at least one HARQ A/N message for all HARQ process IDs associated with a communication channel.

37. The responding node (22, 16) of any one of Claims 29-35, wherein the at least one HARQ request condition includes a request that no HARQ A/N message is to be prepared and sent for any HARQ process IDs associated with a

communication channel.

38. The responding node (22, 16) of any one of Claims 29-37, wherein the configuration of the at least one HARQ request condition is performed by at least one of receiving and configuring via at least one of higher layer signaling and radio resource control, RRC, signaling.

39. The responding node (22, 16) of any one of Claims 29-38, wherein the at least one HARQ A/N message is a HARQ feedback message with a bit length, the bit length based at least in part on a number of HARQ process IDs satisfying the at least one HARQ request condition indicated by the request condition indicator.

40. The responding node (22, 16) of any one of Claims 29-39, wherein the at least one HARQ A/N message is a HARQ feedback message with a bit length, the bit length based at least in part on at least one of a codeword configuration and a code block group, CBG, configuration.

41. The responding node (22, 16) of Claim 29, wherein the at least one HARQ A/N message is associated with at least one HARQ process identifier and a predetermined time period and if a communication associated with the at least one HARQ process identifier is not received within the predetermined time period, a HARQ non-acknowledgement is reported for the at least one HARQ process identifier.

42. A method performed by a responding node (22, 16), the method comprising:

receiving (S136) a request condition indicator, the request condition indicator associated with a configuration of at least one hybrid automatic repeat request, HARQ, request condition; and based at least in part on the received request condition indicator, preparing and sending (S138) at least one HARQ acknowledgment/non-acknowledgement, A/N, message according to the at least one HARQ request condition.

43. The method of Claim 42, further comprising receiving the

configuration of the at least one HARQ request condition from the requesting node (16, 22), the requesting node (16, 22) being a network node (16) and the responding node (22, 16) being a wireless device, WD (22).

44. The method of Claim 42, wherein the responding node (22, 16) is a network node (16) and the request condition indicator is associated with an uplink,

UL, transmission.

45. The method of any one of Claims 42-44 wherein the at least one HARQ request condition includes a set of HARQ request conditions and the received request condition indicator indicates at least one HARQ request condition of the set of HARQ request conditions.

46. The method of any one of Claims 42-45, wherein the configuration of the at least one HARQ request condition includes at least one range of HARQ process identifiers, IDs, for which the responding node (22, 16) is to prepare and send the at least one HARQ A/N message.

47. The method of Claim 46, wherein the at least one range includes a non contiguous range of HARQ process IDs for which the responding node (22, 16) is to prepare and send the at least one HARQ A/N message.

48. The method of Claim 46 or 47 wherein the at least one range includes a contiguous range HARQ process IDs for which the responding node (22, 16) is to prepare and send the at least one HARQ A/N message.

49. The method of any one of Claims 42-48, wherein the at least one HARQ request condition includes a request to prepare and send the at least one HARQ A/N message for all HARQ process IDs associated with a communication channel.

50. The method of any one of Claims 42-48, wherein the at least one HARQ request condition includes a request that no HARQ A/N message is to be prepared and sent for any HARQ process IDs associated with a communication channel.

51. The method of any one of Claims 42-50, wherein the configuration of the at least one HARQ request condition is performed by at least one of receiving and configuring via at least one of higher layer signaling and radio resource control, RRC, signaling.

52. The method of any one of Claims 42-51, wherein the at least one HARQ A/N message is a HARQ feedback message with a bit length, the bit length based at least in part on a number of HARQ process IDs satisfying the at least one HARQ request condition indicated by the request condition indicator.

53. The method of any one of Claims 42-52, wherein the at least one HARQ A/N message is a HARQ feedback message with a bit length, the bit length based at least in part on at least one of a codeword configuration and a code block group, CBG, configuration.

54. The method of Claim 42, wherein the at least one HARQ A/N message is associated with at least one HARQ process identifier and a predetermined time period and if a communication associated with the at least one HARQ process identifier is not received within the predetermined time period, a HARQ non acknowledgement is reported for the at least one HARQ process identifier.