As you may guess from the terminoloty itself, ACK NACK repetition is a method in which a sender (UE in current specification) transmit ACK/NACK multiple times in a row. In an aspect, we can say it is similar concept to TTI Bundling. The difference between Ack Nack Repetition and TTI Bundling is that TTI bundling is for PUSCH transmission (user data transmission) and Ack Nack Repetition is for PUCCH transmission.

Overall Ack Nack Repetition flow can be illustrated as shown below.

Figure 1. Ack/Nack Repetition with repetitionFactor = n4, drawn against the UE and SS subframe grids. Four uplink subframes now carry one acknowledgement, so the price of the feature appears in the downlink scheduling rate rather than in uplink power.

• The two ladders are subframe grids : the left one belongs to the UE and the right one to the SS. The numbers running down each side are the SFN and the subframe count, so you can read the 1 ms spacing straight off them.
• One solid arrow, three dashed arrows : the solid Ack is the first transmission, and the three dashed ones are the repeats. The repetition factor counts all four together. So n4 does not mean one Ack plus four repeats.
• The bracket at the top marks a blocked subframe : the note beside it says this subframe cannot be scheduled for transmission once the repetition factor is 4.
• The arithmetic in the note on the right : a 1000 subframe measurement window holds 125 DL-SCH at one every 8 ms, and each one produces 4 Ack transmissions. That is where the 500 Ack count and the 1/8 data rate on the figure come from.

The advantage and disadvatage of Ack/Nack repetition is similar to that of TTI bundling. In short, the advantage is that it increase the probability of Ack/Nack information at destination. The disadvantage is that it would cause some additional time delay (resulting in low throughput) since there should be a certain time period during which UL scheduling (DCI 0) should not be transmitted.

How to enable this feature (Ack/Nack Repetition) ? Just enable a couple of IEs in RRC message (RRCConnectionSetup or RRCConnectionReconfiguration) as shown below.

Figure 2. The same feature seen in a decoded rrcConnectionSetup. Two values are all it takes : repetitionFactor sets how many times the Ack is sent, and n1PUCCH-AN-Rep names the PUCCH resource that carries the repeats.

• The path down the tree tells you where the feature lives : radioResourceConfigDedicated, then physicalConfigDedicated, then pucch-ConfigDedicated, then ackNackRepetition. This is dedicated configuration, so it never arrives in a SIB.
• ackNackRepetition is set to setup : the field is a CHOICE with two branches, and the other branch is release. Later on the eNB sends release to switch the feature off.
• repetitionFactor reads n4 : that is exactly the case Figure 1 draws.
• n1PUCCH-AN-Rep reads 0 : this is a PUCCH resource index rather than a count, and 0 is an ordinary value for it.
• tdd-AckNackFeedbackMode sits below it with no value : the field is conditional on TDD, and this capture came from an FDD cell.

What you have read so far is the short version. The rest of this page works through the timing cost, the PUCCH resources involved, the ASN.1 behind Figure 2, and the cases where the feature cannot be used at all. Followings are the topics :

• What does the repetition factor cost in scheduling?
• Which PUCCH resource carries each repetition?
• How is Ack/Nack Repetition configured in RRC?
• When can Ack/Nack Repetition not be used?
• Reference

What does the repetition factor cost in scheduling?

Let's work out the price of this feature before we look at the configuration. The repetition factor is not only a count of transmissions. It also fixes how long the UE is unavailable for anything else in the uplink, and that is what costs the throughput.

36.213 calls this HARQ-ACK repetition, and clause 10.1.4 defines it. Once the eNB enables ackNackRepetition, the UE repeats every HARQ-ACK with the factor higher layers gave it. One detail decides everything that follows : the factor includes the initial transmission. So n4 gives one Ack and three repeats.

Two rules then apply while the window is open. First, the UE transmits only that HARQ-ACK on PUCCH in those subframes, and it transmits no other signal or channel there. Second, the UE sends no Ack repetitions for a PDSCH it detects in subframes n-3 to n, because those repeats would land inside the window.

Put the two rules together and the scheduling restriction appears on its own. Every downlink transport block now reserves a run of uplink subframes. The eNB gets no acknowledgement for any PDSCH it schedules inside that run, so it has to schedule the downlink less often. The opening of this page describes the same effect from the scheduler's side, where a UL grant also has to stay clear of the window.

