HARQ - HSUPA

HSUPA puts a HARQ protocol between the UE and the Node B, so a lost E-DCH transport block is retransmitted from the Node B side in a few tens of milliseconds. The RLC retransmission from the RNC is kept as the second line of recovery. The three lines below summarise the design, and the rest of this page explains each of them.

Uses Synchronous HARQ

The terminal should keep the unacknowledged data in the memory for any possible retransmission

Both Soft(Chasing) combining and Incremental Redundancy can be applicable.

I'll start with what "synchronous" means for the UE, because it explains the fixed number of HARQ processes. Then the two TTI lengths are shown on a timing diagram. The last two sections cover the redundancy version and the end of a retransmission cycle.

Followings are the topics to be covered in this page.

How does the UE know which HARQ process to use ?

In HSDPA, the Node B names the HARQ process on the HS-SCCH for every transmission. HSUPA has no field for this on the E-DPCCH. So both sides must work out the process from the timing alone, and this is what synchronous HARQ means here.

25.321 clause 11.8.1.4 gives the rule. The UE computes the HARQ process ID from the CFN, and for the 2 ms TTI also from the subframe number inside that frame.

10 ms TTI : CURRENT_HARQ_PROCESS_ID = CFN mod HARQ_RTT, with HARQ_RTT = 4.
2 ms TTI : CURRENT_HARQ_PROCESS_ID = (5 x CFN + subframe number) mod HARQ_RTT, with HARQ_RTT = 8.

The number of HARQ processes is equal to HARQ_RTT. This means a process comes back exactly one round trip after its previous transmission. At that point the ACK or NACK for the previous transmission has already arrived on the E-HICH. So the process either sends new data or retransmits the old data, and it never waits.

The same timing also carries the retransmission. A retransmission always goes out on the same process, one round trip later. For this reason the UE cannot move a retransmission to an earlier TTI, and the Node B always knows which soft buffer to combine it with.

The processes can also be restricted. With the 2 ms TTI, RRC can limit which processes may carry scheduled or non-scheduled data. An absolute grant with the scope "Per HARQ process" can also activate or deactivate one process. With the 10 ms TTI, only the scope "All HARQ processes" is valid in CELL_DCH.

Uplink MIMO in Release 11 doubles the count for the 2 ms TTI. Processes 0 to 7 then map to the primary stream and processes 8 to 15 map to the secondary stream.

No process ID is signalled : the UE and the Node B both derive it from the CFN and the subframe number.
Process count equals the round trip : 4 processes for the 10 ms TTI and 8 for the 2 ms TTI, so no process waits for its feedback.
A retransmission comes exactly one round trip later : it goes out on the same process, and the UE cannot move it.

10 ms TTI

The 10 ms TTI was the first HSUPA configuration, and every HSUPA UE supports it. The long TTI gives more energy per transport block, so cell edge UEs often keep it. The price is a long HARQ round trip.

Max 4 HARQ Process are being used.

The diagram below shows one HARQ round trip for the 10 ms TTI. The UE sends a 10 ms E-DPDCH frame together with its E-DPCCH. The Node B answers on the E-HICH, which lasts 8 ms, that is 12 slots. The gap from the end of the UE transmission to the start of the E-HICH is marked as 14-16 ms. The gap from the end of the E-HICH to the next UE transmission is marked as 5.5-5.7 ms.

HSUPA HARQ timing for 10 ms TTI

The same process transmits again 30 ms, or 3 TTIs, after the end of its previous frame. So a process repeats every 40 ms, and 4 processes keep the UE busy in every TTI.

UE side : two 10 ms E-DPDCH and E-DPCCH frames of the same HARQ process, 30 ms apart. The second one is either new data or a retransmission, depending on the E-HICH.
Red arrow : the frame travels to the Node B. The Node B then decodes it within the 14-16 ms window.
E-HICH : 12 slots in 25.211 for a UE with the 10 ms TTI. 25.214 clause 6B.3.1 says that the E-HICH frame for SFN i carries the answer for the E-DPDCH frame for SFN i-3.
5.5-5.7 ms : the UE processing time. In this time the UE reads the ACK or NACK and prepares the next transmission of that process.
The ranges : 25.211 clause 7.10 derives the E-HICH frame offset from the DPCH timing of the UE, so the two gaps move a little from one UE to another.

2 ms TTI

The 2 ms TTI came with HSUPA in Release 6 as an optional UE capability. It cuts the round trip to 16 ms, but it needs twice as many HARQ processes as the 10 ms TTI. The diagram below shows why.

Max 8 HARQ Process are being used.

The picture has the same layout as the one for the 10 ms TTI. The UE sends a 2 ms subframe of E-DPDCH and E-DPCCH. The E-HICH now lasts 2 ms, that is 3 slots. The gap before the E-HICH is marked as 6.1-8.1 ms, and the gap after it is marked as 3.5-5.5 ms.

HSUPA HARQ timing for 2 ms TTI

The same process transmits again 14 ms, or 7 TTIs, after the end of its previous subframe. So a process repeats every 16 ms, and 8 processes keep the UE busy in every TTI.

UE side : two 2 ms subframes of the same HARQ process, 14 ms apart.
E-HICH : 3 slots in 25.211 for a UE with the 2 ms TTI. The Node B processing window is 6.1-8.1 ms, which is much shorter than for the 10 ms TTI.
3.5-5.5 ms : the UE processing time between the end of the E-HICH and the next subframe of the process.
Round trip : 16 ms instead of 40 ms. This is the main latency gain of the 2 ms TTI.

