HARQ (Downlink & Uplink) in 5G NR

1. Why HARQ Exists, and the Division of Labour with RLC ARQ

A radio link makes errors, and it makes them in bursts. The natural engineering response — encode conservatively enough that errors never happen — is enormously wasteful, because the coding has to be sized for the worst instant rather than the average one. NR instead deliberately schedules to fail: the link adaptation loop aims at roughly a 10 % block error rate on first transmission, accepts that one block in ten will not decode, and recovers those with a retransmission mechanism cheap enough that the trade is worth it.

HARQ is that mechanism. The hybrid in the name is the important part. Plain ARQ discards a failed transmission and sends it again; HARQ keeps the failed attempt as soft information and combines it with the retransmission, so the second attempt starts from an accumulated signal rather than from nothing. That means a retransmission does not have to be independently decodable — it only has to close the gap — which is why HARQ recovers from a marginal failure in one extra attempt where plain ARQ might need several.

There are two retransmission layers in NR and the separation is deliberate. Each is bad at what the other is good at:

Table 1. The two layers, and why both are needed. Residual error figures are typical design targets rather than specified values.

The error budget cascades. Reading it top to bottom is the clearest way to see why the link adaptation target is deliberately poor:

Table 2. Why aiming at 10 % BLER is correct rather than sloppy: the spectral efficiency gained by coding for the average instead of the worst case far exceeds the cost of retransmitting one block in ten. Figures are design targets, not specified requirements.

2. Stop-and-Wait, Parallelised: Processes and the Pipeline

One HARQ process is the simplest possible protocol: send a transport block, wait for the answer, then either send new data or resend. The problem is the waiting. At 30 kHz a slot is 0.5 ms, and the round trip from transmission to the earliest possible retransmission is typically five to ten slots once UE decoding time, feedback timing and the gNB's own turnaround are included. A single stop-and-wait process would leave the link idle for nine slots out of ten.

NR runs many processes in parallel, each an independent stop-and-wait instance identified by a HARQ process ID carried explicitly in the scheduling DCI. While process 3 waits, processes 4, 5, 6 and the rest carry new data. Stop-and-wait applies per process; it never applies to the link.

2.1 How many processes, and why

Two things bound the count. The first is arithmetic: the HARQ process number field in DCI formats 1_0/1_1 and 0_0/0_1 is 4 bits, so Rel-15 and Rel-16 can address at most 16. The second is what the pipeline actually needs, which is roughly the round trip divided by the slot duration — and since the round trip is dominated by fixed processing time while the slot shrinks with numerology, the needed count grows with SCS. That is exactly why Rel-17, introducing 480 and 960 kHz for FR2-2 and non-terrestrial links with round trips measured in hundreds of milliseconds, had to widen the field to 5 bits and allow 32.

nrofHARQ-ProcessesForPDSCH-v1700

Table 3. Where the process count comes from. See the companion 08 Scheduling document for SPS and configured grants themselves.

The process count is not free. Every process needs its own soft buffer, and the UE's total soft-buffer memory is a capability, not a configuration — so doubling the process count halves the soft bits available per process unless limited buffer rate matching is in play (§7). Configuring n16 on a cell that only ever needs six processes does not improve throughput; it can reduce the combining gain available to each retransmission.

3. Asynchronous in Both Directions — and Where LTE's Model Misleads

Anyone arriving from LTE carries a mental model that is half wrong here. In LTE, downlink HARQ was asynchronous (the process ID was signalled) but uplink HARQ was synchronous: retransmissions happened on a fixed 8 ms cycle and the process ID was implied by the subframe number, with no field for it anywhere. NR abandoned that. Both directions are asynchronous, and both carry the process ID explicitly in the DCI.

Table 4. Downlink and uplink HARQ in NR. The single genuinely asymmetric row is feedback: the downlink has an explicit channel for it, the uplink does not.

There is one place where timing-derived process IDs survive, and it is worth knowing because it looks like the LTE behaviour: configured grants and semi-persistent scheduling. A transmission on a configured resource has no DCI, so there is no field to carry the process ID; the specification therefore derives it from the time the transmission occurs TS 38.321 cl. 5.4.1:

Uplink configured grant, HARQ process ID:

  HARQ Process ID = floor( CURRENT_symbol / periodicity )
                    modulo nrofHARQ-Processes
                    ( + harq-ProcID-Offset2, Rel-16 )

  CURRENT_symbol =   SFN x numberOfSlotsPerFrame x numberOfSymbolsPerSlot
                   + slot number in the frame x numberOfSymbolsPerSlot
                   + symbol number in the slot

Downlink SPS uses the equivalent expression over slots and the SPS
periodicity, modulo the SPS nrofHARQ-Processes.

4. The New Data Indicator: One Bit That Decides Everything

