4G/LTE - Basic Procedures

 

 

 

Downlink Data Transmission Process (HARQ ACK/NACK)

 

A downlink transport block is not finished when the UE receives it. The eNB still has to learn whether the CRC passed. It needs that answer in time to reuse the HARQ process, so every PDSCH creates a reply that the uplink has to carry.

Which uplink channel carries that reply is the interesting part. It depends on whether the UE already holds an uplink grant for that subframe. It does not depend on whether the UE has data of its own to send.

Downlink Data Transmission Process (HARQ ACK/NACK)

The steps below follow one transport block from the network’s higher layers to the UE and back again. Read them together with Figure 1, which draws the same sequence with its timing attached. The branch at step v) is the one to read carefully.

Downlink data (i.e, PDSCH) transmission process can be summarized as follows.

    i) Network High Layer ( RRC or TE)  -> Lower Layer : Transmit the data toward the lower layer.

    ii) Network -> UE : Transmit the data via PDSCH

    iii) UE receive PDSCH data

    iv) UE checks CRC error for the PDSCH data

    v) Now we have two cases at this point,

        a) If UE has a UL Grant (DCI 0) for that subframe, UE send the result of CRC check(ACK/NACK) via PUSCH

        b) If UE does not have a UL Grant, UE sends the result CRC check via PUCCH

    vi) Network receives CRC check result from UE and do one of the following steps.

        a) If it receives ACK, Network transmit the next data (new data)

        b) If it receives NACK, Network HARQ process retransmit the exisiting data (with different revision)

The procedures described above can be illustrated as follows.

Downlink HARQ sequence with PDSCH and DCI 1, the ACK or NACK returning on PUCCH or PUSCH depending on whether a grant arrived, and a retransmission

Figure 1. Downlink data and its HARQ answer. The fork on the UE side is decided by whether a DCI 0 arrived, and the two 4 sub frames Delay brackets do not mean the same thing.

  • The staircase at the top right is where the data comes from. TE or RRC hands it down through PDCP and RLC to MAC. The red arrow out of MAC is the point where the network has a transport block to send.
  • Each downlink transmission is drawn as two lines, User data (PDSCH) and DCI 1 (PDCCH) with/without DCI 0. The PDSCH carries the data and the PDCCH carries the assignment that tells the UE where to find it.
  • The fork on the UE lifeline is labelled by grant, not by data. If Grant (DCI 0) sends the answer on ACK/NACK(PUSCH), and If No Grant (no DCI 0) sends it on ACK/NACK(PUCCH).
  • The upper 4 sub frames Delay is a rule. In FDD the UE answers a PDSCH from subframe n in subframe n+4, and it has no choice about that.
  • The lower 4 sub frames Delay is not a rule. Downlink HARQ is asynchronous, so 4 sub frames is the earliest the eNB can respond to a NACK rather than the offset it has to use.
  • The diamond If NACK is the only thing that leads to the retransmission at the bottom. An ACK sends the network to new data instead, which is step vi) a).
  • The answer is mandatory and the channel is not fixed : every PDSCH gets an ACK or a NACK, and the uplink carries it on whichever channel the grant situation dictates.
  • Only the first delay is a rule : the UE answers at n+4 in FDD, while the eNB retransmits whenever it schedules one.
  • A NACK does not restart the transfer : the network sends the same transport block again with a different redundancy version, and the UE combines the copies.

Which channel carries the ACK/NACK ?

Step v) offers two carriers, and the choice between them is not the UE’s. The eNB settles it earlier, when it decides whether to grant that UE a PUSCH in the answering subframe. By the time the UE has a CRC result, the decision is already made.

ACK/NACK on PUCCH

ACK/NACK on PUSCH

When it happens

No DCI 0 for that subframe

A DCI 0 scheduled a PUSCH in that subframe

What carries it

A PUCCH resource of its own

Multiplexed into the PUSCH beside the data

Where the resource comes from

Derived from the PDCCH, not signalled

It is the PUSCH the grant already allocated

What it costs

One PUCCH resource for each answering UE

Nothing beyond the PUSCH already granted

The PUCCH case leaves a question open. No grant exists, so the network has not named a PUCCH resource for this UE. The resource is derived rather than signalled. LTE takes it from the PDCCH that scheduled the PDSCH. The index of its first CCE is offset by a value the cell broadcasts in SIB2. The PUCCH Format 1 Location page works through that calculation.

That choice is economical rather than arbitrary. Two UEs scheduled by different PDCCHs have different first CCEs, so they use different PUCCH resources. The eNB allocates nothing and signals nothing, and no collision can occur.

The timing works the same way whichever channel is used. In FDD the UE answers a PDSCH from subframe n in subframe n+4. The eNB has no matching constraint on the way back, because downlink HARQ is asynchronous and its retransmissions are scheduled rather than timed.

  • The grant decides the carrier : a UE with a PUSCH in that subframe multiplexes its HARQ-ACK into it, and a UE without one uses PUCCH.
  • The PUCCH resource is derived, not granted : it follows from the first CCE of the scheduling PDCCH plus a broadcast offset, so nothing extra has to be signalled.
  • Only the uplink direction is timed : the answer is due at n+4 in FDD, while the downlink retransmission arrives when the eNB schedules it.

Reference