Overview

HARQ is used for facilitating fast error detection and correction. HARQ is a stop and wait protocol; subsequent transmission can take place only after receiving ACK/NACK from the receiving entity. In case an ACK is received a new transmission is done else a retransmission is done. This scheme can be improved by using multiple channels for supporting HARQ service.
In LTE, HARQ is implemented as MAC level (L1) module called HARQ entity. HARQ entity is associated with N HARQ processes to implement N stop and wait HARQ protocol. The specifications for LTE-HARQ are in development stage and many of the topics discussed below are yet being evaluated for final acceptance.

Scheduling HARQ

In the Downlink, HARQ is asynchronous and the schedule for HARQ transmissions is not predeclared to the UEs. When the HARQ blocks are transmitted they need to be accompanied by control information such as HARQ process ID, new transmission/retransmission.
This scheme has following advantages:

Complete flexibility of scheduling different data flows as per their respective priorities
In case of frequency selective fading, link adaptation is possible. As the resources for HARQ processes are not predetermined, the blocks (new transmission / retransmission) can be modulated and coded as per the link conditions.

In Uplink the HARQ transmission is synchronous, which means that the HARQ blocks are predetermined for transmission and retransmission. The modulation, coding scheme for the blocks is predetermined by the eNB. Thus for Uplink transmission, there is no need for transmitting control information along with the HARQ data blocks. The modulation and coding scheme for the different UEs may be tuned by the eNB based on the reports submitted by the UEs.

HARQ in downlink

The downlink HARQ transmission is asynchronous; the UE receives the information about HARQ transmissions on control channel. Downlink assignments and HARQ information is transmitted on PDCCH and the TB (transport blocks) are transmitted on DL-SCH.
HARQ entity in UE deciphers the HARQ information. HARQ information consists of parameters such as HARQ process ID, New Data Indicator (NDI), Redundancy Version (RV), Transport Block (TB) size. HARQ entity maintains a number of HARQ processes, HARQ information and TB is forwarded by HARQ entity to relevant process.

A transmission is considered new transmission in case

this is first transmission ever received for this process ID or
NDI has toggled in HARQ information.

Otherwise TB is considered retransmitted.

For a new transmission, HARQ process replaces the old contents of associated HARQ buffer with the new contents. If the decoding of this data block is successful the data is handed over to disassembly and demultiplexing MAC module. If decoding fails, data is preserved in this buffer.

For retransmission, the retransmitted data is soft combined with old buffer contents. HARQ process decodes the new contents; if the decoding is successful the retransmitted block is handed over to disassembly and demultiplexing unit.
It may happen that the retransmission is done using some different coding scheme and the TB is of different size, in this case soft combining is not possible and HARQ buffer contents are replaced with the new received buffer contents.

HARQ process generates a positive ACK for the successfully decoded data and negative ACK for the unsuccessful ones.HARQ feedback has a lower priority than measurement gaps. HARQ feedback is transmitted when measurement gaps are not scheduled.

HARQ in uplink

Uplink HARQ is synchronous; UE receives the Uplink grant for transmission on control channel. The grant indicates control information such as HARQ process ID, type of transmission (new/retransmission), redundancy version.

Downlink ACK/NACK are sent on PHICH and uplink grants are sent via PDCCH.
If a PDCCH grant is received, data is considered ack/nack based on HARQ info. HARQ feedback is not considered in this case.
In case PDCCH is not received, HARQ feedback is considered. In case NACK is received – non-adaptive retransmission is planned. In case ACK is received, no non-adaptive retransmission can be planned. HARQ buffer is preserved as-is (till PDCCH grant indicative of ACK arrives)

On receiving PDCCH grant for new transmission, HARQ entity receives a PDU for transmission from “Multiplexing and assembly” module. HARQ entity delivers the PDU, uplink grant and HARQ info to HARQ process (that was indicated in control information) and instructs the HARQ process to transmit the new block. The HARQ process stores the received PDU in its HARQ buffer and sets the redundancy version IRV indicated in control information. HARQ process then instructs the PHY layer to transmit the block.

On receiving the PDCCH grant for retransmission, HARQ entity delivers uplink grant and HARQ info to relevant HARQ process and instructs it to generate an adaptive retransmission. HARQ process instructs PHY to retransmit the buffer contents as per the redundancy version instructed by eNB in control information. If max limit for retransmissions is reached HARQ process flushes the contents of buffer.

HARQ ARQ interaction

ARQ uses the knowledge from HARQ about transmission status of a MAC PDU. This interaction is useful in handling HARQ residual error cases. HARQ provides indications to ARQ block when:

HARQ transmitter reaches maximum retransmissions for a TB without getting an ACK
HARQ receiver is able to detect a transmission failure

First indication is called as NACK1 and the second one is called NACK2. We discuss the two conditions in detail in following sections.

NACK1

This situation may be caused when HARQ block transmissions could not be successfully decoded at receiver. After reaching max limit for number of retransmission MAC sends NACK1 indication to RLC layer. On getting this indication ARQ block in RLC can recode/re-segment the block for transmission.
Max number of retransmission in Uplink should be known to the eNB, as eNB has to stop scheduling retransmissions after UE has reached the max transmissions. Maximum number of retransmission suited for a connection depends on the type of QoS. For a real time traffic flow, more than 1-2 retransmissions may be unnecessary. However, for a file transfer kind of flow it would be useful to have greater number of retransmissions. This radio bearer specific max limit has to be indicted in UE reports to eNB. However, the scheme is prone to failure in case UE reports are received late/erroneously at eNB. The other option is to have a common limit for max retransmissions for all the radio bearers.

Generation of NACK1 from MAC to RLC may also be caused if an ACK from receiver is misinterpreted as NACK. This misinterpretation leads to unnecessary retransmissions.

NACK2

When HARQ receiver transmits NACK for a HARQ block, it expects the block to be retransmitted. If the receiver sees no transmission in the expected TTI or when the receiver sees the HARQ process ID rescheduled for a new transmission; the receiver knows that the NACK has been misinterpreted as ACK by the transmitter. MAC indicates this to RLC and RLC sends a control message to peer to indicate the missing block.

The scheme requires a request for resource grant for UE and eNB followed by transmission of control message. Synchronous HARQ was adopted in uplink to save on control channel resources and this control messaging becomes overhead.

This NACK2 interaction provides little performance gain compared to added complexity and has been dropped from recent versions of specifications.