In normal case, when network send a grant (DCI 0), UE transmit PUSCH at only one specific subframe (4 ms after the DCI 0 reception). TTI Bundling is a method in which UE transmit a PUSCH in multiple subframes in a row (4 subframes according to current specification). In other words, UE transmit a PUSCH in a 'BUNDLED TTI'.

Why does LTE need this at all? A UE at the cell edge is limited by its transmit power, not by the scheduler. Sending the same transport block in four TTIs collects four times the energy at the eNB, and it does so within one HARQ round trip. That is the trade the rest of this page examines: more subframes per packet in exchange for coverage and a short delay.

Followings are the topics to be covered in this page.

• How TTI Bundling works ?
• Isn't it too much waste of subframes ?
• PHICH timing when PUSCH reception failed
• Where is TTI bundling allowed, and what does it restrict?
• Reference
• Get the Test Procedure and Log / Amarisoft TechAcademy

How TTI Bundling works ?

The basic rule is simple. One DCI 0 schedules a bundle of four consecutive PUSCH transmissions, and each of the four carries the same transport block with a different redundancy version. The eNB can soft-combine all four before it decodes, and it answers only once for the whole bundle.

Typical case of TTI Bundling can be illustrated as shown below.

One TTI bundle in FDD. DCI 0 in subframe 0 schedules PUSCH in subframes 4 to 7, and the single PHICH comes 4 ms after the last PUSCH of the bundle.

Read the diagram from top to bottom. The UE decodes DCI 0 in subframe 0 of frame 0 and starts the bundle 4 subframes later, in subframe 4. It then transmits in subframes 4, 5, 6 and 7 without waiting for any feedback, with the redundancy versions labelled a, b, c and d. The PHICH arrives in subframe 1 of frame 1, which is subframe 11 counted from the DCI. That is 4 ms after the last transmission, not after the first one.

In some aspect, you may say this is a kind of wasting resources. Then Why we need this kind of method ?

The simple answer is to increase the possibility of data reception at the destination.

Then you may ask "Why not just rely on normal HARQ retransmission mechanism ?". If the destination fail to decode a data, it would send NACK or do DTX and then UE can retransmit it and then the data delivery would be guaranteed.

That is true, but this kind of normal retransmission mechnism cause a certain time delay (e.g, in FDD case, single retransmission would case 8 ms delay. see here for general UL scheduling) This delay can cause a very bad user experience in time critical data communication like VoLTE.