The receiver has to answer one question before it does anything else: is this transport block new, or is it another attempt at the one I already have soft bits for? Nothing else in the DCI answers it. The process ID is the same either way. The transport block size is the same. The RNTI is the same. The redundancy version hints at it but does not decide it — a retransmission can legitimately reuse RV0. The answer is carried by a single bit, the New Data Indicator, and the semantics are a toggle, not a flag:

• NDI differs from the value stored for that process → new data. Flush the soft buffer, store the new NDI value, decode what just arrived on its own.
• NDI is unchanged → retransmission. Keep the stored soft bits, add the new coded bits at the offset the RV indicates, decode the combination.
• No stored value for that process (first use, or after a flush) → treat as new data.

5. The Circular Buffer, Rate Matching and Redundancy Versions

The LDPC encoder does not produce a transmission — it produces a pool of coded bits far larger than any single transmission needs. For base graph 1 the encoder output per code block is 66·Z_c bits, of which 22·Z_c are systematic (the information bits themselves) and 44·Z_c are parity. That pool is written into a circular buffer, and rate matching is the act of reading a contiguous run out of it, wrapping at the end, long enough to fill the resource elements the scheduler allocated.

The redundancy version is simply where in that buffer the read starts. It is not a different encoding, not a different puncturing pattern, and not a mode. Two bits in the DCI select one of four starting offsets TS 38.212 cl. 5.4.2.1, Table 5.4.2.1-2:

Table 5. Redundancy version starting positions. The percentages assume no limited buffer rate matching, so N_cb = N; with LBRM the offsets compress towards the start of the buffer (§7).

Three consequences follow, and all three show up in logs:

• RV0 is self-decodable and the others are generally not. RV0 starts at the systematic bits, so a receiver with an empty buffer can decode it alone if the channel is good enough. A UE that receives RV2 as its first sight of a transport block — because it missed the RV0 transmission — will usually fail, and correctly so.
• Chase combining and incremental redundancy are the same mechanism. Sending RV0 repeatedly is chase combining: identical bits, so the receiver accumulates energy. Sending RV0 then RV2 is incremental redundancy: different bits, so the receiver accumulates code rate. IR is stronger and is the default; CC is what you get when the allocation is so large that a single transmission already reads the whole buffer and wrapping makes every RV equivalent.
• The order 0/2/3/1 is not a rule the UE enforces. It is the sequence TS 38.214 mandates for repetition (pdsch-AggregationFactor and pusch-AggregationFactor, Tables 5.1.2.1-2 and 6.1.2.1-2) and the sequence essentially every scheduler uses for dynamic retransmission. The DCI carries an arbitrary rv_id, so a scheduler is free to send 0, 0, 0, 0 — and some do, in poor coverage, because chase combining needs no buffer state at the UE.

6. Base Graphs, Code Blocks and the Transport Block Size

Before there is a circular buffer there is a choice of LDPC base graph and a segmentation of the transport block into code blocks, and both depend on the transport block size and the target code rate. This is worth following once end to end, because the code block count is what sets the CBG granularity in §10 and the per-code-block rate matching length in §5.

6.1 Which base graph

Table 6. LDPC base graph selection, TS 38.212 cl. 7.2.2 (downlink) and cl. 6.2.2 (uplink). The rules are evaluated in order and the first match wins.

6.2 Segmentation

B  = A + 24                        -- transport block CRC (CRC24A)

if B <= K_cb :   C = 1,  B' = B                 -- no segmentation,
                                                --   no code block CRC
else :           L = 24                         -- CRC24B per code block
                 C = ceil( B / (K_cb - L) )
                 B' = B + C x L

K' = B' / C                                     -- bits per code block
Z_c = smallest lifting size with  K_b x Z_c >= K'
      ( K_b = 22 for BG1;  10, 9, 8 or 6 for BG2 depending on B )
K   = K_b_max x Z_c                             -- 22 Z_c for BG1
filler bits = K - K'                            -- set to NULL, not sent

N   = 66 x Z_c  (BG1)   or   50 x Z_c  (BG2)    -- circular buffer size

6.3 Transport block size, worked

TBS is not a free parameter: it is derived from the allocation, the MCS and the overhead, then quantised so that both ends compute the same value without signalling it TS 38.214 cl. 5.1.3.2. Here is one, all the way through, and the numbers feed §5 and §10.

7. Soft Combining, the Soft Buffer and Limited Buffer Rate Matching

What the receiver stores after a failed attempt is not the received bits but their log-likelihood ratios — soft values expressing how confident the demodulator is about each coded bit, positive for a likely zero and negative for a likely one, with magnitude proportional to confidence. When a retransmission arrives, the receiver adds the new LLRs into the same buffer at the positions the RV offset indicates. Positions covered twice accumulate confidence; positions covered for the first time fill in previously unknown parity. Then it runs the LDPC decoder over the whole accumulated buffer, not over the retransmission.

That is why the retransmission does not have to be independently decodable, and it is also why the soft buffer is expensive: it needs several bits of storage per coded bit, per code block, per HARQ process, per carrier. A UE aggregating four carriers with 16 processes each and four code blocks per transport block is holding 256 code blocks' worth of soft values.