The 2 ms TTI has a cost too. Each transport block gets only one fifth of the energy of a 10 ms block at the same power. For this reason a network often configures the 10 ms TTI near the cell edge. Release 12 also added TTI switching by HS-SCCH order, so the UE can change between the two lengths while it stays in CELL_DCH.

How are Chase Combining and Incremental Redundancy selected ?

The page summary says that both chase combining and incremental redundancy can be applied. The UE does not choose between them. RRC sets one field for the E-DCH, and the RSN on the E-DPCCH does the rest.

The field is harq-Info in the E-DCH part of the added or reconfigured UL TrCH information. 25.331 clause 10.3.5.7d gives its meaning. With "rv0", the UE uses only E-DCH RV index 0, so every retransmission sends the same bits, and this is chase combining. With "rvtable", the UE uses an RV index that depends on the RSN, and this is incremental redundancy.

Following is based on 25.331 v19.0.1 (Release 19)

UL-AddReconfTransChInformation-r14 ::= CHOICE {
    dch-usch                            SEQUENCE {
        ul-TransportChannelType             UL-TrCH-Type,
        transportChannelIdentity            TransportChannelIdentity,
        transportFormatSet                  TransportFormatSet
    },
    e-dch                               SEQUENCE {
        ul-MAC-HeaderType                   ENUMERATED { mac-iis }              OPTIONAL,
        modeSpecific                        CHOICE {
            fdd                                 SEQUENCE {
                tti                                 E-DCH-TTI,
                secondaryTTI                        E-DCH-TTI                   OPTIONAL
            },
            tdd                                 NULL
        },
        harq-Info                           ENUMERATED { rv0, rvtable },
        addReconf-MAC-d-FlowList            E-DCH-AddReconf-MAC-d-FlowList-r7   OPTIONAL
    }
}

E-DCH-TTI ::=                       ENUMERATED { tti2, tti10 }

With "rvtable", 25.212 Table 16 maps the RSN to the RV index. The mapping also depends on the code rate, that is on the ratio Nsys / Ne,data,j between the systematic bits and the available bits.

RSN	RV index if Nsys / Ne,data,j < 1/2	RV index if 1/2 <= Nsys / Ne,data,j
0	0	0
1	2	3
2	0	2
3	floor(TTIN / NARQ) mod 2, times 2	floor(TTIN / NARQ) mod 4

The RSN has only 2 bits, so it stays at 3 from the third retransmission on. From that point the RV index follows the TTI number TTIN. TTIN is the CFN for the 10 ms TTI and 5 x CFN + subframe number for the 2 ms TTI. The Node B knows TTIN too, so it can still tell which RV was sent. The E-DPCCH page covers the RSN field itself.

rv0 means chase combining : every transmission uses RV index 0.
rvtable means incremental redundancy : the RV index follows the RSN, and after RSN 3 it follows the TTI number.
The RSN is not the RV : the same RSN gives a different RV at a low code rate and at a high code rate.

When does the UE stop retransmitting ?

A HARQ process cannot keep the data forever, because it has to free the buffer for new data. Let's look at the two things that end the cycle. The first is an ACK, and the second is the transmission limit of the HARQ profile.

At a new transmission, E-TFC selection gives the HARQ process a HARQ profile. The profile holds the power offset and the maximum number of transmissions. RRC configures these per MAC-d flow with "E-DCH MAC-d flow power offset" and "E-DCH MAC-d flow maximum number of retransmissions", which is an integer from 0 to 15.

25.321 clause 11.8.1.1.2 then flushes the HARQ buffer in three cases.

ACK from the serving radio link set : the serving cell has the data, so the process is finished.
ACK from any radio link set, when the block held higher layer data : in soft handover a non-serving Node B can also receive the data, and MAC-es in the SRNC combines what arrives.
CURRENT_TX_NB reaches the maximum : the process gives up, and recovery is left to RLC.

Soft handover explains the second case. On the E-HICH, a cell in the serving radio link set sends +1 for ACK and -1 for NACK. A cell outside it sends +1 for ACK and nothing for NACK. So only a positive answer is heard from a non-serving Node B. The UE soft combines the ACK/NACKs that come from the same radio link set, as 25.214 clause 6B.1 specifies.

A block that carries only Scheduling Information is a special case. For it, only an ACK from the serving radio link set counts, because only the serving Node B schedules the UE. So the UE keeps retransmitting a lone SI until the serving cell acknowledges it or the limit is reached.

The HARQ profile sets the limit : the limit is per MAC-d flow, so delay sensitive flows can use fewer transmissions.
One ACK is enough in soft handover : this holds when the block carries higher layer data.
A lost HARQ block is not lost data : RLC AM in the UE and the SRNC still recovers it, only more slowly.

Reference

[1] 3GPP TS 25.321 v19.0.0 - clause 11.8.1.1, HARQ operation, and clause 11.8.1.4, E-TFC selection

[2] 3GPP TS 25.212 v19.0.0 - clause 4.9.2.2, RSN mapping and Table 16

[3] 3GPP TS 25.211 v19.0.0 - clause 5.3.2.4, E-HICH, and clause 7.10, E-HICH timing

[4] 3GPP TS 25.214 v19.0.0 - clause 6B, E-DCH related procedures

[5] 3GPP TS 25.331 v19.0.1 - clause 10.3.5.2, 10.3.5.7d and the ASN.1 of clause 11.3