Introduction

5G NR (New radio) has several retransmission systems using three different layers in the protocol stack:

• MAC protocol: It implements a fast retransmission system with delay less than 1ms in new radio, called HARQ (Hybrid Automatic Repeat reQuest).
• RLC protocol: Even though HARQ is present at MAC but there might still be some possibility of errors in the feedback system. So, for dealing with those errors, RLC has a slow retransmission system but with a feedback protected by CRC. Compared to the HARQ acknowledgments, the RLC status reports are transmitted relatively infrequently.
• PDCP protocol: This will guarantee in-sequence delivery of user data and it is mainly used during handover as RLC and MAC buffers are flushed when a handover is executed.

NR uses an asynchronous hybrid-ARQ protocol in both downlink and uplink, that is, the hybrid-ARQ process which the downlink or uplink transmission relates to is explicitly signaled as part of the downlink control information (DCI). The hybrid-ARQ mechanism in the MAC layer targets very fast retransmissions and, consequently, feedback on success or failure of the downlink transmission is provided to the gNB after each received transport block (for uplink transmission no explicit feedback needs to be transmitted as the receiver and scheduler are in the same node).

HARQ is implemented to correct the erroneous packets coming from PHY layer. If the received data is erroneous then the receiver buffers the data and requests for a re-transmission from the sender. When the receiver receives the re-transmitted data, it then combines it with buffered data prior to channel decoding and error detection. This helps in the performance of re-transmissions. For this to work, the sending entity need to buffer the transmitted data until the ACK is received since the data needs to be retransmitted in case a NACK is received.

HARQ is a stop and wait (SAW) protocol with multiple processes. The protocol will continue to repair one transmission without hindering other ongoing transmissions which can continue in parallel.

Why multiple SAW processes are required?

Once a packet is sent from a process, it waits for an ACK/NACK. While it is waiting for an ACK/NACK in the active state, no other work can be done by the same process leading to reduced performance. So, if we have multiple such processes working in parallel, throughput can be increased by making other processes work at the same time on other packets, while a process is in waiting state for ACK/NACK.

Differences with LTE HARQ

• New radio is using an asynchronous protocol in both UL and DL, which is different from LTE, where the protocol was synchronous in UL; UE should reply with an ACK/NACK after 3ms of receiving the DL data. The gNB knows that when the ACK/NACK is expected. In NR, the report timing is not fixed to increase the flexibility which is important for URLLC services.
• PHICH (Physical HARQ Indicator channel) was used in LTE to handle uplink retransmissions and was tightly coupled to the use of a synchronous HARQ protocol, but since the NR HARQ protocol is asynchronous in both uplink and downlink the PHICH is not needed in NR.
• In LTE, Non-adaptive retransmissions were triggered by a negative acknowledgement on the PHICH, which used the same set of resources as the previous transmission i.e. the modulation scheme and the set of allocated resource blocks remains unchanged. Only Redundancy version used to change between transmissions. But in NR, PHICH is not there and retransmissions are adaptive that can be triggered by DCI. NDI flag retriggers a transmission if its value is toggled relative to previous transmission.
• Maximum number of HARQ processes was set to 8 in LTE but is increased to 16 in NR. This was motivated by shorter time slot and increased use of remote radio heads that will increase the round-trip time slightly.

Reasons why NR HARQ is asynchronous in both UL and DL:

• Synchronous HARQ operation does not allow dynamic TDD.
• Operation in unlicensed spectra (part of later NR releases) is more efficient with asynchronous operation as it is not guaranteed that the radio resources are available at the time for a synchronous transmission.

Hybrid ARQ with Soft combining

The hybrid-ARQ protocol is the primary way of handling retransmissions in NR. In case of an erroneously received packet, a retransmission is requested. However, despite it not being possible to decode the packet, the received signal still contains information, which is lost by discarding erroneously received packets. This shortcoming is addressed by hybrid-ARQ with soft combining. In hybrid- ARQ with soft combining, the erroneously received packet is stored in a buffer memory and later combined with the retransmission to obtain a single, combined packet that is more reliable than its constituents. Decoding of the error-correction code operates on the combined signal. Both Chase combining and Incremental Redundancy methods were proposed initially, but it is Incremental Redundancy that is getting used in NR.

Difference between Chase combining and Incremental Redundancy

In Chase combining, the physical layer applies the same puncturing pattern to both the original transmission and each retransmission. This results in retransmissions which include the same set of physical layer bits as the original transmission. Systematic bit remains the same even in the subsequent transmission. Only Parity 1 and Parity 2 bits are punctured. Benefits of chase combining are its simplicity and lower UE memory requirements.