Limited buffer rate matching is the escape valve. Instead of the full circular buffer N, rate matching is restricted to the first N_cb bits of it TS 38.212 cl. 5.4.2.1:

N_cb = N                                        if LBRM is not in use
N_cb = min( N , N_ref )                         if LBRM is in use

  N_ref = floor( TBS_LBRM / (C x R_LBRM) )      with R_LBRM = 2/3

  TBS_LBRM is computed from a reference configuration: the maximum
  number of layers the UE is configured for on that cell, 256QAM if
  supported, the largest configured bandwidth part, and a code rate
  of 948/1024.

Consequence: the RV offsets in S5 are computed from N_cb, not N, so
with LBRM they all move towards the start of the buffer -- and the
highest-parity part of the code is never transmitted at all.

8. K1 and K2: the Timing Offsets, Worked to an Absolute Slot

NR signals every scheduling relationship as a slot offset, so that the same DCI formats work at every numerology and in every TDD pattern. Three offsets matter for HARQ:

Table 7. The three HARQ-relevant timing offsets, TS 38.214 cl. 5.1.2.1 and 6.1.2.1, and TS 38.213 cl. 9.2.3 for the DCI 1_0 K1 table.

The processing times these offsets have to respect are capabilities, not configuration, and they are expressed in symbols so they shrink in absolute time but not in slots as numerology rises:

Table 8. UE processing capability 1, front-loaded DMRS only, from TS 38.214 Table 5.3-1 and Table 6.4-1. Capability 2 (processingType2Enabled) is roughly half of these and is what makes sub-slot URLLC scheduling possible.

9. HARQ-ACK Codebooks: Type-1, Type-2 and Type-3

One PUCCH transmission usually has to acknowledge more than one PDSCH: several downlink slots' worth of transport blocks, possibly across several carriers, all mapping onto the same uplink slot through their K1 values. The HARQ-ACK codebook is the agreement between UE and gNB about how many bits that PUCCH carries and which transport block each bit refers to. If the two sides disagree about the size, every bit is misaligned and the feedback is worse than useless.

pdsch-HARQ-ACK-Codebook = semiStatic

pdsch-HARQ-ACK-Codebook = dynamic

Table 9. The three codebook types, TS 38.213 cl. 9.1.2 (Type-1), 9.1.3 (Type-2) and 9.1.4 (Type-3). Rel-16 also adds an enhanced dynamic codebook for NR-U that can group and retransmit feedback.

9.1 What the DAI fields actually do

In a dynamic codebook the UE cannot know the codebook size by configuration, so each DCI carries a counter DAI: a 2-bit value counting, modulo 4, the accumulated number of assignments up to and including this one, ordered first by serving cell and then by PDCCH monitoring occasion. A UE that misses one DCI sees the counter jump, infers exactly how many it missed, and pads the codebook with NACK at the right positions. The total DAI, present only when more than one serving cell is configured, states the total number of assignments across all cells up to the current monitoring occasion — which is the only defence against a DCI missed on a different carrier, where a counter jump would be indistinguishable from correct counting.

9.2 Spatial bundling

On a cell configured for two transport blocks, each PDSCH produces two HARQ-ACK bits. harq-ACK-SpatialBundlingPUCCH and harq-ACK-SpatialBundlingPUSCH in PhysicalCellGroupConfig replace them with their logical AND, halving the codebook at the cost of retransmitting both transport blocks when only one failed. It is a PUCCH-overhead trade, and it is usually enabled on cells with many aggregated carriers and disabled where two-codeword MIMO is common enough for the wasted retransmissions to matter.

10. Code Block Group Based Transmission

A transport block with four code blocks fails as a whole if any one code block fails, and a retransmission normally resends all four. When the failure is caused by something localised — a burst of interference hitting part of the allocation, or a pre-empted mini-slot — that is three quarters wasted. Code block group based transmission lets the scheduler retransmit only the failed subset.

maxCodeBlockGroupsPerTransportBlock

Table 10. Code block group configuration and signalling, TS 38.212 cl. 7.3.1.2.2 and TS 38.214 cl. 5.1.7.

CBG earns its complexity in exactly two situations: large transport blocks (where retransmitting everything is expensive in absolute terms) and bursty, localised interference — most characteristically downlink pre-emption, where a URLLC mini-slot punches a hole in an eMBB allocation and damages a predictable subset of the code blocks. See the pre-emption indication (DCI 2_1) in the companion 08 Scheduling document. Outside those cases the M-fold increase in HARQ-ACK payload usually costs more than the saved retransmission, which is why most deployments leave codeBlockGroupTransmission unconfigured.

11. Uplink HARQ Without a PHICH

LTE had a dedicated physical channel, PHICH, whose only job was to carry one ACK/NACK bit per uplink transport block. NR deleted it. There is no downlink channel anywhere in NR that carries uplink HARQ feedback, and there is no MAC control element for it either. The feedback is the next grant.