Figure 3 shows this on an FDD subframe grid, with n as the first Ack subframe. The downlink row shows where the eNB may and may not start a transport block. The uplink row shows the four subframes the Ack now occupies.

Figure 3. The repetition window on FDD, drawn for repetitionFactor = n4. The four grey downlink subframes are the real cost of the feature, because a transport block started in any of them would never be acknowledged.

• The window is four uplink subframes wide : it opens at n, which is 4 ms after the PDSCH at n-4, and it closes at the end of n+3. The UE sends nothing else in between.
• The grey downlink subframes are n-3 to n : an Ack for a PDSCH there would start somewhere in n+1 to n+4, which overlaps the window, so its repeats are dropped.
• n+1 is the first downlink subframe that works again : its Ack starts at n+5, clear of the window.

• The factor includes the first transmission : n4 gives three extra copies rather than four. Budget the reliability gain on that basis.
• The cost is scheduling time, not uplink power : each Ack still uses the normal PUCCH power. What you spend is downlink opportunities.
• Higher factors get expensive quickly : n6 widens the window to six subframes, and the blocked downlink run widens with it.

Which PUCCH resource carries each repetition?

This is the part that surprises people the first time they read a PUCCH trace. The repeats do not always share a resource with the first Ack. Which resource the UE picks depends on how the PDSCH was scheduled in the first place.

Start from the normal case, without repetition. The UE derives the PUCCH resource for an Ack from the first CCE index of the PDCCH that scheduled the PDSCH. Nothing has to be signalled, because both sides compute the same index. That method needs a PDCCH to compute from.

With repetition enabled, 36.213 clause 10.1.4 splits the behaviour in two. Take a PDSCH that arrived with a PDCCH or an EPDCCH. It keeps the implicit resource for its first Ack only, and the remaining repeats move to n1PUCCH-AN-Rep. The same applies to a PDCCH or EPDCCH that releases downlink SPS, because it also has a CCE index.

A PDSCH with no corresponding PDCCH is the other case, and in practice that means downlink SPS. There is no CCE index to derive anything from. So every transmission, including the first, uses n1PUCCH-AN-Rep.

The consequence for the eNB is worth stating plainly. The eNB listens on two different PUCCH resources for one acknowledgement of a dynamically scheduled transport block. Figure 4 puts the two cases side by side, again for repetitionFactor = n4.

Figure 4. Resource selection for the four transmissions of one acknowledgement. Only the dynamically scheduled case uses two resources, and only its first transmission is implicit.

• The top row is the dynamically scheduled case : Ack #1 sits on the resource derived from the PDCCH CCE index, and Ack #2 to Ack #4 sit on n1PUCCH-AN-Rep.
• The bottom row is downlink SPS : no PDCCH means no CCE index, so all four transmissions use n1PUCCH-AN-Rep.
• An SPS release follows the top row : the release travels on PDCCH or EPDCCH, so there is a CCE index for the first Ack after all.

• n1PUCCH-AN-Rep is a resource index, not a count : it ranges from 0 to 2047 and points into the same PUCCH resource space as n1PUCCH-AN.
• A misconfigured n1PUCCH-AN-Rep is easy to miss : the first Ack still arrives on the implicit resource, so only the repeats go missing.
• SPS is the cleaner case to debug : every transmission uses one resource, so a missing Ack points at that one index.

How is Ack/Nack Repetition configured in RRC?

Figure 2 shows what a decoder makes of the configuration, and here is the ASN.1 underneath it. Only three fields are involved, so the definition is short. The one part worth reading carefully is the CHOICE at the top.

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

PUCCH-ConfigDedicated ::=           SEQUENCE {
    ackNackRepetition                   CHOICE{
        release                             NULL,
        setup                               SEQUENCE {
            repetitionFactor                    ENUMERATED {n2, n4, n6, spare1},
            n1PUCCH-AN-Rep                      INTEGER (0..2047)
        }
    },
    tdd-AckNackFeedbackMode             ENUMERATED {bundling, multiplexing}      OPTIONAL    -- Cond TDD
}

Read the CHOICE first. The field ackNackRepetition is not a boolean, and it has no default value. The eNB either sends setup, with both inner fields present, or it sends release. Release is how the feature is switched off in a later RRCConnectionReconfiguration, and a UE that never received setup simply does not have the feature.

