HARQ(Hybrid ARQ) is pretty complicated process and not easy to understand in very detail, but it would be helpful if you have some big picture of this process. (Describing this process in very detail would not be the scope of this section.)

Let's first think about the terminology. What is H-ARQ ? Why it uses the term "Hybrid" ?

First think about the term ARQ. ARQ stands for Automatic Repeat Request and you would have heard this a lot if you had experience of studying IP communication (I think you can google a lot of tutorials on this, so I would not explain about what is ARQ here). The "H" in HARQ means "Hybrid" which implies that HARQ is a combination of "Something" and "ARQ".

Then what would be the "Something" ? The "Something" is FEC (forward error correction). FEC is also not LTE specific technology and a kind of generic error correction mechanism. So I would like you to google something about FEC.

Followings are the topics that will be described in this page.

• HARQ Structure
• HARQ Process
• For Downlink : Asynchronous Process
• For Uplink : Synchronous Process
• Adative UL HARQ Process
• Non-Adative UL HARQ Process
• Case 1 : HARQ Process for Uplink (except Msg 3)
• HARQ ProcessID Synchronization
• Synchronous and Asynchronous in Real Networks
• Reference :

HARQ Structure

Before following any HARQ timing diagram, it helps to know what a HARQ process actually holds. 36.321 models the HARQ entity as a set of parallel processes, and each one carries its own buffer and its own small set of state variables. Those variables are what the retransmission rules read and write, so every diagram later on this page is really describing changes to them.

Following is overall architecture of LTE HARQ entity. Refer to 36.321 5.4.2.1 and 5.4.2.2 for the detailed description of mechanism.

< Overall Architecture of LTE HARQ Entity >

Figure 1. The LTE HARQ entity. One switch chooses the source of the MAC PDU and a second chooses which process receives it, and every process carries the same three state variables.

• Two sources feed the entity. The Multiplexing And Assembly Entity supplies ordinary MAC PDUs, and the Msg3 Buffer supplies the Random Access message 3. The upper switch picks between them.
• The lower switch routes the chosen MAC PDU to one of the processes, drawn here as HARQ Process#1 through HARQ Process#N. The red arrows trace one MAC PDU through both switches.
• Every process box holds the same four items. A HARQ Buffer sits at the top in orange, and CURRENT_TX_NB, HARQ_FEEDBACK and CURRENT_IRV sit below it.
• The processes are parallel and independent. Each one keeps its buffer and its variables until its own transmission is acknowledged, which is what lets eight transmissions be outstanding at once.

One label in the drawing is deliberately vague. The boxes run to HARQ Process#N rather than to a fixed number, because the count is not the same everywhere. FDD uses 8, which is the figure the rest of this page works with. TDD varies with the uplink and downlink configuration, and that is why this page keeps to FDD.

The three variables are worth naming properly, because the rest of this page keeps changing them.

Those three names reappear in Figure 4, and reading the two together is the quickest way to make sense of either. The architecture says what a process stores. The flow chart says when each value changes.

• A HARQ process is a buffer plus three variables : everything the retransmission rules do is a read or a write to CURRENT_TX_NB, HARQ_FEEDBACK or CURRENT_IRV.
• Msg3 has a buffer of its own : the entity treats the Random Access message 3 as a separate source, which is why Msg3 is singled out later on this page.
• The processes are independent : each keeps its own buffer until its own transmission is acknowledged, so eight can be outstanding at the same time.

HARQ Process

A little bit different mode of HARQ process is used depending on whether it is for FDD or TDD and whether it is for Uplink and Downlink. But I will talk only about FDD case.

In FDD, we are using 8 HARQ process.

i) For Downlink : Aynchronous Process

a) it can use the 8 HARQ processes in any order (Asynchronous Process).

b) UE does not know anything about HARQ process information for DL data before it gets it. So Network send these information (Process ID, RV) in PDCCH (DCI, Refer to DCI section of this site).

ii) For Uplink : Synchronous Process

a)it have to use the specific process in a specific subframe (Synchronous Process). UE has to use the same HARQ process number every 8 subframes.

b) Since UE have to use specific HARQ process ID at specific subframe, the reciever (eNode B) knows exactly which HARQ process comes when. And eNodeB can also knows about RV because UL Grant (DCI 0) from eNodeB can specify RV using MCS field.

c)it has two mode of operation : Adaptive and Non-Adaptive HARQ

< Adative UL HARQ Process >

Adaptive here means that the network chooses how each retry is sent, rather than repeating the first attempt unchanged. The eNB has just failed to decode a PUSCH, so it knows something went wrong and can act on that. It can move the retransmission to different resource blocks, and it can choose which redundancy version the UE sends next. The UE decides none of this. It waits for a grant and follows what the grant says.