11.1 How the UE infers the outcome

When the gNB fails to decode a PUSCH, it sends a new DCI for the same HARQ process with the NDI unchanged. The UE recognises that as "send that transport block again" and does so, at whatever RV the DCI specifies. When the gNB succeeds, it either sends a DCI for that process with the NDI toggled — which both acknowledges the old block and schedules a new one — or sends nothing at all for that process, leaving the UE holding the transport block in its buffer until something else happens.

• No news is not good news, and it is not bad news either. A UE with no grant for a process simply waits. It does not retransmit on its own (except under a configured grant with cg-RetransmissionTimer, Rel-16 NR-U) and it does not flush.
• There is no configured retry limit. Unlike LTE's maxHARQ-Tx, NR specifies no maximum number of HARQ transmissions in either direction. The scheduler decides when to stop, and the real bound comes from above: the PDCP discardTimer, the RLC maxRetxThreshold, and the delay budget of the 5QI.
• Blind repetition is a separate mechanism. pusch-AggregationFactor (n2/n4/n8) and Rel-16 PUSCH repetition Type A and Type B send the same transport block several times without waiting for feedback, cycling the RV through 0/2/3/1. That is not HARQ retransmission; it is repetition, and it happens whether or not the first copy would have decoded.

11.2 Msg3 and configured grants

Two uplink cases sidestep the DCI entirely. The MAC PDU transmitted as MSG3 during Random Access uses HARQ process 0 by specification TS 38.321 cl. 5.4.2.1, because the UE has no C-RNTI-addressed DCI to carry a process ID at that point — see the companion 03 Random Access document. And a configured grant derives its process ID from the transmission time, using the formula in §3. Both are places where the process ID is not in any message you can read; you have to compute it.

12. Disabled HARQ Feedback and Very Long Round Trips

Everything so far assumes the round trip is short enough that a process waiting for feedback is a minor inefficiency. Over a geostationary satellite the round trip is around 270 ms, which at 30 kHz is 540 slots. Sixteen processes would leave the link idle 97 % of the time, and even 32 would not fix it. Rel-17 therefore allows HARQ feedback to be switched off per process.

Table 11. Rel-17 long-round-trip mechanisms. The timing side of this is covered in the companion 04 Timing Advance document, which carries the same NTN-Config structure.

13. HARQ, DRX, and the Timers That Connect Them

A UE in DRX is asleep most of the time, and a NACK it just sent creates an obligation to be awake later — but not immediately, because no retransmission is physically possible until the gNB has decoded the feedback and prepared one. Two per-process timers encode exactly that TS 38.321 cl. 5.7:

drx-HARQ-RTT-TimerDL

drx-RetransmissionTimerDL

drx-HARQ-RTT-TimerUL

drx-RetransmissionTimerUL

Table 12. The four HARQ-related DRX timers. The RTT timer is a permission to sleep; the retransmission timer is an obligation to wake. See the companion 11 DRX document for how these sit inside the wider Active Time rules.

14. Parameter Reference: ASN.1, Ranges and Effects

nrofHARQ-ProcessesForPDSCH

PDSCH-ServingCellConfig

pdsch-HARQ-ACK-Codebook

PhysicalCellGroupConfig

harq-ACK-SpatialBundlingPUCCH

PhysicalCellGroupConfig

dl-DataToUL-ACK

PUCCH-Config

codeBlockGroupTransmission

maxCodeBlockGroupsPerTransportBlock

PDSCH-CodeBlockGroupTransmission

codeBlockGroupFlushIndicator

pdsch-AggregationFactor

PDSCH-Config

pusch-AggregationFactor

PUSCH-Config

xOverhead

PDSCH-ServingCellConfig

processingType2Enabled

PDSCH-ServingCellConfig

DRX-Config

DRX-Config

downlinkHARQ-FeedbackDisabled-r17

Table 13. HARQ-relevant configuration. Note how much of HARQ has no configuration at all: the NDI semantics, the RV offsets, the base graph rules and the retry budget are all fixed or left to the scheduler.

15. Failure Modes and What Each One Means

Table 14. HARQ failure modes. Notice how many are detected by nobody — HARQ has almost no self-diagnosis, and its one-bit feedback has no integrity protection.

16. ASN.1 Extracts

HARQ configuration is spread across four places: the per-cell PDSCH and PUSCH serving-cell configurations, the cell-group physical configuration, the PUCCH configuration for K1, and the DRX configuration. Abridged from TS 38.331; ... marks omitted fields and extension markers.