Therefore, in a case where the communication is for time critical communication and UE is in the area of poor coverage (e.g, cell edge), it would not be a bad idea to enable TTI bundling. (But I haven't seen any case in which this is enabled in live network, at least as of now Aug, 2013).

How to enable TTI bundling for a specific UE ?

It is simple. Just enable a ttiBundling IE as shown below. (But the real implementation and optimization may not as easy as it sound).

A decoded RRC Connection Reconfiguration from a capture. The ttiBundling field is a BOOLEAN in ul-SCH-Config, inside mac-MainConfig of radioResourceConfigDedicated.

The capture shows where the switch sits. The eNB sends it in radioResourceConfigDedicated, so it applies to one UE only, and it can turn it on or off with any later reconfiguration. A retransmission of a bundle is again a bundle of four TTIs.

• Four TTIs, one transport block : TTI_BUNDLE_SIZE is 4, and the redundancy version changes in each TTI.
• No feedback inside a bundle : the UE sends all four TTIs before any PHICH arrives.
• One PHICH per bundle : 4 ms after the last TTI of the bundle.
• Configured per UE : ttiBundling in ul-SCH-Config, sent by RRC Connection Reconfiguration.

Isn't it too much waste of subframes ?

A bundle occupies four subframes, and the PHICH comes much later than in normal operation. So a single HARQ process would leave the UL idle most of the time. The question is whether the eNB can fill that idle time with other data from the same UE.

Looking at the illustration at the beginning, you might think this is too much waste of subframes, partly because of multiple retransmission and partly because of scheduling restriction (the empty subframes you saw in the illustration at the beginning).

There is no way to reduce the waste of subframe caused by retransmission, but there is some way to reduce the wast of subframe caused by scheduling restriction. If you are allowed to use only one HARQ process, there would be only one way of scheduling/transmission as the illustration shown at the beginning. However, we can use multiple HARQ in LTE and if you interleave the multiple HARQ, you can schedule the resources as shown below that transmit PUSCH at every subframe.

The diagram below shows four HARQ processes, each drawn in its own colour. DCI 0 is the thick solid arrow, the PHICH is the dashed arrow and the PUSCH is the thin arrow, as the legend at the upper right says. Each new bundle starts where the previous one ends, so the UE transmits PUSCH in every subframe from subframe 4 onward.

Four interleaved HARQ processes in FDD TTI bundling. Four bundles of four TTIs fill the 16 subframes of one bundling HARQ round trip.

The numbers match 36.213 v19.4.0 clause 8.0. For FDD with TTI bundling there are 4 uplink HARQ processes, instead of 8 in normal operation. The PHICH of a bundle comes 4 subframes after its last TTI. For a PHICH in subframe n-5, the UE starts the retransmission bundle in subframe n+4, which is 9 subframes after the PHICH. So the HARQ round trip of a bundle is 16 subframes, from subframe 4 of frame 0 to subframe 0 of frame 2 in the diagram above. Four processes of four TTIs each exactly fill it, which is why the diagram reaches continuous transmission and no fifth process is needed.

Release 12 adds a second pattern. With e-HARQ-Pattern-r12 set to TRUE, the UE takes the retransmission from a PHICH in subframe n-1 instead of n-5. The round trip becomes 12 subframes, and FDD bundling then uses 3 HARQ processes. The retransmission therefore comes 4 ms earlier, which matters for VoLTE with its tight delay budget.

• 4 HARQ processes in FDD bundling : 3 with e-HARQ-Pattern-r12.
• 16 subframe round trip : 12 subframes with e-HARQ-Pattern-r12.
• Interleaving removes the idle subframes : the only cost left is the repetition itself.

PHICH timing when PUSCH reception failed

Does the PHICH move when part of a bundle is lost? The eNB may miss the first TTI, the last TTI or one in the middle, and a naive design could move the PHICH with it.

Now you may have another question. According to the illustration at the beginning, it seems that PHICH response (ACK / NACK( seems to be transmitted 4 ms after the last PUSCH in the TTI Bundle.  Should it be always like this (i.e, PHICH 4 ms after the last PUSCH) ?  How about sending PHICH 4 ms after the first PUSCH in the TTI ? Is this 'Not allowed' ? What if some of PUSCH got lost or received with CRC error as shown below. Would PHICH timing vary in these cases ?

The two diagrams below show six cases, labelled A to F. Each one keeps DCI 0 in subframe 0 and the bundle in subframes 4 to 7. A dashed arrow marks the TTI that failed. A CRC error means the eNB received the TTI but could not decode it. Loss (DTX) means the eNB did not detect the transmission at all. Cases A and B hit the first TTI, cases C and D the last TTI, and cases E and F the second and third TTI.

Six ways a bundle can be partly lost. The position of the failed TTI changes, but the bundle itself always ends in subframe 7.

In 3GPP 36.321 5.4.2.1 HARQ entity, you may find the answer to these questions as below :

When TTI bundling is configured, the parameter TTI_BUNDLE_SIZE provides the number of TTIs of a TTI bundle. TTI 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 triggered without waiting for feedback from previous transmissions according to TTI_BUNDLE_SIZE. The HARQ feedback of a bundle is only received for the last TTI of the bundle (i.e the TTI corresponding to TTI_BUNDLE_SIZE), regardless of whether a transmission in that TTI takes place or not (e.g. when a measurement gap occurs). A retransmission of a TTI bundle is also a TTI bundle. TTI bundling is not supported when the UE is configured with one or more SCells with configured uplink.

According to this statement, the PHICH timing for all the case illustrated above the answer is same as follows.

The PHICH timing for all six cases. It always follows the last TTI of the bundle, whatever happened to the individual TTIs.

36.213 v19.4.0 clause 9.1.2 states the same rule from the physical layer side. For subframe bundling operation, the PHICH resource is associated with the last subframe in the bundle. So the PHICH position depends only on the grant, never on which TTIs the eNB decoded. The PHICH value may change, but the timing does not. The MAC text quoted above has changed only slightly since it was copied. In 36.321 v19.3.0 the last sentence reads "when the MAC entity is configured with one or more SCells with configured uplink".

For some additional information regarding PUSCH, PHICH in TTI Bundling, refer to following docuements

36.321 7.5 TTI_BUNDLE_SIZE value

The parameter TTI_BUNDLE_SIZE is 4.

36.213 8.0 UE procedure for transmitting the physical uplink shared channel

When a UE is configured with higher layer parameter ttiBundling and configured with higher layer parameter e-HARQPattern-r12 set to FALSE or not configured, for FDD and subframe bundling operation, the UE shall upon detection of a PDCCH/EPDCCH with DCI format 0 in subframe n intended for the UE, and/or a PHICH transmission in subframe n-5 intended for the UE, adjust the corresponding first PUSCH transmission in the bundle in subframe n+4 according to the PDCCH/EPDCCH and PHICH information.

The 36.213 quote above is from an earlier version. In 36.213 v19.4.0 clause 8.0 the UE shall "perform a corresponding first PUSCH transmission in the bundle in subframe n+4", and only "if a transport block corresponding to the HARQ process of the first PUSCH transmission is generated". The timing is unchanged. The same clause also gives the e-HARQ-Pattern-r12 variant, where the PHICH is in subframe n-1.

• PHICH follows the last TTI of the bundle : even when that TTI was lost or not sent.
• A partly lost bundle is still one bundle : the eNB combines what it received and answers once.
• The timing is fixed by the grant : 4 ms after subframe n+7 in FDD.

Where is TTI bundling allowed, and what does it restrict?

TTI bundling was designed for one narrow case: a power-limited UE sending small, delay-sensitive packets. So 36.331 and 36.213 allow it only in some configurations, and they restrict the grant while it is on. Let's collect those rules in one place.

The switch is the ttiBundling field of ul-SCH-Config in MAC-MainConfig. The listing below shows it together with e-HARQ-Pattern-r12, which the eNB may set only when ttiBundling is TRUE.

Following is based on 36.331 v19.3.0 (Release 19)

MAC-MainConfig ::=                  SEQUENCE {
    ul-SCH-Config                       SEQUENCE {
        maxHARQ-Tx                          ENUMERATED {
                                                n1, n2, n3, n4, n5, n6, n7, n8,
                                                n10, n12, n16, n20, n24, n28,
                                                spare2, spare1}     OPTIONAL,   -- Need ON
        periodicBSR-Timer                   PeriodicBSR-Timer-r12   OPTIONAL,   -- Need ON
        retxBSR-Timer                       RetxBSR-Timer-r12,
        ttiBundling                         BOOLEAN
    }                                                               OPTIONAL,   -- Need ON
    drx-Config                          DRX-Config                  OPTIONAL,   -- Need ON
    timeAlignmentTimerDedicated         TimeAlignmentTimer,
    phr-Config                          CHOICE {
        release                             NULL,
        setup                               SEQUENCE {
            periodicPHR-Timer                   ENUMERATED {sf10, sf20, sf50, sf100, sf200,
                                                            sf500, sf1000, infinity},
            prohibitPHR-Timer                   ENUMERATED {sf0, sf10, sf20, sf50, sf100,
                                                                sf200, sf500, sf1000},
            dl-PathlossChange                   ENUMERATED {dB1, dB3, dB6, infinity}
        }
    }                                                               OPTIONAL,   -- Need ON
    ...,
    ...                                 -- the r9 to r11 extension groups are not TTI bundling related
    [[  e-HARQ-Pattern-r12                  BOOLEAN                 OPTIONAL,   -- Need ON
        ...                             -- the rest of this group is not TTI bundling related
    ]],
    ...                                 -- the r13 to r19 extension groups are not TTI bundling related
}

The ttiBundling field description in 36.331 lists where the eNB may enable it. TTI bundling works for FDD and for TDD configurations 0, 1 and 6. It also works for TDD configurations 2 and 3 when symPUSCH-UpPts-r14 is configured. The eNB does not configure it for the SCG, and it does not combine it with SCells with configured uplink or with eIMTA. For a TDD PCell, it also does not combine it with semi-persistent scheduling.

While bundling is on, 36.213 clause 8.6.1 limits the grant. The modulation order is QPSK, and the resource allocation is limited to 3 PRBs. A UE that reports noResourceRestrictionForTTIBundling-r12 can operate without the PRB limit. Both limits make sense for the target case. A power-limited UE gains nothing from a wide allocation or a high modulation order, because it cannot give the extra PRBs enough power.

A few more rules complete the picture. Msg3 of the random access procedure is never bundled, so a UE at the cell edge must get Msg3 through with normal HARQ. A periodic CSI report that collides with a bundle is dropped, and the eNB does not configure simultaneous PUCCH and PUSCH with bundling. Finally, ttiBundling does not apply to BL/CE UEs. Those UEs use the PUSCH repetition of CE mode instead.

• FDD and some TDD configurations only : TDD 0, 1 and 6, plus 2 and 3 with symPUSCH-UpPts-r14.
• No UL carrier aggregation with bundling : and never on the SCG.
• QPSK and at most 3 PRBs : unless the UE supports noResourceRestrictionForTTIBundling-r12.
• Msg3 is never bundled : bundling starts only after RRC has configured it.

Reference

[1] 3GPP TS 36.321 v19.3.0 - clause 5.4.2.1, HARQ entity, and clause 7.5, TTI_BUNDLE_SIZE value

[2] 3GPP TS 36.213 v19.4.0 - clause 8.0, UE procedure for transmitting the physical uplink shared channel, clause 8.6.1, Modulation order and redundancy version determination, and clause 9.1.2, PHICH Assignment Procedure

[3] 3GPP TS 36.331 v19.3.0 - clause 6.3.2, MAC-MainConfig