PUCCH Formats & UCI in 5G NR

Introduction

PUCCH is the dedicated physical channel that carries Uplink Control Information whenever the UE has no PUSCH to piggyback on. Its content is defined in TS 38.212, its physical structure and sequences in TS 38.211, and the resource-selection and timing procedures in TS 38.213. It is small in payload but enormous in importance: without it, HARQ cannot close its loop, the scheduler cannot know a UE wants resources, and link adaptation is blind.

PUCCH is active from almost the first moment of connected life. During initial access the UE uses a common PUCCH resource (from a table indexed by pucch-ResourceCommon in SIB1) to acknowledge Msg4 before any dedicated resources exist; from then on, dedicated resources configured in PUCCH-Config carry HARQ-ACK, scheduling requests, periodic/semi-persistent CSI, and beam-failure recovery requests throughout the connection.

This page covers what UCI contains, the five PUCCH formats and how one is chosen, short versus long PUCCH, PUCCH resource sets, the two HARQ-ACK codebook types and the Downlink Assignment Index, scheduling requests, when UCI piggybacks on PUSCH, and how PUCCH can live on a secondary cell.

Why UCI and PUCCH are needed

Concretely, four jobs make PUCCH indispensable. HARQ needs acknowledgements to decide whether to retransmit; the scheduler needs a scheduling request to learn a UE has data but no grant; link adaptation needs CSI to choose modulation, coding and precoding; and a UE whose serving beam has failed needs a link-recovery request to point the network at a usable beam. All four are tiny compared to data, so they get a purpose-built channel optimised for low overhead, multiplexing many UEs, and reaching the cell edge — rather than borrowing the heavyweight PUSCH machinery.

What UCI carries

UCI is the umbrella term for the control feedback a UE sends uplink. Any PUCCH transmission carries one of these information types, or a combination that has been multiplexed together into a single payload.

CSI itself splits into two parts. CSI part 1 has a fixed size the gNB can always decode (it includes RI/CRI and a wideband CQI), and it tells the receiver how big CSI part 2 is. That two-part structure matters later, because when UCI is squeezed for space, part 2 is the first thing to be dropped.

The five PUCCH formats

NR defines exactly five PUCCH formats, spanning tiny 1-bit acknowledgements up to large multi-bit CSI reports. Two axes separate them: payload size (up to 2 bits, or more than 2 bits) and duration (short = 1–2 symbols, long = 4–14 symbols). A third axis — whether several UEs can share one time/frequency resource — distinguishes formats that support multiplexing (0, 1, 4) from those that do not (2, 3).

Format 0 is unusual: it does not send coded bits at all. The UE picks a cyclic shift of a length-12 base sequence (a low-PAPR Zadoff–Chu-like sequence occupying one RB), and which shift it transmits encodes the 1 or 2 UCI bits — the gNB detects energy on the expected sequence. Because there is nothing to demodulate, Format 0 needs no DMRS and can occupy just a single symbol, making it the fastest way to return an ACK.

Format 1 spreads a 1–2 bit payload over 4–14 symbols, alternating data and DMRS symbols, and applies an orthogonal cover code (OCC) across the data symbols. Combined with cyclic shifts, this lets a large group of UEs occupy the very same physical resource block, which is why Format 1 is the workhorse for periodic ACK/SR from many users.