PDSCH-ServingCellConfig ::= SEQUENCE {
    codeBlockGroupTransmission  SetupRelease {
                                  PDSCH-CodeBlockGroupTransmission } OPTIONAL,
    xOverhead                   ENUMERATED { xOh6, xOh12, xOh18 } OPTIONAL,
    nrofHARQ-ProcessesForPDSCH  ENUMERATED { n2, n4, n6, n10, n12, n16 }
                                                                   OPTIONAL,
    pucch-Cell                  ServCellIndex                      OPTIONAL,
    ...,
    [[ maxMIMO-Layers           INTEGER (1..8)                     OPTIONAL,
       processingType2Enabled   BOOLEAN                            OPTIONAL ]],
    [[ downlinkHARQ-FeedbackDisabled-r17
                                SetupRelease { DownlinkHARQ-FeedbackDisabled-r17 }
                                                                   OPTIONAL,
       nrofHARQ-ProcessesForPDSCH-v1700
                                ENUMERATED { n32 }                 OPTIONAL ]]
}

PDSCH-CodeBlockGroupTransmission ::= SEQUENCE {
    maxCodeBlockGroupsPerTransportBlock  ENUMERATED { n2, n4, n6, n8 },
    codeBlockGroupFlushIndicator         BOOLEAN,
    ...
}

PhysicalCellGroupConfig ::= SEQUENCE {
    harq-ACK-SpatialBundlingPUCCH  ENUMERATED { true }             OPTIONAL,
    harq-ACK-SpatialBundlingPUSCH  ENUMERATED { true }             OPTIONAL,
    p-NR-FR1                       P-Max                           OPTIONAL,
    pdsch-HARQ-ACK-Codebook        ENUMERATED { semiStatic, dynamic },
    tpc-SRS-RNTI                   RNTI-Value                      OPTIONAL,
    ...,
    [[ pdsch-HARQ-ACK-OneShotFeedback-r16     ENUMERATED { true }  OPTIONAL,
       pdsch-HARQ-ACK-OneShotFeedbackNDI-r16  ENUMERATED { true }  OPTIONAL,
       pdsch-HARQ-ACK-OneShotFeedbackCBG-r16  ENUMERATED { true }  OPTIONAL ]]
}

Listing 1. Downlink HARQ configuration. Note that pdsch-HARQ-ACK-Codebook is mandatory and per cell group — there is no way to run different codebook types on different carriers of one group.

PUCCH-Config ::= SEQUENCE {
    resourceSetToAddModList   SEQUENCE (SIZE (1..4)) OF PUCCH-ResourceSet
                                                                  OPTIONAL,
    resourceToAddModList      SEQUENCE (SIZE (1..128)) OF PUCCH-Resource
                                                                  OPTIONAL,
    format1                   SetupRelease { PUCCH-FormatConfig } OPTIONAL,
    dl-DataToUL-ACK           SEQUENCE (SIZE (1..8)) OF INTEGER (0..15)
                                                                  OPTIONAL,
    pucch-PowerControl        PUCCH-PowerControl                  OPTIONAL,
    ...
}

PDSCH-TimeDomainResourceAllocation ::= SEQUENCE {
    k0                        INTEGER (0..32)                     OPTIONAL,
    mappingType               ENUMERATED { typeA, typeB },
    startSymbolAndLength      INTEGER (0..127)
}

PUSCH-TimeDomainResourceAllocation ::= SEQUENCE {
    k2                        INTEGER (0..32)                     OPTIONAL,
    mappingType               ENUMERATED { typeA, typeB },
    startSymbolAndLength      INTEGER (0..127)
}

DRX-Config ::= SEQUENCE {
    drx-onDurationTimer          CHOICE { subMilliSeconds INTEGER (1..31),
                                          milliSeconds ENUMERATED {...} },
    drx-InactivityTimer          ENUMERATED { ms0, ms1, ..., ms1280 },
    drx-HARQ-RTT-TimerDL         INTEGER (0..56),
    drx-HARQ-RTT-TimerUL         INTEGER (0..56),
    drx-RetransmissionTimerDL    ENUMERATED { sl0, sl1, sl2, sl4, sl6, sl8,
                                              sl16, sl24, sl33, sl40, sl64,
                                              sl80, sl96, sl112, sl128,
                                              sl160, sl320 },
    drx-RetransmissionTimerUL    ENUMERATED { ... same ... },
    ...
}

Listing 2. The timing side: K1 candidates, K0/K2, and the two pairs of DRX HARQ timers. drx-HARQ-RTT-Timer* is in symbols while drx-RetransmissionTimer* is in slots — a units mismatch that has caused real misconfigurations.

17. Illustrative Message Traces

17.1 A downlink retransmission, decoded field by field

14:22:08.4120  [PHY-DL] PDCCH  DCI 1_1  CRC scrambled by C-RNTI 0x4601
                SFN 412  slot 7   (absolute slot 8247, 30 kHz)
                freq domain RA .............. 100 PRB from PRB 0
                time domain RA .............. row 2: k0=0, S=2, L=12
                MCS ......................... 15   -- Qm 4, R 616/1024
                NDI ......................... 1    -- stored value was 0
                RV .......................... 0
                HARQ process number ......... 3
                counter DAI ................. 0
                PUCCH resource indicator .... 1
                PDSCH-to-HARQ timing ind .... 1    -> dl-DataToUL-ACK[1]
                                                   -> K1 = 2 slots
