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.)
Following is overall architecture of LTE HARQ entity. Refer to 36.321 188.8.131.52 and 184.108.40.206 for the detailed description of mechanism.
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
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).
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 "220.127.116.11 HARQ process").
The last but very important question would be "How UE knows if it is supposed to do Adaptive retransmission and Non-Adaptive retransmission ?"
The detailed HARQ Process for Uplink is described in 36.321 - 18.104.22.168 and following is my interpretation of the specification in illustration.
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.
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.