In Incremental Redundancy, the physical layer applies different puncturing patterns to the original transmission and retransmission. This results in retransmission which include a different set of physical layer bits to the original transmission. 1^st transmission provides the systematic bits with the greatest priority while subsequent retransmissions can provide either the systematic or the parity 1 and parity 2 bits with greatest priority. Drawbacks associated with Incremental Redundancy are its increased complexity and increased UE memory requirements.

Performance wise, incremental redundancy is like chase combining when the coding rate is low i.e. there is less puncturing. But, when there is an increased quantity of puncturing, the performance of incremental redundancy becomes greater i.e. when the coding rate is high because channel coding gain is greater than soft combining gain.

Codeblock Groups

Due to increased data rate in NR, when several gigabits per second is transmitted, the size of the transport block will be too large to handle. So, these transport blocks will be split into codeblocks, each with its own 24 bits CRC. This principle made it possible to handle large transport block in parallel channel coders/decoders.

In NR, there can be hundreds of codeblocks in a transport block. If only one or a few of them are in error, retransmitting the whole transport block results in a low spectral efficiency compared to retransmitting only the erroneous codeblocks.

To reduce the control signaling overhead, 2,4,6 or 8 blocks can be grouped together to Codeblock Groups (CBG). In case of an error in one Codeblock, only the Codeblock group to which the faulty Codeblock belongs, need to be retransmitted instead of whole transport block. If per-Code Block Group (per-CBG) retransmission is configured, feedback is provided per CBG instead of per transport block and only the erroneously received codeblock groups are retransmitted, which consumes less resources than retransmitting the whole transport block.

HARQ in Downlink

The gNB will send a scheduling message to the UE that indicates where the user data is located and how it is coded. Downlink Control Information (DCI) will indicate which HARQ process to be used by the UE. Since transmissions and retransmissions are scheduled using the same framework, the UE needs to know whether the transmission is a new transmission, in which case the soft buffer should be flushed, or a retransmission, in which case soft combining should be performed. For that purpose, a New Data Indicator (NDI) bit will also be set to indicate that this will be new data and the receive buffer should be flushed before loading the user data.

Upon reception of a downlink scheduling assignment, UE checks the new-data indicator to determine whether the current transmission should be soft combined with the received data currently in the soft buffer for the HARQ process in question, or if the soft buffer should be cleared. UE receives the user data and starts to calculate a checksum of the single transport block and if used, the included codeblocks. After completing the calculation, the UE follows the timing order of the UL report and sends an HARQ report indicating ACK or NACK. In case of NACK, the gNB will start to schedule a retransmission of the data.

Now if per- CBG retransmissions are configured, UE needs to know which CBGs are retransmitted and whether the corresponding soft buffer should be flushed or not. For this purpose, two additional fields are present in the DCI. 1) CBG Transmit Indicator (CBGTI), which is a bitmap indicating whether a certain CBG is present in the downlink transmission or not and 2) CBGFI which is a single bit, indicating whether the CBGs indicated by the CBGTI should be flushed or whether soft combining should be performed.

The result of the decoding operation—a positive acknowledgment in the case of a successful decoding and a negative acknowledgment in the case of unsuccessful decoding—is fed back to the gNB as part of the uplink control information. If CBG retransmissions are configured, a bitmap with one bit per CBG is fed back instead of a single bit representing the whole transport block.

DCI Format 1-0 and 1-1 for downlink scheduling assignment contains HARQ related information as:

• Hybrid-ARQ process number (4 bit), informing the device about the hybrid-ARQ process to use for soft combining.
• Downlink assignment index (DAI, 0, 2, or 4 bit), only present in the case of a dynamic hybrid-ARQ codebook. DCI format 1_1 supports 0, 2, or 4 bits, while DCI format 1_0 uses 2 bits.
• HARQ feedback timing (3 bit), providing information on when the hybrid- ARQ acknowledgment should be transmitted relative to the reception of the PDSCH.
• CBG transmission indicator (CBGTI, 0, 2, 4, 6, or 8 bit), indicating the code block groups. Only present in DCI format 1_1 and only if CBG retransmissions are configured.
• CBG flush information (CBGFI, 0_1 bit), indicating soft buffer flushing. Only present in DCI format 1_1 and only if CBG retransmissions are configured.

HARQ in Uplink

The gNB sends a scheduling message to the UE indicating resources to be used for uplink transmission, which also has HARQ process number. The UE will follow the order and send the transport block (or Codeblock group) as per the scheduling grant. The gNB will calculate and verify the checksum for the correctness of the message. The gNB will order the UE to retransmit the transport block again with a new scheduling grant, if an error id detected. In order to indicate a retransmission is required, same HARQ process number is sent with NDI bit set to no, which will be interpreted by the UE as retransmission.     