The table below takes the four fields in the order they appear, and says what each one decides.

What did the later releases add?

Release 8 defined the three fields above, and the repetition behaviour has not changed since. What later releases added is a second antenna port and a repackaged copy of the whole IE. Both are easy to miss in a log, so they are worth knowing about before you search for a field that seems to be missing.

Release 10 added n1PUCCH-AN-RepP1-r10 inside PUCCH-ConfigDedicated-v1020. It carries the PUCCH resource for the second antenna port. 36.213 clause 10.1.4 allows repetition with PUCCH format 1a/1b on two antenna ports. In that case n1PUCCH-AN-Rep gives the resource for the first port, and n1PUCCH-AN-RepP1 gives the resource for the second.

Release 13 then repackaged everything into PUCCH-ConfigDedicated-r13, where the same three fields reappear with -r13 suffixes. Nothing about the repetition behaviour changed. If you are reading a Rel-13 or later log and cannot find ackNackRepetition, look for ackNackRepetition-r13 instead.

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

PUCCH-ConfigDedicated-r13 ::=       SEQUENCE {
    --Release 8
    ackNackRepetition-r13               CHOICE{
        release                             NULL,
        setup                               SEQUENCE {
            repetitionFactor-r13                ENUMERATED {n2, n4, n6, spare1},
            n1PUCCH-AN-Rep-r13                  INTEGER (0..2047)
        }
    },
    tdd-AckNackFeedbackMode-r13         ENUMERATED {bundling, multiplexing}      OPTIONAL,   -- Cond TDD
    --Release 10
    ...                                 -- pucch-Format-r13 and the format 3, 4 and 5 fields are not Ack/Nack Repetition related
    twoAntennaPortActivatedPUCCH-Format1a1b-r13  ENUMERATED {true}               OPTIONAL,   -- Need OR
    simultaneousPUCCH-PUSCH-r13         ENUMERATED {true}                        OPTIONAL,   -- Need OR
    n1PUCCH-AN-RepP1-r13                INTEGER (0..2047)                        OPTIONAL,   -- Need OR
    ...                                 -- the Release 11 and later fields are not Ack/Nack Repetition related
}

• setup and release are the only two branches : there is no third value and no implicit default, so the feature is present exactly when the eNB said setup.
• repetitionFactor has no n3 and no n5 : the usable values are n2, n4 and n6. The fourth code point is spare1 and carries no meaning.
• The -r13 names are the same fields : ackNackRepetition-r13, repetitionFactor-r13 and n1PUCCH-AN-Rep-r13 behave exactly as their Release 8 originals do.

When can Ack/Nack Repetition not be used?

Before turning this on in a live cell, check the limits. 36.213 clause 10.1.4 rules out two configurations outright, and the repetition window itself rules out a few more transmissions while it is open. The table below collects all four in one place.

The first row is the one that matters most in practice. Ack/Nack Repetition and carrier aggregation cannot be configured together, because repetition applies only to a UE with one serving cell. That restriction matches the situation the feature is for, where a UE at the cell edge runs on a single carrier and needs its uplink control channel to survive.

The second row is the TDD counterpart. On TDD the UE may be told to bundle its Ack bits or to multiplex them, and repetition works only with bundling. So tdd-AckNackFeedbackMode and ackNackRepetition have to be set consistently, even though they sit side by side as independent fields in the ASN.1.

• Repetition and carrier aggregation are exclusive : configure one or the other. It is a configuration error to add an SCell to a UE that has repetition, not a trade-off.
• On TDD, check the feedback mode first : multiplexing and repetition together will not work, whatever the repetition factor says.
• The window blocks more than the downlink : SR and periodic CQI are lost inside it too, so a UE with repetition reports less often than one without.

Reference

Two specifications carry everything on this page. One defines the fields the eNB sends, and the other defines what the UE does when it receives them. Both were read at the versions named below.

• 36.331 - E-UTRA; Radio Resource Control (RRC) protocol specification, v19.3.0. PUCCH-ConfigDedicated and PUCCH-ConfigDedicated-r13 sit in the PUCCH-Config IE definitions, and the PUCCH-Config field descriptions carry the pointers into 36.213.
• 36.213 - E-UTRA; Physical layer procedures, v19.4.0. Clause 10.1.4 is the HARQ-ACK Repetition procedure, and clause 10.1 carries the PUCCH resource rules it points at.