One consequence is worth noting before you look at Figure 2. Every retransmission there needs its own DCI 0, and every DCI 0 occupies a PDCCH. So this control is not free, and the non-adaptive mode exists partly to avoid that cost.

Following is an example of Adative UL HARQ Process (Key idea is that Each UL retransmission uses different RV and the RV is determined by DCI 0).



Figure 2. Adaptive UL HARQ. Every retransmission arrives with its own DCI 0, and the MCS field rather than a separate field carries the redundancy version.

• The first grant is DCI 0 (MCS = 8, RV 0) and the UE answers with PUSCH (RV = 0). Every step sits 4 sub frames after the one before, so one retransmission round costs 8 sub frames.
• A new DCI 0 follows each NACK on PHICH, and every one of them is marked NDI = Not Toggled. That is what tells the UE this is a retransmission rather than new data.
• The redundancy version runs 0, then 2, then 3, then 1. The MCS field carries it: MCS = 30 with RV 2, MCS = 31 with RV 3, and MCS = 29 with RV 1.
• The last exchange shows the release. ACK on PHICH is followed by DCI 0 (MCS = 8, RV 0, NDI = Toggled), and the toggled NDI starts a new transport block.

< Non-Adative UL HARQ Process >

Non-adaptive works the opposite way. Neither side has to signal the terms of the retry, because both already know them. The UE follows a fixed redundancy version order, and the eNB expects that same order on that same HARQ process. Uplink HARQ is synchronous, so the subframe alone tells the eNB which transmission it is looking at. A single NACK bit on PHICH is therefore enough to start the retransmission.

That saving has a cost. The eNB cannot move the retransmission, so it repeats on the same resource blocks with the same MCS as the first attempt. When those resource blocks are the problem, repeating on them does not help. Adaptive retransmission exists for exactly that case.

Following is an example of Non Adative UL HARQ Process (Key idea is that Each UL retransmission uses different RV and the RV is determined by predefined sequence specified in TS36.321 "5.4.2.2 HARQ process").



Figure 3. Non-adaptive UL HARQ. The redundancy version order is the same as in Figure 2, and the difference is that no DCI 0 arrives to carry it.

• Each NACK on PHICH is followed by the note (No DCI 0), and the UE retransmits anyway. The PHICH on its own triggers the retransmission.
• The redundancy version still runs 0, then 2, then 3, then 1, and MCS stays at 8 throughout. The UE takes the order from the predefined sequence rather than from a grant.
• The release works the same way as in Figure 2. ACK on PHICH, then a DCI 0 with NDI Toggled, then a new PUSCH at RV 0.

The last but very important question would be "How UE knows if it is supposed to do Adaptive retransmission and Non-Adaptive retransmission ?"

•   UE do "Adaptive retransmission" if it detect DCI 0 with NDI not toggled. (In this case, UE does not care about "HARQ feedback (PHICH)", it retransmit based on DCI 0 information).
•   UE do "Non-Adaptive retransmission" if it got "HARQ feedback (PHICH=NACK)" but does not get DCI 0. In this case, UE retransmit the PUSCH in predefined RV and MCS without the information from DCI 0.

	Adaptive (Figure 2)	Non-adaptive (Figure 3)
What arrives after the NACK	A DCI 0 with NDI = Not Toggled	Nothing. The drawing marks it (No DCI 0)
What carries the redundancy version	The MCS field of that DCI 0	A predefined sequence
MCS value in the drawing	30, 31 and 29 for RV 2, 3 and 1	8 throughout, the same as the first transmission
What the UE acts on	The grant	The PHICH
Redundancy version order	0, 2, 3, 1	0, 2, 3, 1

The detailed HARQ Process for Uplink is described in 36.321 - 5.4.2.2 and following is my interpretation of the specification in illustration.  

Case 1 : HARQ Process for Uplink (except Msg 3)

Figures 2 and 3 showed the two modes as timing diagrams, with subframes running down the page. Figure 4 is a flow chart, so read it as decision logic rather than as a schedule. It covers both modes in one picture, and the branch that separates them sits in the middle. The label says except Msg 3 for a reason. The Random Access message 3 runs its own variant, bounded by maxHARQ-Msg3Tx rather than by maxHARQ-Tx. That limit is broadcast in RACH-ConfigCommon, and it runs from 1 to 8.

Figure 4. The uplink HARQ process as a flow chart. The loop has only two exits: an ACK on PHICH, or CURRENT_TX_NB reaching maxHARQ_Tx minus one.