14:22:08.4120  [MAC-DL] HARQ pid 3: NDI toggled 0 -> 1  => NEW DATA
                flush soft buffer for pid 3, store NDI = 1
                TBS ......................... 31752 bits (3969 bytes)
                code blocks ................. 4    -- BG1, Z_c 384
                N_RE ........................ 13200, coded bits 52800
                effective code rate ......... 0.604
14:22:08.4123  [PHY-DL] PDSCH decode  pid 3  CRC FAIL
                LDPC iterations ............. 8 (max)
                soft bits retained .......... 13200 per code block

14:22:08.4130  [PHY-UL] PUCCH format 1, 1 bit, HARQ-ACK = NACK
                SFN 412  slot 9  (8247 + K1 = 8249)

14:22:08.4145  [PHY-DL] PDCCH  DCI 1_1  C-RNTI 0x4601   SFN 412 slot 12
                MCS ......................... 15   -- unchanged
                NDI ......................... 1    -- UNCHANGED => retx
                RV .......................... 2
                HARQ process number ......... 3
14:22:08.4145  [MAC-DL] HARQ pid 3: NDI unchanged => RETRANSMISSION
                RV 2 -> k_0 = 33 x Z_c = 12672  (50.0 % of N_cb 25344)
                combine 13200 new soft bits at offset 12672
                accumulated coverage ........ ~96 % of the buffer
                effective code rate now ..... 0.31
14:22:08.4148  [PHY-DL] PDSCH decode  pid 3  CRC PASS  (3 iterations)
14:22:08.4155  [PHY-UL] PUCCH  HARQ-ACK = ACK   SFN 412 slot 14
14:22:08.4155  [MAC-DL] pid 3 released; TB delivered to demultiplexing

-- HARQ round trip: slot 7 -> slot 12 = 5 slots = 2.5 ms

Listing 3. One NACK and one successful retransmission, with the RV offset and the resulting code rate carried through. The falling code rate — 0.604 to 0.31 — is the incremental redundancy gain, quantified.

17.2 Dynamic codebook reconstruction after a missed PDCCH

14:31:55.0000  [CFG] pdsch-HARQ-ACK-Codebook = dynamic,
                     one serving cell, no total DAI field present

14:31:55.0025  [PHY-DL] DCI 1_1  slot 5   pid 2  NDI 1  cDAI 0  K1 4
14:31:55.0028  [PHY-DL] PDSCH    slot 5   pid 2  CRC PASS
14:31:55.0030  [PHY-DL] DCI 1_1  slot 6   pid 3  NDI 0  cDAI 1  K1 3
14:31:55.0033  [PHY-DL] PDSCH    slot 6   pid 3  CRC PASS
14:31:55.0035  [PHY-DL] PDCCH blind decode set exhausted, slot 7
                        -- no DCI found; the UE does not know one was sent
14:31:55.0040  [PHY-DL] DCI 1_1  slot 8   pid 5  NDI 1  cDAI 3  K1 1
14:31:55.0043  [PHY-DL] PDSCH    slot 8   pid 5  CRC PASS

14:31:55.0045  [MAC-UL] building Type-2 HARQ-ACK codebook for slot 9
                cDAI values received ........ 0, 1, 3
                gap detected between 1 and 3 -> 1 assignment missed
                codebook size ............... 4 bits
                bit 1 (cDAI 0, pid 2) ....... ACK
                bit 2 (cDAI 1, pid 3) ....... ACK
                bit 3 (missed) .............. NACK
                bit 4 (cDAI 3, pid 5) ....... ACK
14:31:55.0047  [PHY-UL] PUCCH format 2, 4 bits: 1 1 0 1   slot 9

14:31:55.0060  [PHY-DL] DCI 1_1  slot 11  pid 4  NDI 1 (unchanged)  RV 2
                        -- gNB retransmitting the TB the UE never saw;
                        -- to the UE, pid 4 has no stored NDI, so this
                        -- is treated as NEW DATA and decoded alone
14:31:55.0063  [PHY-DL] PDSCH    slot 11  pid 4  CRC FAIL
                        -- RV2 is not self-decodable; expected outcome
14:31:55.0075  [PHY-DL] DCI 1_1  slot 12  pid 4  NDI 1 (unchanged)  RV 3
14:31:55.0078  [PHY-DL] PDSCH    slot 12  pid 4  CRC PASS
                        -- RV2 + RV3 together cover enough of the buffer

Listing 4. The codebook survives the missed PDCCH, but the retransmission does not survive it cleanly: the UE has no soft bits to combine, so a non-self-decodable RV2 fails and a second attempt is needed. This is normal and is why RV0 is sometimes repeated in poor coverage.

17.3 Uplink HARQ, where the grant is the feedback

14:44:02.1000  [PHY-DL] DCI 0_1  C-RNTI 0x4601   slot 3
                HARQ process number ......... 7
                NDI ......................... 0    -- stored was 1 => NEW
                RV .......................... 0
                MCS ......................... 11
                k2 .......................... 3   -> PUSCH in slot 6