Format 2 is the short, higher-payload format: CP-OFDM with QPSK modulation and DMRS on one of every three subcarriers (REs #1, 4, 7, 10 in each RB). It is the only long-payload format that is also short, so it is chosen when you need > 2 bits back quickly. It cannot multiplex UEs.

Format 3 uses DFT-s-OFDM — the same single-carrier waveform as PUSCH — giving low peak-to-average power ratio and therefore the best uplink coverage. It scales in both frequency (multiple RBs) and time (up to 14 symbols), so it carries the largest UCI payloads. It does not multiplex UEs.

Format 4 also uses DFT-s-OFDM but confines itself to a single RB and applies a pre-DFT OCC (spreading factor 2 or 4), so a handful of UEs can share that one RB. You give up peak payload compared with Format 3 in exchange for that multiplexing capacity.

Short vs long PUCCH

Grouping the formats by duration gives the two families the specifications constantly refer to. Short PUCCH (Formats 0 and 2) occupies 1 or 2 OFDM symbols and is typically placed at the end of a slot, so a UE can acknowledge a downlink transmission within the same slot — the foundation of low-latency HARQ. Long PUCCH (Formats 1, 3 and 4) spans 4 to 14 symbols; spreading the same information over more time buys energy and coverage, which is what a cell-edge UE needs.

Long PUCCH can apply frequency hopping — transmitting the first half of the symbols in one part of the band and the second half in another — to grab frequency diversity on top of the time-domain energy gain. Short 2-symbol PUCCH can also hop within the slot. This is a large part of why long formats reach the cell edge that short formats cannot.

The exact slot in which the HARQ-ACK PUCCH lands is not free-floating: the downlink DCI (DCI format 1_0/1_1) carries a PDSCH-to-HARQ feedback timing field K1 that names how many slots after the PDSCH the ACK is due, drawn from the RRC list dl-DataToUL-ACK. That is how the gNB and UE agree on when to listen for the acknowledgement.

PUCCH resource sets and format selection

A UE does not pick a format from thin air; it picks a PUCCH resource, and the resource embeds a format. Resources are grouped into up to four PUCCH resource sets, and the set is chosen purely by the size of the UCI payload the UE has to send. Within the chosen set, a field in the scheduling DCI (the PUCCH resource indicator, PRI — a 3-bit field, so up to 8 resources) selects one of the resources; for the ACK case, the exact resource also depends on the CCE index of the PDCCH that scheduled the PDSCH, which spreads different UEs onto different resources automatically.

The first set (set 0) always holds ≤ 2-bit resources and therefore only Format 0 or Format 1. The remaining sets hold the higher-payload formats, and RRC configures the bit-count boundaries (maxPayloadMinus1) that decide where one set ends and the next begins. The UE computes the total number of UCI bits it must send in the slot, walks the sets from smallest to largest, and uses the first set whose maximum payload covers it. That is precisely how "how many bits" turns into "which format."

Before the UE has a dedicated configuration — during initial access — it uses a common PUCCH resource chosen from a standardised 16-row table via the pucch-ResourceCommon index (0…15) broadcast in SIB1 → PUCCH-ConfigCommon. Each row fixes a Format (0 or 1), a starting symbol, a number of symbols and a PRB offset. That gives the UE a way to send the Msg4 HARQ-ACK before any dedicated PUCCH resources exist.

HARQ-ACK codebooks and the DAI

When a UE must acknowledge several downlink transmissions in one PUCCH, the ACK bits are packed into a HARQ-ACK codebook. The codebook is simply the ordered set of ACK/NACK bits and the agreed rule for how many there are and in what order — the gNB must build the identical structure to interpret the report. NR defines two ways to construct it, chosen by pdsch-HARQ-ACK-Codebook = semiStatic or dynamic.

The semi-static (Type-1) codebook is built from the RRC-configured possibilities: for every PDSCH occasion that could map to this PUCCH (the candidate set spanned by the dl-DataToUL-ACK K1 values and the TDRA table), the UE reserves an ACK bit, whether or not a PDSCH was actually sent. The size never changes slot to slot, so the gNB and UE can never disagree about how many bits are in the report. The price is wasted bits on occasions that carried nothing (reported as NACK).

The dynamic (Type-2) codebook sizes itself to the actual scheduling using the DAI carried in DL DCI (formats 1_0/1_1). The counter DAI (C-DAI) — a 2-bit field — numbers each scheduled assignment in order across cells and monitoring occasions, and the total DAI (T-DAI), present with carrier aggregation, tells the UE the running total of assignments up to that point. By reading these, a UE that misses one DCI can still tell that a gap exists and keep the rest of the codebook aligned — it will not silently shift every subsequent ACK bit into the wrong position.

Scheduling Request, PUSCH multiplexing, and PUCCH on an SCell

The Scheduling Request (SR) is the UE's way of asking for an uplink grant when it has data to send but no PUSCH resource. An SR is essentially a 1-bit "please schedule me," sent on a dedicated PUCCH resource (Format 0 or 1). Its resources are set up by schedulingRequestResourceConfig, which binds an SR configuration to a PUCCH resource and gives it a periodicity and offset — the recurring occasions on which the UE may transmit an SR. Different logical channels can be tied to different SR configurations (via schedulingRequestID), so a latency-sensitive bearer can have far more frequent SR occasions than a background one. If the UE has data and no grant, it sends SR on the next configured occasion; if it has no valid SR resource, it falls back to the random-access procedure.

PUCCH-to-PUSCH multiplexing. The default carrier for UCI is PUCCH, but an uplink slot may also contain a PUSCH. If a scheduled PUSCH and a would-be PUCCH overlap in time (and satisfy the timeline conditions), the UE does not transmit both. Instead the UCI is multiplexed onto the PUSCH — "UCI on PUSCH," commonly called piggybacking. HARQ-ACK is mapped to resource elements right around the PUSCH DMRS (so it is well protected), and CSI is mapped to the remaining data REs. The single-carrier property and the power budget are preserved. A key detail: when there is not enough room, the UE drops in a defined order — CSI part 2 is sacrificed first, then CSI part 1, while HARQ-ACK is protected. The number of REs each UCI type consumes is scaled by the RRC betaOffset values, which trade UCI reliability against how much data the PUSCH loses.

PUCCH on a PUCCH-SCell. In carrier aggregation, all PUCCH normally lives on the primary cell (PCell), which can become a bottleneck when many secondary cells generate large HARQ-ACK feedback. NR therefore allows a PUCCH secondary cell (PUCCH-SCell): one designated SCell is configured with its own PUCCH resources, and the cells of the carrier-aggregation set are split into two PUCCH groups. The primary PUCCH group reports its feedback on the PCell; the secondary PUCCH group reports on the PUCCH-SCell. This spreads the uplink control load across two carriers and keeps the PCell from saturating when a UE aggregates many downlink cells.

Summary

PUCCH is the reserved uplink lane for control when there is no PUSCH to share. It carries four kinds of UCI — HARQ-ACK, SR, CSI and the link-recovery request — across five formats selected on two axes: payload (≤2 bits vs >2 bits) and duration (short 1–2 symbols vs long 4–14). Format 0 is sequence-selection with no DMRS for the fastest ACK; Format 1 multiplexes many low-payload UEs with OCC; Format 2 is short and higher-payload; Formats 3 and 4 use DFT-s-OFDM for coverage, with 4 trading payload for multiplexing. The UE turns "how many bits" into "which format" by walking up to four resource sets by payload size and letting the DCI PRI pick a resource. Multi-transmission acknowledgements are packed into a Type-1 semi-static or Type-2 dynamic HARQ-ACK codebook, the latter kept aligned by the counter/total DAI. When PUSCH overlaps, UCI piggybacks on it (HARQ-ACK protected, CSI part 2 dropped first); and under carrier aggregation a PUCCH-SCell can offload control from the PCell.

Quick Q&A