HARQ

- Hybrid Automatic Repeat Request.

It is combination of ARQ and FEC (Forward Error Correction)

A typical communication channel has imperfections. Packets get lost or corrupted. When
the receiver detects errors, it discards the erroneous packet and requests the sender to
retransmit it. This is called Automatic Repeat Request (ARQ). Error detection is usually
done using Cyclic Redundancy Check (CRC) bits. The RLC layer uses an ARQ protocol
for Acknowledged Mode.
However, if errors are within certain limits, the receiver can not only detect but also correct
errors. This is possible if the sender employs Error-Correcting Codes (ECCs). These
include parity bits that help in correcting errors in information bits. The technique is called
Forward Error Correction (FEC). FEC avoids ARQ retransmissions but parity bits are
an overhead.
Hybrid ARQ is a technique the combines both ARQ and FEC. Packet errors are corrected
where possible. Where not possible, retransmission is requested. First and subsequent
packet transmissions are combined to increase the chance of correct decoding. The MAC
layer uses a HARQ protocol.
In 5G NR, HARQ operates at both MAC and PHY layers. Retransmissions occur at the
MAC layer. PHY layer at the receiver combines one or more transmissions to increase the
chances of correct decoding.

Why do we need HARQ in 5G when RLC and PDCP do retransmissions?

- RLC and PDCP being higher layers, the feedback signalling is slower.
HARQ retransmissions at MAC react faster and improve performance for delay-sensitive
applications.
RLC retransmissions are limited to logical channels in Acknowledged Mode (AM). HARQ
offers retransmission capability for RLC UM and TM.
PDCP retransmissions are useful during inter-gNB handovers.

HARQ re-transmissions can benefit from either Chase Combining or Incremental

Redundancy.

Chase Combining HARQ

Same information and parity bits are retransmitted each time. This technique is also called
as repetition coding as same coded information is transmitted all the time.
Moreover, at receiver previous packets are stored in a buffer; so that retransmitted packets
are summed up with previously received erroneous packets. The technique used at receiver
to sum the packets is the simple MRC (maximum Ratio Combining) technique.
Incremental redundancy HARQ
Multiple different set of code bits are generated for the same information bits used in a
packet unlike chase combining type.
This scheme in which some additional redundant information bits are transmitted in each
re-transmission and receiver needs to decode on each re-transmission is the IR type II
HARQ.
In type III HARQ, each re-transmitted packet is self-decodable.
The performance of Incremental Redundancy is similar to the performance of Chase
Combining when the coding rate is low. Incremental Redundancy performs better than
Chase Combining when the coding rate is high.

The HARQ protocol relies upon the sender receiving acknowledgements from the receiver.
The round-trip time, which includes both the sender and receiver processing times as well
as the propagation delays, means that these acknowledgements are not received
instantaneously.
The sender becomes inactive while waiting for the acknowledgement, so the average
throughput is relatively low. This corresponds to using a single Stop And Wait (SAW)
process. A SAW process stops and waits for an acknowledgement before proceeding to
transfer any further data.

Multiple parallel SAW processes are used to avoid the round-trip time having an impact
upon throughput, i.e. additional SAW processes transfer data while the first SAW process
is waiting for its acknowledgement. Larger round trip times require an increased number of
parallel SAW processes

These SAW processes are also referred to as HARQ processes. The HARQ entity within
the MAC layer manages these multiple HARQ processes.
The sender buffers the transmitted data until a positive acknowledgement has been
received in case a re-transmission is required. Data is cleared from the transmit buffer once
a positive acknowledgement has been received or the maximum number of allowed
retransmissions has been reached. New data can be sent by a specific HARQ process once
its transmit buffer has been cleared.

DOWNLINK HARQ
Downlink HARQ refers to the transfer of downlink data on the PDSCH with HARQ
acknowledgements returned on either the PUCCH or the PUSCH.
Each serving cell has its own HARQ entity and its own set of HARQ processes.
A single HARQ process can be associated with either 1 or 2 transport blocks in the
downlink. Each of these transport blocks can include multiple Code Block Groups (CBG).
Downlink HARQ is responsible for achieving reliable downlink data transfer by managing
the re-transmission of transport blocks or the re-transmission of individual Code Block
Groups.
Downlink HARQ is asynchronous which means that there is no fixed timing pattern for
each HARQ process. Instead, the Base Station must signal the identity of the relevant
HARQ process with each downlink resource allocation. Asynchronous HARQ increases
the signalling overhead but also increases flexibility because re-transmissions do not have
to be scheduled during specific slots.

Dynamic downlink resource allocations are provided on the PDCCH using Downlink
Control Information (DCI) Formats 1_0 and 1_1 . These DCI Formats include key
information for the operation of downlink HARQ:
1. HARQ Process Number
2. PUCCH Resource Indicator
3. New Data Indicator (NDI)
4. Downlink Assignment Index (DAI)
5. Redundancy Version (RV)
6. CBG Transmission Information (CBGTI)
7. PDSCH-to-HARQ Feedback Timing Indicator
8. CBG Flushing Information (CBGFI)
The error-correcting code used in 5G NR is Low Density Parity Check (LDPC) code. For
LDPC, the order in which RVs are received matters because some RVs can't be decoded on
their own. The default order is 0, 2, 3 and 1. RV0 and RV3 are self-decodable. The first
transmission RV0 includes all information bits