14:44:02.1015  [MAC-UL] pid 7: new transmission, TBS 6272 bits
14:44:02.1015  [PHY-UL] PUSCH  slot 6  pid 7  RV 0
               -- no PHICH exists. The UE now waits, holding the TB.

14:44:02.1040  [PHY-DL] DCI 0_1  C-RNTI 0x4601   slot 8
                HARQ process number ......... 7
                NDI ......................... 0    -- UNCHANGED
                RV .......................... 2
14:44:02.1040  [MAC-UL] pid 7: NDI unchanged => this is a NACK,
                        expressed as a grant. Retransmit from the buffer.
14:44:02.1055  [PHY-UL] PUSCH  slot 11  pid 7  RV 2

14:44:02.1090  [PHY-DL] DCI 0_1  C-RNTI 0x4601   slot 16
                HARQ process number ......... 7
                NDI ......................... 1    -- TOGGLED
                RV .......................... 0
14:44:02.1090  [MAC-UL] pid 7: NDI toggled => the previous TB was
                        received. Flush pid 7, build a new TB from the
                        LCP procedure, transmit.
               -- the toggle is the only acknowledgement that ever
               -- arrives for an uplink transport block

Listing 5. Three grants and no acknowledgement channel. The NDI toggling at 14:44:02.1090 is simultaneously the ACK for the old transport block and the grant for the new one. See the companion 09 LCP document for how the new TB's contents are chosen.

17.4 The failure that HARQ cannot see

15:02:11.2000  [PHY-DL] PDSCH  pid 9  NDI 1  RV 0   CRC FAIL
15:02:11.2010  [PHY-UL] PUCCH  HARQ-ACK = NACK for pid 9
                        UE transmit power .... 14.2 dBm
                        (gNB side) PUCCH DTX/ACK/NACK decision ... ACK
                        -- the gNB misread the NACK as an ACK
15:02:11.2010  [MAC-DL] (gNB) pid 9 acknowledged, process released
                        -- no retransmission will ever be scheduled
15:02:11.2010  [MAC-DL] (UE)  pid 9 still holds soft bits, waiting

15:02:11.2500  [MAC-DL] PDSCH  pid 9  NDI 0  RV 0
                        -- a completely different transport block
15:02:11.2500  [MAC-DL] (UE) NDI toggled => new data, flush pid 9
                        -- the old TB's soft bits are discarded. The TB
                        -- itself was never delivered and never will be
                        -- by HARQ.

15:02:11.3120  [RLC-DL] AM: SN gap detected, SN 4471 missing
                        t-Reassembly started
15:02:11.3620  [RLC-UL] RLC STATUS PDU: ACK_SN 4478, NACK_SN 4471
15:02:11.3700  [RLC-DL] retransmission of SN 4471 (segment 0)
15:02:11.3700  [MAC-DL] PDSCH  pid 12  NDI 1  RV 0   CRC PASS
                        -- carrying the RLC retransmission

-- HARQ counters for this interval:
--   PDSCH transmissions ....... 148
--   HARQ retransmissions ...... 14   (9.5 %  -- on target)
--   HARQ failures ............. 0
--   RLC AM retransmissions .... 3    <-- the real story is here

Listing 6. A NACK-to-ACK error. HARQ statistics are flawless — no failures, retransmission rate exactly on target — and a transport block was lost anyway. The only evidence is the RLC retransmission count. This is the pattern described in §15.

Two habits pay for themselves when reading traces like §17.4. First, always read HARQ retransmission counts next to RLC retransmission counts — HARQ alone cannot report the failure that matters most. Second, reconstruct the NDI history per process rather than reading each DCI in isolation; the NDI means nothing on its own, and a log line showing NDI = 1 is not information until you know what the previous value for that process was.

18. Release Deltas: Rel-15 to Rel-18

Table 15. HARQ changes by release. Confirm feature presence against the UE capability exchange — see the companion 26 UE Capability document.

19. Reading HARQ in Logs: A Checklist

1. Group everything by HARQ process ID first. A HARQ trace read in time order is nearly meaningless; read in per-process order it tells a story. Watch for process IDs above 15 — valid from Rel-17, and a common decoder bug (§18).

2. Reconstruct the NDI history per process. A single NDI = 1 line carries no information. Only the change from the previous transmission on that process does, and a flush event resets the reference (§4).

3. Check the RV against the attempt number. RV0 on a first attempt is normal. RV0 on every attempt means chase combining, which is a deliberate scheduler choice in poor coverage, not a fault. RV2 as the first thing a process sees means the initial PDCCH was missed, and a failure there is expected (§5, §17.2).

4. Verify the K1 arithmetic against the TDD pattern. Compute n + K1 and confirm it lands on a slot with usable uplink symbols. If some downlink slots have no reachable uplink slot, the scheduler is losing capacity silently (§8).