• The first box sets the state the architecture defines. CURRENT_TX_NB = 0, CURRENT_IRV = 0 and HARQ_FEEDBACK = NACK, and both the MAC PDU and the UL Grant are stored.
• HARQ_FEEDBACK starts at NACK rather than at nothing. The process assumes failure until a PHICH says otherwise.
• The diamond labelled "ACK ?" is the only early exit. Everything below it runs once per retransmission.
• The diamond labelled "Is Adpative ?" is where Figure 2 and Figure 3 diverge. The left branch takes CURRENT_IRV from DCI 0, and the No branch leaves it to the predefined order.
• The red dotted note "From RRC message" points at maxHARQ_Tx. The UE does not choose that value, and the listing below shows where the network sets it.
• Reaching CURRENT_TX_NB = maxHARQ_Tx - 1 ends the process by flushing the HARQ Buffer. The UE abandons the transport block at that point, and leaves recovery to RLC.

maxHARQ-Tx is configured in the MAC-MainConfig information element, inside its ul-SCH-Config field.

Following is based on 36.331 v19.3.0 (Release 19)

ul-SCH-Config                SEQUENCE {
    maxHARQ-Tx                   ENUMERATED {
                                     n1, n2, n3, n4, n5, n6, n7, n8,
                                     n10, n12, n16, n20, n24, n28,
                                     spare2, spare1}   OPTIONAL,   -- Need ON
    periodicBSR-Timer            PeriodicBSR-Timer-r12 OPTIONAL,   -- Need ON
    retxBSR-Timer                RetxBSR-Timer-r12,
    ttiBundling                  BOOLEAN
}                                                      OPTIONAL,   -- Need ON

• The values run n1 to n8, then n10, n12, n16, n20, n24 and n28. So the limit is a count of transmissions, and not every count is available.
• The -- Need ON comment means the UE keeps the value it already has when the field is absent.

• The redundancy version order is the same either way : Figure 2 and Figure 3 both run 0, 2, 3 then 1. So the RV sequence does not tell you which mode is in use.
• NDI is the new data flag, not the mode flag : NDI not toggled means retransmission, and NDI toggled starts a new transport block. Both figures end that way.
• Adaptive retransmission overrides the PHICH : the UE follows a DCI 0 when one arrives, so the NACK is not what drives the retransmission in Figure 2.
• maxHARQ-Tx bounds the loop : the UE stops after that many attempts and flushes the buffer, which leaves RLC to recover the data.

HARQ ProcessID Synchronization

When transfering data via HARQ process, the reciever and transmitter should know 'some information' about Process ID for each of the HARQ process, so that the reciever can successfully keeping each process data without getting them mixed up.

In case of Asynchronous HARQ

(e.g, PDSCH transmission in LTE), the sender should inform the receiver of HARQ processor number explictely. In case of LTE, DCI 1 and 2 carries this information as you see in the DCI 1 and DCI 2 examples.

Asynchronous HARQ has no timing rule to rely on, so the process ID has to travel with the data. Figure 5 shows a downlink stretch where the eNB uses its processes in whatever order suits it. The PDCCH row is a field the UE reads. Nothing in the subframe number would let it work the number out. Figure 6 shows the synchronous case, where the opposite holds.

Figure 5. Asynchronous HARQ on the downlink. Process 3 returns after 4 subframes and then after 5, so the gap carries no information and the DCI has to name the process every time.

• The PDCCH : HARQ process ID row is the DCI field itself. DCI 1 and DCI 2 both carry it, and the UE takes the number straight from there.
• The order here is 3, 0, 5, 3, 1, 5, 0, 3. It does not ascend and it does not repeat on a period, which is what asynchronous means.
• The three shaded columns all carry process 3. They sit 4 and then 5 subframes apart, so no fixed offset exists for the UE to derive.
• Two columns carry nothing. The eNB schedules a process when it has data for it, so the numbering does not advance with the subframe.

What about in case of Synchronous HARQ ?  

You don't have to inform Process ID in this case since the process ID can be inferred from the transmission time (In LTE UL HARQ case, this timing is expressed in SFN and subframe number).

Then is there any specific rule (mathematical formula) to figure out HARQ process ID from SFN and subframe number ?

In LTE, there is no specific formula is defined in the 3GPP specification, but following can be one of the simplest rule in LTE case.

UL HARQ Process ID = (SFN x 10 + subframe) modulo 8

, here we use modulo 8 because LTE use 8 HARQ process

Does the reciever (eNodeB in LTE case) need to know exact HARQ process ID ?

Not Really. As long as eNodeB prepare at least 8 HARQ buffer and store PUSCH for each subframe separately at least for 8 subframe span, there would be no problem of decoding each HARQ data without problem. One possible procedure may go like this :

i) an eNodeB prepare 8 separate HARQ Buffers and let name it as Buf0,Buf1,..,Buf7.