HARQ ACK CODEBOOKS

The HARQ ACK codebook defines the format used to signal a set of HARQ
acknowledgements to the Base Station. The codebook allows the UE to multiplex the
HARQ acknowledgements from multiple slots, multiple carriers, multiple Transport
Blocks, and multiple Code Block Groups (CBG) within a single transmission. It is
important that both the UE and Base Station share the same understanding of the codebook
format to ensure that each acknowledgement is linked to the appropriate transmission.

3GPP has specified 2 categories of codebook:

1. Type I codebook (semi-static): the size of this codebook is fixed by information
provided by RRC signalling.
2. Type 2 codebook (dynamic): the size of this codebook changes according to the number
of resource allocations.

The Base Station configures the use of a specific codebook category using the pdsch-
HARQ-ACK-Codebook information clement.
The size of a semi-static codebook is defined as the sum of all possible transmission
opportunities within a specific time window.
The time window across which the transmission opportunities are summed depends upon
the Downlink Control Information (DCI) format used to allocate the PDSCH resources.
The dynamic (Type 2) codebook helps to improve efficiency by excluding codebook entries
which correspond to unused transmission opportunities. This type of codebook poses a
challenge in terms of maintaining the correct relationship between acknowledgement and
transmission.

UPLINK HARQ
Uplink HARQ refers to the transfer of uplink data on the PUSCH with HARQ
acknowledgements returned on the PDCCH
Uplink HARQ does not require the use of the codebooks. Instead, acknowledgements are
returned individually on the PDCCH.

Each serving cell has its own HARQ entity and its own set of HARQ processes. AUE is
required to support 16 HARQ processes per serving cell:
1. In the case of dynamic resource allocations, the Base Station uses PDCCH DCI Format
0_0 or 0_1 to specify the HARQ process associated with a PUSCH transmission. In this
case, it is not necessary to configure the UE with a specific number of HARQ processes
but the UE assumes that the Base Station can allocate up to 16 processes.
2. In the case of Configured Grants, the UE does not receive the PDCCH in advance of
every PUSCH transmission. The UE is responsible for calculating the HARQ Process
Identity associated with each transmission
HARQ Process ID = [ROUNDDOWN (Current Symbol / periodicity)] MOD
nrofHARQ-Processes

where, Current_ Symbol = (SFN x SlotsPerFrame x SymbolsPerSlot) + (SlotNumber x

SymbolsPerSlot) + SymbolNumber.
 This information is given by BS in ConfiguredGrantConfig information element.

The PDSCH supports the transmission of up to 2 Transport Blocks using up to 8 layers. In

contrast, the PUSCH supports the transmission of 1 Transport Block using up to 4 layers.
This means that only a single Transport Block needs to be acknowledged after each
transmission

Similar to the downlink, each transport block can include multiple Code Block Groups
(CBG). Uplink HARQ is responsible for achieving reliable uplink data transfer by
managing the re-transmission of transport blocks or the re-transmission of individual Code
Block Groups

Similar to the downlink, uplink HARQ is asynchronous which means that there is no fixed
timing pattern for each HARQ process. Instead, the Base Station must signal the identity of
the relevant HARQ process with each uplink resource allocation (except when
using Configured Grants).
Asynchronous HARQ increases the signalling overhead but also increases flexibility
because retransmissions do not have to be scheduled during specific slots.

Dynamic uplink resource allocations are provided on the PDCCH using Downlink Control
Information (DCI) Formats 0_0 and 0_l.

These DCI Formats include key information for the operation of uplink HARQ:
1. HARQ Process Number
2. Redundancy Version (RV)
3. New Data Indicator (NDI)
4. CBG Transmission Information (CBGTI)

How is 5G NR HARQ different from 4G/LTE HARQ?

In LTE and 5G NR, retransmissions can be adaptive in uplink and downlink.
The use of code blocks is common to LTE and 5G NR but 5G NR has introduced CBG-
based retransmissions.
In 5G NR, HARQ is asynchronous in downlink and uplink. In 4G/LTE, HARQ is
asynchronous in downlink and synchronous in the uplink. However, Release 13 introduced
asynchronous UL HARQ that's used by License-Assisted Access.
Synchronous HARQ is not suitable in 5G NR due to dynamic TDD and operation in
unlicensed spectra.
In LTE synchronous UL HARQ, the same process ID is used every eighth subframe. An
LTE UE responds with HARQ ACK 3ms after receiving the downlink data. 5G NR has
more flexibility to respond faster for URLLC use cases. In fact, first transmission and its
retransmission can happen within 1ms.
In LTE, Physical HARQ Indicator Channel (PHICH) is a dedicated downlink channel to
carry HARQ ACK/NACK for uplink traffic carried on PUSCH. Such a channel is not
required in 5G NR since HARQ is asynchronous.
In LTE, the number of HARQ processes was limited to 8 but this is increased to 16 in 5G
NR.