5. Establish the codebook type before interpreting any PUCCH payload. A 4-bit codebook read as 1 bit, or a semi-static codebook read as dynamic, makes every subsequent conclusion wrong. If the size looks implausible, look for a recent RRCReconfiguration (§9).

6. Follow the counter DAI sequence. Gaps are the record of missed PDCCHs, and they are the cheapest available PDCCH BLER estimate. A counter that wraps without a visible gap can hide four missed assignments (§9.1).

7. Read HARQ and RLC retransmission counts together, always. An excess of RLC retransmissions over HARQ retransmissions is the signature of NACK-to-ACK errors, which HARQ itself reports as perfect health (§15).

8. For uplink, look for the grant, not for feedback. There is no PHICH. Success is an NDI toggle on the next grant for that process, and "no grant" means neither success nor failure (§11).

9. Check whether the UE is in DRX before blaming the scheduler. A stalled process on a DRX UE with healthy statistics for active UEs points at drx-RetransmissionTimer, not at radio (§13).

10. Recompute configured-grant and SPS process IDs from the formula. They are in no message. A mismatch between the two sides' periodicity or process count corrupts data with no error reported anywhere (§3).

20. Glossary

21. References

• 3GPP TS 38.321 — NR MAC protocol specification. Clause 5.3.2 (downlink HARQ operation and the reception procedure), 5.4.1 (configured-grant HARQ process ID derivation), 5.4.2 (uplink HARQ operation), 5.7 (DRX, including drx-HARQ-RTT-Timer and drx-RetransmissionTimer behaviour).
• 3GPP TS 38.212 — Multiplexing and channel coding. Clause 5.2.2 (code block segmentation and CRC attachment), 5.3.2 (LDPC coding), 5.4.2.1 (rate matching, the circular buffer, N_cb, LBRM and Table 5.4.2.1-2 giving the RV starting positions), 6.2.2 and 7.2.2 (LDPC base graph selection), 7.3.1.1 and 7.3.1.2 (DCI formats 0_x and 1_x field definitions, including NDI, RV, HARQ process number, DAI, CBGTI and CBGFI).
• 3GPP TS 38.213 — Physical layer procedures for control. Clause 9.1.2 (Type-1 semi-static codebook), 9.1.3 (Type-2 dynamic codebook and the DAI), 9.1.4 (Type-3 one-shot, Rel-16), 9.2.3 (PUCCH resource and the DCI 1_0 K1 table), 9.2.5 (multiplexing HARQ-ACK on PUSCH).
• 3GPP TS 38.214 — Physical layer procedures for data. Clause 5.1.2 (PDSCH time-domain allocation and K0), 5.1.3 (modulation order, target code rate and the transport block size determination), Table 5.1.2.1-2 (RV sequence for pdsch-AggregationFactor), 5.1.7 (CBG-based transmission), 5.3 (UE PDSCH processing procedure time, N1), 6.1.2 (PUSCH time-domain allocation and K2), Table 6.1.2.1-2 (RV sequence for pusch-AggregationFactor), 6.4 (UE PUSCH preparation time, N2).
• 3GPP TS 38.331 — RRC protocol specification. PDSCH-ServingCellConfig, PDSCH-CodeBlockGroupTransmission, PUSCH-ServingCellConfig, PhysicalCellGroupConfig, PUCCH-Config (dl-DataToUL-ACK), PDSCH-TimeDomainResourceAllocation, PUSCH-TimeDomainResourceAllocation, DRX-Config, SPS-Config, ConfiguredGrantConfig.
• 3GPP TS 38.322 — RLC protocol specification, for the ARQ layer that catches what HARQ misses: maxRetxThreshold, t-PollRetransmit, t-Reassembly and the STATUS PDU.
• 3GPP TS 38.300 — NR overall description. Clause 5.4 and 6.2 for where HARQ sits in the protocol stack and its relationship with RLC.

Companion documents in this set

• 02 Radio Frame Structure — slots, symbols and numerology, which every K0/K1/K2 offset counts in.
• 03 Random Access — MSG3 and its use of HARQ process 0.
• 04 Timing Advance — timeAlignmentTimer expiry flushes every HARQ buffer, and the NTN mechanisms in §12 share its NTN-Config.
• 06 Channel Mapping — how DL-SCH and UL-SCH transport blocks relate to PDSCH and PUSCH.
• 07 MAC PDU and Control Elements — what is inside the transport block HARQ is protecting.
• 08 Scheduling — DCI formats, the TDRA tables that supply K0 and K2, SPS and configured grants, MCS tables, link adaptation and the pre-emption indication that makes CBG worthwhile.
• 09 LCP — how the contents of a new uplink transport block are chosen once an NDI toggle frees the process.
• 11 DRX — the full Active Time rules that §13's two timers plug into.
• 16 RLM and RLF — where RLC's maxRetxThreshold failure ends up.
• 26 UE Capability — processing capability 2, soft buffer size, and which of the Rel-16/17 features in §18 the UE actually supports.