ii) When an eNodeB receives the first PUSCH, it put the PUSCH into the first UL HARQ buffer (Buf0) in the eNodeB.

iii)  When the eNodeB receives the second PUSCH, it put the PUSCH into the first UL HARQ buffer (Buf1) in the eNodeB .... Repeat this process

iv)  When the eNodeB receives the 8 th PUSCH, it put the PUSCH into the 8th UL HARQ buffer (Buf7) in the eNodeB

v)  When the eNodeB receives the 9 th PUSCH, it put the PUSCH into the first UL HARQ buffer (Buf0) in the eNodeB .... Repeat this process.

With this, there may be mismatches between UL HARQ Process ID that is allocated on UE side and the Buf number allocated on the eNodeB receiver buffer, but there would be no problem with decoding the data.

Figure 5 showed an ID that must be signalled because nothing predicts it. Synchronous HARQ is the mirror image. The mismatch it allows is easier to see than to describe. Figure 6 puts both numberings on one timeline, with the UE process ID above and the eNB buffer below. The eNB in this example happened to start its rotation at Buf3, so the two rows sit three apart. Watch what happens 8 subframes later.

Figure 6. The UE process ID and the eNB buffer number on one timeline. Both repeat every 8 subframes, so a retransmission returns to the same process and the same buffer even though the two numbers never agree.

• The SFN . subframe row is the subframe as a log prints it, and the SFN x 10 + subframe row is the number the modulo is applied to.
• The UE : process ID row applies the rule stated above, so the process ID is that number modulo 8. It counts 0 to 7 and starts again.
• The eNB : buffer row is not calculated at all. The eNB fills its buffers in arrival order, and where it starts depends only on which buffer it had reached.
• The two shaded columns sit 8 subframes apart. The UE returns to process 0 there and the eNB returns to Buf3, so a retransmission finds both sides where it left them.
• The gap between the two rows is three all the way across, and it never changes. That is why the mismatch costs nothing.

• Asynchronous HARQ has to carry the process ID : DCI 1 and DCI 2 name it explicitly, because nothing in the timing reveals it.
• Synchronous HARQ derives the process ID from time : the subframe fixes which process is in use, so nothing has to be signalled.
• The two sides need not agree on the number : the eNB only has to keep eight buffers in subframe order, so a different numbering still decodes correctly.

Synchronous and Asynchronous in Real Networks

The two mechanisms above are not alternatives that a vendor picks between. LTE uses both at the same time, and it assigns them by direction rather than by preference. Knowing which one applies tells you whether a process ID is signalled or inferred. That is usually the first thing you need when reading a trace.

Uplink is not synchronous in every case. 36.321 makes uplink HARQ asynchronous for NB-IoT UEs, for BL UEs and for UEs in enhanced coverage. Configured and preallocated grants do the same when they carry harq-ProcID-offset. The specification also defines a third mode it calls autonomous HARQ operation. Mainstream LTE uplink is synchronous, and the low power variants are where that stops being true.

A few uplink transmissions skip the numbering altogether. 36.321 gives HARQ process identifier 0 to three of them. They are the grant in a Random Access Response, transmission using PUR, and CB-Msg3-EDT. That is another reason the flow chart above sets Msg 3 aside.

The exception explains something about the two retransmission modes. For asynchronous uplink the specification triggers retransmissions only with adaptive grants. It also says HARQ feedback does not apply there. Non-adaptive retransmission works only because uplink is synchronous. A bare NACK on PHICH carries no process number, so it is enough only when the timing already says which process it answers. Take the fixed timing away and the PHICH has nothing to point at.

One pairing is worth keeping apart, because the words sound alike. Synchronous and asynchronous describe when a retransmission happens and whether the process ID travels with it. Adaptive and non-adaptive describe what the network may change. LTE uplink is synchronous and can still be adaptive, which is exactly what Figure 2 shows.

• LTE runs both at once : the downlink is asynchronous and the uplink is synchronous, so the question is never which one a network chose.
• Asynchronous means the ID has to be signalled : that is the cost of letting the scheduler retransmit at any moment.
• Non-adaptive retransmission needs synchronous timing : a PHICH NACK cannot say which process it answers, so asynchronous uplink uses grants only.
• Adaptive is not the same as asynchronous : one is about what changes and the other is about when. LTE uplink is synchronous and adaptive at the same time.

Reference :

[1] HARQ Process Boosts LTE Communications

[2] HARQ in LTE

[3] TS 36.321 v19.3.0 (Release 19) - E-UTRA Medium Access Control (MAC) Protocol Specification. Clause 5.4.2 HARQ operation.

[4] TS 36.331 v19.3.0 (Release 19) - E-UTRA Radio Resource Control (RRC) Protocol Specification. MAC-MainConfig and RACH-ConfigCommon.