In short, HARQ mechanism for LTE M1 downlink is similar to legacy LTE mechanism (except the repetitive transmission), but HARQ mechanism is a little bit different from legacy LTE as described below.

One word carries most of the difference, and that word is bundle. A BL/CE transport block is not sent once. It goes out as a run of repetitions that the receiver combines, and the HARQ machinery counts bundles rather than subframes. Where a legacy timer or a legacy grant refers to a transmission, the BL/CE version refers to the last repetition of a bundle.

Followings are the topics to be covered in this page.

• HARQ Operation for Downlink
• HARQ Operation for Uplink
• RV Determination : PDSCH for SystemInformationBlockType1-BR
• How many HARQ processes a UE has
• What changed after Release 13
• Reference

HARQ Operation for Downlink

HARQ Process for Downlink is similar to legacy LTE except that each transmission would happen in repetition in LTE-M1. The rough HARQ sequence would be as follows.

i) UE <-- NW : MPDCCH (DCI for PDCCH) in repetition

ii) UE <-- NW : PDSCH in repetition

iii) UE --> NW : HARQ ACK/NACK

Note : Step i) and ii) happens not in the same subframe. (This is different from legacy LTE)

Following is what is commented in 3GPP

36.321 - 5.3.2.1 HARQ entity describes as follows

• For NB-IoT UEs or BL UEs or UEs in enhanced coverage, the parameter DL_REPETITION_NUMBER provides the number of transmissions repeated in a bundle. For each bundle, DL_REPETITION_NUMBER is set to a value provided by lower layers. Within a bundle, after the initial (re)transmission, DL_REPETITION_NUMBER-1 HARQ retransmissions follow. The HARQ feedback is transmitted for the bundle and a downlink assignment corresponding to a new transmission or a retransmission of the bundle is received after the last repetition of the bundle. A retransmission of a bundle is also a bundle.

The note above says the two steps do not share a subframe, and 36.213 says how far apart they are. The PDSCH starts in the second BL/CE downlink subframe after the last MPDCCH subframe. One configuration replaces that two with a signalled value, and it reaches only a CE mode A UE whose DCI carries the scheduling delay field. Everything else uses the fixed two.

Step iii is measured the same way, from an ending rather than a beginning. The default is four subframes after the last subframe of the PDSCH bundle, so a longer bundle pushes the acknowledgement later without changing the rule. Two configurations replace that four with a signalled value, and both of them reach CE mode A only.

One point is easy to miss on a first reading. The acknowledgement itself repeats. The count comes from pucch-NumRepetitionCE-format1 when that field is configured. Otherwise it comes from the pucch-NumRepetitionCE-Msg4 field of the level the UE is at. Those four Msg4 fields are the ones a SIB2 decode shows, and they govern the HARQ-ACK as well as the acknowledgement of Msg4.

That also explains the HARQ RTT Timer the section below quotes. Seven subframes is four for the delay plus three for processing. The N added to it is the same PUCCH repetition factor, because the timer cannot expire before the repeated acknowledgement has finished.

• Both gaps are counted from a last repetition : the PDSCH from the last MPDCCH subframe, and the HARQ-ACK from the last PDSCH subframe. Nothing is counted from where a bundle began.
• The acknowledgement is a bundle too : one HARQ-ACK is sent over N consecutive BL/CE uplink subframes, so a deep coverage UE spends many subframes saying one bit.
• CE mode A can signal the delays and CE mode B cannot : those fields sit only in the CE mode A DCI, so CE mode B always uses the fixed two and four.
• The HARQ RTT Timer follows from both : 7 plus N is the delay, the processing time and the repeated acknowledgement added together.

HARQ Operation for Uplink

HARQ Process for Downlink of M1 is similar to legacy LTE except that each transmission would happen in repetition. However, HARQ Process for Uplink in M1 is different from legacy LTE. The most critical difference is that eNB does not send any HARQ ACK/NACK for PUSCH (It is understandable because there is no PHICH in LTE M1). Then, you may ask how eNB can handle the case where PUSCH reception fail ? Following process would give you the answer.

The rough HARQ sequence would be as follows.

i) UE <-- NW : MPDCCH (DCI for PUSCH) with UL Grant in repetition

ii) UE --> NW : PUSCH in repetition

iii) One of the following cases happens :

• case 1 : NW successfully decoded PUSCH, it stops there and complete PUSCH reception process.(No ACK transmission).
• case 2 : NW failed to decode PUSCH. it sends MPDCCH (DCI for PUSCH) for PUSCH retransmission

NOTE : If UE does not receive MPDCCH for PUSCH retransmission, UE assumes that PUSCH is properly received by NW. PHICH does not exists to send ACK/NACK for PUSCH in LTE M1.

The uplink loop with no acknowledgement channel in it. The eNB never says yes, and the UE learns the answer from the next grant it receives, or from the absence of one.