The CBGTI is used in a similar way as in the downlink to indicate the codeblock groups to retransmit in the case of per-CBG retransmission. Note that no CBGFI is needed in the uplink as the soft buffer is located in the gNB which can decide whether to flush the buffer or not, based on the scheduling decisions.

DCI format 0-0 and 0-1 for uplink scheduling grants also contains HARQ related information as:

• Hybrid ARQ process number (4 bit), informing the device about the hybrid-ARQ process to (re)transmit.
• Downlink assignment index (DAI), used for handling of hybrid-ARQ codebooks in case of UCI transmitted on PUSCH. Not present in DCI format 0_0.
• CBG transmission indicator (CBGTI, 0, 2, 4, or 6 bit), indicating the code block groups to retransmit. Only present in DCI format 0_1 and only if CBG retransmissions are configured.

Timing of UL reports

The timing of the UL HARQ reports was fixed in LTE as 3ms, which was way too much for 5G and URLLC services. The solution in NR is to have a flexible solution that can be modified between different service requirements and when new HW is developed. The gNB informs the UE about the timing in a ‘HARQ timing’ field in the Downlink Control Information (DCI). This flexibility was also required in dynamic TDD when the directions of the slots is flexible (UL/DL). The “HARQ Timing” field contains a 3-bit pointer to an RRC Configured Table, which will indicate the timing between the scheduling message (The data this is included in the slot) and the related UL report. This will also allow for the gNB to order several transmissions to be grouped together or to order the UE to report as quickly as possible (for delay sensitive services). This information provides the UE with the information when to send the HARQ report back to the gNB.

Now where in the frequency band the information should be sent (Physical Uplink Control Channel, PUCCH)? The answer is that RRC protocol configures another table and the UE will get a pointer to the table in the scheduling message. This will tell the UE where to send the HARQ report.

Multiple Bits in HARQ reports

5G NR supports very high bitrates and multiple simultaneous carriers. A UE can be configured to use carrier aggregation, spatial multiplexing and dual connectivity at the same time. This means that UE should be able to report the success or failure of the transmission of multiple transport blocks at the same time. To do this, there are two ways defined in the standard:

• Semi-static HARQ acknowledgement codebook

Below example can be considered to understand semi-static HARQ acknowledgement codebook:

The codebook which is configured by RRC protocol is valid for a specific time span. In the example, it is valid for 3 slots. The upper carrier is configured to use 4 codeblocks per transport block, the middle carrier uses spatial multiplexing with either one or two transport blocks per slot. Finally, the lower carrier is using transmission with 1 transport block per slot. A configured table is shown below the figure where A/N means Ack/Nack is transmitted while only N means NACK is sent. Negative acknowledgements are always sent for Non-scheduled slots which will help the gNB to detect that a scheduling message was not received by the UE. When the UE reports, there will always be 21 bits in the report as there are 7 rows in the table and 3 slots.

• Dynamic HARQ acknowledgement codebook

As you can see above, the drawback with semi-static codebook was that the number of bits can be rather high in case of, for example carrier aggregation with large number of component carriers. This is the reason 3GPP adopted dynamic HARQ codebook as default approach of reporting. The principle is to only report those transport blocks or codeblock groups that are actually sent, which will reduce the overhead in the reporting. However, there is a problem with this reporting method as the scheduling message sent to the UE may be lost on one of the carriers (or many carriers). This might create a situation where gNB and the UE do not agree on how many transport blocks to report. To avoid this situation, the scheduling message will indicate how many transport blocks or codeblock groups to report.

In the above example, there are 5 carrier in the carrier aggregation scenario. For every scheduling message sent on each carrier, the “cDAI” tells the number of transport block (Counter Downlink Assignment). For detecting lost scheduling messages, the total number of scheduled carriers is also indicated as “tDAI” (Total Downlink Assignment). The figure shows that the number 3, sent on carrier #3, gets lost and is not detected/decoded by the UE. This will be detected easily by the UE as the total DAI indicates that the last number should be 6 but the UE has only received number 0 to 5. The HARQ report in this case will consist of 12 bits, one for each received transport block during the time span of the codebook.

Note: To know more, Please refer to http://www.sharetechnote.com/html/5G/5G_HARQ.html

References:

• https://www.etsi.org/deliver/etsi_ts/138300_138399/138300/15.09.00_60/ts_138300v150900p.pdf
• https://www.etsi.org/deliver/etsi_ts/138300_138399/138321/15.08.00_60/ts_138321v150800p.pdf
• “5G NR – The next generation wireless access technology” – By Erik Dahlman, Stefan Parkvall, Johan Sköld
• http://www.sharetechnote.com