• A and B are the first transmission : the UE sends New MPUSCH 1 and keeps the data in a buffer, because nothing yet says the block arrived.
• C is the only decision the eNB makes : the Decoding Error question at the top. Its NO branch leads to E, No Feedback, and its YES branch leads to D.
• D is a retransmission request written as a grant : a DCI with NDI Not Toggled, which asks for the same data again rather than new data.
• G and the dashed line through K are the loop : a second decoding error returns to D, and the exchange repeats with the buffer still held.
• H is the acknowledgement, and it is a grant : a DCI with NDI Toggled says the eNB has the data. The two boxes below it discard the buffer and send the next transport block.

Two branches in the drawing look the same and are not. E is silence after a successful first transmission, while H is a grant after a successful retransmission. Both mean the eNB decoded the block, and the UE reads them differently only because one carries a DCI and the other carries nothing.

The new data indicator is what makes this work without a feedback channel. It is a single bit in the uplink DCI, and the UE compares it against the value it saw for the same HARQ process last time. An unchanged bit means send the same data, and a changed bit means the eNB is finished with that transport block. The word toggled in the drawing is that comparison.

The drawing writes the uplink channel as MPUSCH in three places and MPUSH in two others. Neither spelling appears in the specifications, which call it the PUSCH throughout, and the M in front of it is borrowed from the MPDCCH.

• Silence means success : the eNB sends nothing after decoding the first transmission, so the UE has to treat the absence of a grant as an acknowledgement.
• A grant can be an acknowledgement or a request : the new data indicator separates the two, and it is the only thing that does.
• The buffer is held until the indicator toggles : the UE cannot release the data at any earlier point, because no earlier signal confirms the block arrived.
• Asynchronous means the grant names the process : a retransmission can arrive at any time, so the HARQ process identifier travels in the grant rather than in the timing.

36.321 - 5.4.2.1 HARQ entity, 5.4.2.2 HARQ process, 7.7 HARQ RTT Timers describes as follows

• Uplink HARQ operation is asynchronous for NB-IoT UEs, BL UEs or UEs in enhanced coverage except for the repetitions within a bundle.
• For NB-IoT UEs, BL UEs or UEs in enhanced coverage, the parameter UL_REPETITION_NUMBER provides the number of transmission repetitions within a bundle. For each bundle, UL_REPETITION_NUMBER is set to a value provided by lower layers. Bundling operation relies on the HARQ entity for invoking the same HARQ process for each transmission that is part of the same bundle. Within a bundle HARQ retransmissions are non-adaptive and are triggered without waiting for feedback from previous transmissions according to UL_REPETITION_NUMBER. An uplink grant corresponding to a new transmission or a retransmission of the bundle is only received after the last repetition of the bundle. A retransmission of a bundle is also a bundle.
• For NB-IoT UEs, BL UEs or UEs in enhanced coverage for UL_REPETITION_NUMBER for Mode B operation, the same redundancy version is used multiple times before cycling to the next redundancy version as specified in Subclause 16.5.1.2, 8.6.1 and 7.1.7.1 in 36.213.
• For BL UEs and UEs in enhanced coverage, HARQ RTT Timer corresponds to 7 + N where N is the used PUCCH repetition factor, where only valid (configured) UL subframes as configured by upper layers in fdd-UplinkSubframeBitmapBR are counted. In case of TDD, HARQ RTT Timer corresponds to 3 + k + N, where k is  the interval between the last repetition of downlink transmission and the first repetition of the transmission of associated HARQ feedback, and N is the used PUCCH repetition factor, where only valid UL subframes are counted as indicated in subclauses 10.1 and 10.2 of  36.213

RV Determination : PDSCH for SystemInformationBlockType1-BR

SystemInformationBlockType1-BR is retransmitted and each retransmission uses different RV (Redundancy Version). RV for each retransmission varies depending on SystemInformationBlockType1-BR retransmission patter as described below : (Refer to 36.321 - 5.3.1 DL Assignment reception for further details)

RV = ceiling(3/2*k) mod 4 // k is determined depending of the number of repetitions

Case 1 : number of repetitions for PDSCH carrying SystemInformationBlockType1-BR is 4

k = floor(SFN/2) mod 4

Case 2 : number of repetitions for PDSCH carrying SystemInformationBlockType1-BR is 8

k = SFN mod 4

Case 3 : number of repetitions for PDSCH carrying SystemInformationBlockType1-BR is 16

k = (SFN * 10 + i) mod 4 , where i = subframe number in the SFN

The three cases above cover SystemInformationBlockType1-BR alone, and 36.321 gives a fourth line for the other broadcast messages. For a SystemInformation-BR message the index is k = i mod 4, where i counts subframes within the SI window rather than frames within a cycle. The redundancy version therefore advances once per subframe in that case and once per frame or per two frames in the SIB1-BR cases.

Why the redundancy version has to move at all is worth stating. A repeated transmission that sent the same bits every time would give the receiver nothing new to combine beyond a better signal to noise ratio. Cycling the redundancy version sends different coded bits instead, so each repetition adds parity the receiver did not have.

The pattern is also blind. Nothing schedules SystemInformationBlockType1-BR, so the UE cannot be told which redundancy version a given subframe carries. Deriving it from the frame number lets a UE join the cycle at any point, even one that has just powered on.

Checked against 36.321 v19.3.0, the formula and all three cases are unchanged from the Release 13 text quoted here.

• The redundancy version is derived, never signalled : it comes from the system frame number, which a UE reading SIB1-BR already has from the MIB.
• More repetitions means a faster cycle : with 4 repetitions k advances every two frames, with 8 every frame, and with 16 every subframe.
• The cycle is 0, 2, 3, 1 rather than 0, 1, 2, 3 : the four values of k give ceilings of 0, 2, 3 and 5, and 5 wraps to 1.
• SystemInformation-BR uses a different index : k counts subframes inside the SI window, so position in the window drives the cycle rather than the frame number.

How many HARQ processes a UE has

The two sections above describe one process at a time and never say how many run at once. That number matters more here than in legacy LTE. A bundle occupies many subframes, so a UE with few processes spends most of its time waiting rather than sending. The counts below are the FDD ones, and they differ by coverage enhancement mode rather than by direction.

CE mode A keeps the legacy figure of eight in both directions. CE mode B does not, and the reason is the bundle length. A CE mode B transport block can occupy hundreds of subframes, so a second process would have nowhere to run, and the specification allows only two.

Maximum HARQ processes per serving cell in FDD, from 36.213 v19.4.0 clauses 7 and 8.0. The dedicated broadcast process that carries SystemInformationBlockType1-BR is counted separately and is not included here.

One case sits outside the table. A PUSCH sent on a preconfigured uplink resource uses exactly one uplink HARQ process, whatever the mode. No grant is involved, so there is nothing to interleave with.

The broadcast process is the other exception. 36.213 says plainly that it is not counted against the maximum. The redundancy version cycle of the section above therefore runs independently of anything a scheduler does.

• CE mode B has a quarter of the processes : two against eight, because one bundle already occupies the subframes the other processes would need.
• Multi-TB doubles CE mode B : one grant carrying several transport blocks raises the count to four, which is still half of CE mode A.
• Only the downlink grew past eight : ten and then fourteen downlink processes were added for CE mode A, and the uplink stayed at eight throughout.
• The broadcast process is free : SystemInformationBlockType1-BR does not consume one of the counted processes.

What changed after Release 13

The reference at the foot of this page is 36.321 V13.2.0, and one sentence in the uplink section above has not survived it. The rest has. Bundling, the new data indicator and the redundancy version cycle all work in Release 19 exactly as they are described here. The drawing and the quoted clauses still hold for a Release 13 network.

The sentence that has changed is the central one. Release 15 added mpdcch-UL-HARQ-ACK-FeedbackConfig. 36.331 describes it as letting the network send an uplink HARQ-ACK on the MPDCCH, or a grant for a new transmission, to end a PUSCH bundle early. A Release 15 UE with that field set therefore can be acknowledged directly, and it no longer has to infer success from silence.

The point of the addition is the bundle rather than the acknowledgement. A CE mode B bundle can run for hundreds of subframes. Without a way to stop it, the UE keeps transmitting long after the eNB has decoded the block. An early acknowledgement returns those subframes to the cell, and it saves the UE the power it would have spent on them.

Compared against 36.213 v19.4.0, 36.321 v19.3.0 and 36.331 v19.3.0, with each release dated by the suffix of the field that configures it in 36.331.

The HARQ RTT Timer quoted in the uplink section has grown as well. 36.321 v19.3.0 writes the single transport block case as 7 plus N subframes plus a downlink offset. Two more cases were added for multiple transport blocks, 7 plus m times N without bundling and 7 plus M times N with it. The form quoted on this page is the first of the three.

• The no acknowledgement rule is now conditional : it holds for Release 13, and a Release 15 network can acknowledge an uplink bundle directly on the MPDCCH.
• Early termination is the reason, not feedback : stopping a long bundle returns subframes to the cell and power to the UE.
• The downlink process count moved twice : eight, then ten in Release 14, then fourteen in Release 17, each time for CE mode A only.
• Release 18 can switch downlink feedback off : the round trip of a non-terrestrial link makes an acknowledgement costly, so a bitmap or the DCI disables it per process.
• The redundancy version rule never moved : the formula and its three cases read the same in 36.321 v19.3.0 as in the Release 13 text.

Reference

[1] 3GPP TS 36.321 V13.2.0 (2016-06)

[2]

[3] 3GPP TS 36.321 v19.3.0 - clause 5.3.1 Downlink Assignment reception, clause 5.3.2.1 and 5.4.2.1 HARQ entity, clause 5.4.2.2 HARQ process, clause 7.7 HARQ RTT Timers

[4] 3GPP TS 36.213 v19.4.0 - clause 7 for the downlink HARQ process count and the HARQ-ACK timing, clause 8.0 for the uplink count

[5] 3GPP TS 36.331 v19.3.0 - the ce-PDSCH-TenProcesses, ce-PDSCH-14HARQ-Config, mpdcch-UL-HARQ-ACK-FeedbackConfig and downlinkHARQ-FeedbackDisabled fields