The HARQ-ACK codebook is one of those NR topics that can look much harder than it really is. The equations in 38.213 are detailed, but the basic question is simple:

When several downlink results are reported in one uplink transmission, which ACK/NACK bit belongs to which downlink transmission?

The codebook answers that question. It defines the number, order, and meaning of the HARQ-ACK bits that the UE sends on PUCCH or multiplexes onto PUSCH.

IMPORTANT : A HARQ-ACK codebook is not a compression table that turns many ACK/NACK bits into a shorter message. It is an ordered bit sequence. Channel coding of that UCI happens later, following the physical-layer procedures in 38.212.

• Start with the simplest HARQ feedback
• Why NR needs a codebook
• How the codebook is built and sent
• Type 1, Type 2, and Type 3
  • Type 1: semi-static codebook
  • Type 2: dynamic codebook
  • Type 3: one-shot codebook
• DAI: counter DAI, total DAI, and missed DCI
  • DAI compared with the other DCI fields
  • Counter DAI (C-DAI)
    • Two-bit DAI and modulo-4 wraparound
    • How C-DAI exposes a missed DCI
  • Total DAI (T-DAI)
  • DAI in an uplink DCI
  • Practical DAI checklist
• How many HARQ-ACK bits are generated?
• CBG-based feedback
• Important RRC and DCI parameters
• Detailed worked examples: RRC, DCI, and UCI
  • Common illustrative PUCCH configuration
  • Example 1: one DCI, one PDSCH, and one-bit PUCCH
  • Example 2: three DCIs and three PDSCHs share one PUCCH
  • Example 3: Type 1 keeps candidate positions
  • Example 4: two CBG DCIs create eight HARQ-ACK bits
  • Example 5: HARQ-ACK is sent on PUSCH
  • Example 6: Type-3 one-shot report
• Common points of confusion
• Reference

Start with the Simplest HARQ Feedback

Suppose the gNB sends one PDSCH containing one transport block (TB). The UE tries to decode the TB and produces one result:

• ACK (bit value 1) if the TB is decoded correctly.
• NACK (bit value 0) if the TB is not decoded correctly.

The feedback timing is controlled by the PDSCH-to-HARQ_feedback timing value, commonly called K1. The value comes from the corresponding DCI field or from an RRC-configured dl-DataToUL-ACK list. In plain language, K1 tells the UE which uplink slot is used to report the result of that PDSCH.

If only one TB result is due in that uplink occasion, the payload can be just one HARQ-ACK bit. The difficult part begins when several results point to the same reporting occasion.

NOTE : HARQ process number and codebook position are different ideas. The HARQ process number identifies the stop-and-wait process whose TB may be retransmitted. The codebook position tells the gNB where to find a particular feedback result in this UCI report.

Why NR Needs a Codebook

One PUCCH or PUSCH transmission may need to carry feedback for more than one downlink event. For example:

• several PDSCH receptions in different slots can use K1 values that point to the same uplink slot;
• carrier aggregation can bring feedback from multiple serving cells together;
• a PDSCH can contain one or two TBs, depending on the configured number of codewords;
• CBG-based retransmission can require several feedback bits for one TB;
• SPS PDSCH receptions and an SPS release can also create HARQ-ACK information.

Both the UE and gNB therefore need the same deterministic ordering rule. Otherwise, a bit sequence such as ACK, NACK, ACK would be ambiguous. The codebook rules tell both sides which serving cell, PDCCH monitoring occasion, PDSCH occasion, TB, or CBG each position represents.

A useful mental model is an ordered checklist:

candidate or detected downlink events → ordered HARQ-ACK positions → PUCCH/PUSCH transmission

How It Works from PDSCH to Uplink Feedback

1. The gNB schedules downlink data. A DCI normally identifies the PDSCH resources, HARQ process, new-data indicator, redundancy version, and feedback timing. SPS PDSCH is a notable case in which a PDSCH can arrive without a new scheduling PDCCH.
2. The UE decodes the applicable TB or CBGs. It records ACK or NACK for each feedback unit. With ordinary TB-based feedback, there is one result per TB. With CBG-based feedback, there is one result per configured code block group position.
3. The UE finds the reporting occasion. K1 maps the PDSCH or related DCI event to a particular uplink slot.
4. The UE selects the applicable codebook rule. A semi-static configuration leads to Type 1, a dynamic configuration leads to Type 2, and a one-shot request can trigger Type 3.
5. The UE places the results in the specified order. Depending on the type, that order is based on configured candidate PDSCH occasions, detected assignments and DAI values, or serving-cell/HARQ-process indexes.
6. The UE sends the UCI. HARQ-ACK is carried on PUCCH unless the multiplexing rules place it on a simultaneous PUSCH. The gNB applies the same ordering rules to interpret every bit.

The PUCCH and PUSCH subclauses in 38.213 are not separate codebook types. They are two transmission cases for the same basic Type-1 or Type-2 codebook concept, with some channel-specific details.

Codebook Determination Type: Type 1, Type 2, and Type 3

Type 1: Semi-Static Codebook

Type 1 first works out the set of candidate PDSCH reception occasions that could map to the same feedback occasion. This set is derived from configuration such as the time-domain resource allocations and K1 values. A codebook position can therefore exist even when no PDSCH was actually scheduled in that candidate occasion.

• The size and positions are predictable from the configuration.
• Unused or missed candidate positions are normally represented by NACK according to the detailed rules.
• It can use more bits than the number of PDSCHs that were actually scheduled, but it does not depend as heavily on detecting every scheduling DCI to determine the payload layout.

Type 2: Dynamic Codebook

Type 2 follows the downlink assignments that the UE actually detects for the reporting occasion. Its payload can therefore be smaller when only a few PDSCHs are scheduled. The tradeoff is that the gNB and UE must keep a consistent count of those assignments.

• Counter DAI tracks the running number of applicable downlink assignments.
• Total DAI, where applicable, indicates the total count at a scheduling point.
• These DAI values help expose a missed DCI and keep the bit positions aligned across monitoring occasions and serving cells.

NOTE : Type 1 is not simply “single-slot” feedback, and Type 2 is not simply “multi-slot” feedback. Both can collect results associated with multiple occasions. The real distinction is semi-static candidate positions versus a dynamically accumulated assignment count.

Type 3: One-Shot Codebook

Type 3 is a one-shot status report. When the UE detects a DCI whose One-shot HARQ-ACK request is set to 1, it reports the available HARQ-ACK state for the configured or indicated serving cells and HARQ process numbers. The basic ordering is by serving-cell index and then HARQ-process index, with TB/CBG positions added as applicable.

This is useful when the gNB wants a broader HARQ status snapshot instead of only the feedback tied to the normal Type-1 or Type-2 reporting occasion. Type 3 is not a beam-feedback or TCI-state codebook; beam management uses other reporting and control mechanisms.

DAI: How the UE and gNB Keep a Dynamic Codebook Aligned

DAI means Downlink Assignment Indicator. Despite the name, DAI is not the ACK/NACK result and it is not the HARQ process number. It is counting information carried in DCI so that the UE and gNB agree on the number and order of downlink assignments represented in a dynamic Type-2 HARQ-ACK codebook.

The shortest useful definition is:

DAI is the sequence number used to place a downlink assignment at the correct position in a dynamic HARQ-ACK report.

DAI Compared with the Other DCI Fields

For example, HARQ process 5 does not automatically go into codebook position 5. If it is the second applicable assignment for a particular PUCCH occasion, its feedback normally occupies the position identified by that assignment sequence, not by the HARQ process ID.

Counter DAI (C-DAI)

Counter DAI is the running count. For the conventional case of one PDSCH scheduled by each DCI, it behaves like assignment number 1, assignment number 2, assignment number 3, and so on. More precisely, 38.213 counts applicable {serving cell, PDCCH monitoring occasion} pairs in a defined traversal:

1. process PDCCH monitoring occasions from earlier to later;
2. within the same monitoring occasion, process serving cells in ascending cell-index order;
3. when more than one applicable DCI/PDSCH belongs to the same cell and monitoring occasion, process them in ascending PDSCH starting-time order.

That exact definition matters for carrier aggregation and newer multi-PDSCH scheduling. In a simple single-cell trace with one DCI/PDSCH per monitoring occasion, however, it is safe to read C-DAI as the running DCI-assignment count.

Why a 2-Bit DAI Counts 1, 2, 3, 4 and Then Wraps

The two DAI bits are codepoints for a count that wraps every four assignments. They are interpreted as follows:

So six consecutive assignments carry the codepoints 00, 01, 10, 11, 00, 01. The UE combines the codepoint with the earlier DAI history to unwrap the count. It should not treat 00 as an ordinary binary value of zero.

NOTE : The count is associated with the assignments belonging to a particular HARQ-ACK codebook/reporting occasion. It is not one never-ending global counter, and it is not the same as the HARQ process number.

How C-DAI Exposes a Missed Scheduling DCI

Consider three assignments whose feedback all goes to the same PUCCH:

The UE sees C-DAI jump from 1 to 3. It therefore knows that assignment position 2 is missing, even though it does not know the PDSCH details contained in the missed DCI. The UE preserves alignment by placing NACK in that missing position. If A and C both decoded successfully, the report is:

[A, missing B, C] = [ACK, NACK, ACK] = [1, 0, 1]

This is the main reason DAI is so important. Without the count, the UE might send [ACK, ACK]. The gNB could then interpret the second ACK as the result for B instead of C.

LIMITATION : DAI does not magically reconstruct the missed DCI. It only reveals a missing position when a later counter value or a total-DAI value exposes the gap. If the UE misses the last assignment and receives no later count that reveals it, the UE may not know from C-DAI alone that the final assignment existed.

Total DAI (T-DAI)

Total DAI gives the total number of applicable assignment pairs accumulated up to the current PDCCH monitoring occasion. When total DAI is present in several DCIs in the same monitoring occasion, those DCIs carry the same total value. This is especially useful with carrier aggregation, where several serving cells can contribute feedback to one PUCCH.

Assume two serving cells and one PDCCH monitoring occasion. The gNB schedules one PDSCH on each cell:

If the UE receives DCI A but misses DCI B, A’s T-DAI still says that the total has reached two. The UE can therefore retain a second codebook position and report NACK there. C-DAI says “where am I in the sequence?”; T-DAI says “how many assignments exist up to this monitoring occasion?”

In a common DCI 1_1 dynamic-codebook configuration:

• with one configured DL serving cell, the DAI field is often 2 bits carrying only C-DAI;
• with multiple configured DL serving cells, the DAI field is commonly 4 bits: the 2 MSBs carry C-DAI and the 2 LSBs carry T-DAI;
• other features, such as enhanced dynamic codebooks, multiple codebooks, PDSCH groups, or joint feedback across CORESET pools, can change the width and interpretation. Always derive the field layout from the applicable 38.212 rules and RRC configuration.

What About DAI in an Uplink DCI?

DAI can also appear in an uplink grant such as DCI 0_1 or DCI 0_2 when HARQ-ACK may be multiplexed on the scheduled PUSCH. Do not confuse this with the counter DAI carried in the downlink scheduling DCIs:

• DAI in DCI 1_x accompanies downlink assignment(s) and helps build/order the dynamic HARQ-ACK codebook.
• DAI in DCI 0_x accompanies a PUSCH grant and tells the UE which HARQ-ACK amount/state the gNB expects to be multiplexed on that PUSCH. In the usual dynamic-codebook case it acts as an uplink total-DAI indication, with detailed behavior depending on the configured codebook and PDSCH groups.

This is why a trace may show DAI in both a downlink grant and an uplink grant. They participate in the same HARQ-ACK coordination, but they are viewed from different sides of the exchange.

Practical DAI Checklist for Reading a Log

1. Group only the DCIs whose K1 values point to the same HARQ-ACK reporting occasion and codebook.
2. Determine the DAI field width from the DCI format and RRC configuration. Split C-DAI and T-DAI when the field contains both.
3. Convert each 2-bit codepoint using 00→1, 01→2, 10→3, 11→4, then unwrap modulo 4 using the earlier values.
4. Follow the specification ordering across PDCCH monitoring occasions and serving cells; do not sort by HARQ process number.
5. Look for a counter jump or a total larger than the number of detected assignments. A gap becomes a NACK placeholder.
6. After the logical codebook is complete, determine its UCI size, PUCCH resource set, last-DCI PRI, and final PUCCH/PUSCH transmission.

How Many HARQ-ACK Bits Are Generated?

There is no single “one bit per PDSCH” formula for every NR case. A practical way to reason about the payload size is to ask the following questions in order.

1. What is the feedback unit?
   • Without CBG feedback: normally one bit per TB.
   • With CBG feedback: one bit per CBG position for each applicable TB, including padding positions required by the configured maximum.
2. How many TBs can the PDSCH carry?
   • The configured maxNrofCodeWordsScheduledByDCI determines whether one or two codewords/TBs have to be considered.
   • NR uses one codeword for up to four transmission layers and can use two codewords when more than four layers are transmitted. The antenna configuration by itself does not tell us the number of TBs; the actual transmission rank and codeword configuration matter.
   • If spatial bundling is configured, feedback for two TBs can be bundled into one result according to the applicable rule.
3. Which downlink occasions belong to this uplink report?
   • Type 1 counts the applicable candidate PDSCH occasions derived from configuration.
   • Type 2 counts the applicable detected assignments, using DAI to maintain the sequence.
   • Type 3 walks through the configured or indicated serving cells and HARQ processes.
4. Are there special events?
   • A PDSCH received without a corresponding PDCCH generates one corresponding HARQ-ACK bit.
   • A detected PDCCH indicating an SPS PDSCH release also generates one corresponding HARQ-ACK bit.
   • SPS receptions, carrier aggregation, multicast, different priority indexes, and enhanced codebook options add ordering rules that must be checked in the applicable release of 38.213.

NOTE : The number of HARQ processes does not normally equal the number of bits in a Type-1 or Type-2 report. Many HARQ processes may exist in parallel, while a particular report contains only the results associated with its reporting occasion. Type 3 is the case that explicitly walks across HARQ process numbers.

CBG-Based HARQ-ACK

Normally, the whole TB is the feedback unit: the UE sends one ACK only if the complete TB passes its CRC. With Code Block Group (CBG) retransmission, the TB is divided into groups so that the gNB can retransmit only the groups that were not decoded correctly.

• The RRC field codeBlockGroupTransmission enables the feature for the serving cell.
• maxCodeBlockGroupsPerTransportBlock configures a maximum of 2, 4, 6, or 8 CBG positions per TB.
• The actual number of CBGs depends on the number of code blocks in the TB and the grouping procedure in 38.214.
• A CBG is ACK only when every code block in that group was received correctly. If at least one code block in the group failed, that CBG is NACK.
• If the actual number of CBGs is smaller than the configured maximum, the remaining codebook positions are filled with NACK as specified in 38.213.
• For a CBG retransmission, a CBG that was decoded successfully in an earlier transmission remains ACK in the feedback state.

The CBG procedure changes the granularity of each feedback item. It does not replace Type 1 or Type 2; CBG bits are placed into the applicable codebook using the corresponding ordering rules.

Example : Suppose the maximum is configured as 4 CBGs per TB, but this TB contains only 3 actual CBGs. If the outcomes are ACK, NACK, ACK, the four positions are reported as ACK, NACK, ACK, NACK. The last NACK is padding for the unused configured position.

Important Parameters and Where They Come From

The algorithm is specified mainly in 38.213 clause 9.1, while most long-term configuration comes from RRC in 38.331 and per-transmission information comes from DCI. Similar-looking names across those specifications can be confusing, so the following table focuses on each field’s job.

Detailed Worked Examples: RRC, DCI, and UCI/PUCCH

The examples below use deliberately small configurations so that the codebook can be followed by hand. They are not complete RRC messages or complete DCI payloads; only the fields that matter to HARQ-ACK are shown.

ASSUMPTIONS : Slot numbers are simplified. UL and DL use the same numerology, PDSCH ends in the numbered DL slot, no sub-slot PUCCH or NTN offset is used, and every shown feedback slot is valid for uplink. Under these assumptions, it is convenient to write feedback slot = PDSCH slot + K1. The full timing procedure in 38.213 should be used for an actual implementation.

Common Illustrative PUCCH Configuration

Most examples use the following simplified RRC configuration. The exact PRBs, symbols, hopping, scrambling IDs, power-control fields, and spatial relation are omitted.

PhysicalCellGroupConfig:
  pdsch-HARQ-ACK-Codebook = dynamic       // Type-2 codebook

PDSCH-Config:
  maxNrofCodeWordsScheduledByDCI = n1     // one TB per PDSCH here

PDSCH-ServingCellConfig:
  codeBlockGroupTransmission = absent     // TB-based feedback

PUCCH-Config:
  dl-DataToUL-ACK = { 4, 3, 2, 1 }

  resourceSetToAddModList:
    set 0: resourceList = { 10 }           // O_UCI <= 2 bits
    set 1: resourceList = { 20 }, maxPayloadSize = 20

  resourceToAddModList:
    resource 10: format1                   // chosen in our 1- or 2-bit example
    resource 20: format2                   // chosen in our 3- to 20-bit examples
                

Because dl-DataToUL-ACK has four entries, the illustrative DCI 1_1 uses a 2-bit PDSCH-to-HARQ_feedback timing indicator:

NOTE : This list-index mapping applies to DCI formats such as DCI 1_1. DCI 1_0 uses its specified mapping to K1 values {1, 2, 3, 4, 5, 6, 7, 8}, rather than indexing this four-entry example list.

In the examples, PRI means the PUCCH resource indicator. Also, do not hard-code DAI as a 2-bit field in an implementation. Two counter-DAI bits are common for a single DL serving cell. Under configurations such as multiple DL serving cells or inclusion of total DAI, DCI 1_1 can instead carry four DAI bits: counter DAI plus total DAI.

Example 1: One DCI, One PDSCH, and One-Bit PUCCH

The gNB sends one DCI 1_1 in slot 100 and schedules a one-TB PDSCH in the same slot. Only the fields relevant to this example are shown.

The logical HARQ-ACK payload size is O_ACK = 1. With no SR or CSI to add, O_UCI = 1. Because this is at most two bits, the UE chooses PUCCH resource set 0. PRI = 0 points to the first resource in that set, resource 10, which this example configured as PUCCH Format 1.

The DAI value is shown as a logical running value. In the common 2-bit counter-DAI representation, logical values 1, 2, 3, and 4 are encoded cyclically as 00, 01, 10, and 11. The exact DAI field width depends on the DCI format and configuration.

Example 2: Three DCIs and Three PDSCHs Share One PUCCH

This is the important codebook case. The gNB sends three separate DCI 1_1 messages. Assume K0 = 0, so each DCI schedules its PDSCH in the same slot as the DCI. Each DCI uses NDI = 1 and RV = 0 for a new transmission. Different K1 values make all three results arrive at slot 204; assume the last DCI, DCI C, has PRI = 0.

For this single-serving-cell example, the Type-2 order follows the detected assignments across the PDCCH monitoring occasions. The logical codebook is therefore:

HARQ-ACK codebook = [A, B, C] = [ACK, NACK, ACK] = [1, 0, 1]

Now follow the PUCCH decision in the correct order:

1. The codebook contains three HARQ-ACK bits, so O_ACK = 3.
2. If there is no simultaneous SR or CSI, O_UCI = 3.
3. Three bits do not fit resource set 0, whose limit is two. The UE therefore selects resource set 1.
4. The PUCCH resource indicator from the last applicable DCI—DCI C in this case—selects a resource within set 1. If PRI = 0, it selects the first entry, resource 20.
5. Resource 20 is configured as PUCCH Format 2, so the UE channel-codes and transmits the three UCI bits on that resource in slot 204.

IMPORTANT : Three bits do not inherently mean “PUCCH Format 2.” Three bits select a resource set that supports the payload. PRI then selects a configured resource in that set, and that resource can use Format 2, 3, or 4. It is Format 2 here only because resource 20 was configured that way.

If a positive scheduling request is also due in slot 204, the applicable SR information is combined with the HARQ-ACK according to the UCI multiplexing rule. In a simple one-SR case, the logical UCI becomes [HARQ-ACK bits, SR bit] = [1, 0, 1, 1], so O_UCI becomes 4. Resource set 1 still applies.

Example 3: Type 1 Keeps Candidate Positions Even with Only Two DCIs

Change the common RRC setting to pdsch-HARQ-ACK-Codebook = semiStatic. Assume the Type-1 procedure uses the configured PDSCH time-domain allocations and K1 list to produce four candidate occasions for PUCCH slot 304:

M_A = {A0, A1, A2, A3}

The gNB transmits only two scheduling DCIs: one for A0 and one for A2. A0 decodes as ACK and A2 decodes as NACK. No PDSCH is scheduled for A1 or A3.

The result is [1, 0, 0, 0], not a two-bit [1, 0] report. O_ACK is 4, so this example again selects resource set 1 and, with PRI = 0 in the last applicable DCI, resource 20 / PUCCH Format 2. DAI can still be present in a DCI, but it is not what creates the Type-1 candidate positions.

Example 4: Two DCIs with CBG Feedback Create Eight HARQ-ACK Bits

Now enable CBG feedback and keep the dynamic Type-2 codebook:

PhysicalCellGroupConfig:
  pdsch-HARQ-ACK-Codebook = dynamic

PDSCH-ServingCellConfig:
  codeBlockGroupTransmission = setup:
    maxCodeBlockGroupsPerTransportBlock = n4
                

DCI A in slot 400 schedules HARQ process 2 with K1 = 2. DCI B in slot 401 schedules HARQ process 5 with K1 = 1. Both results therefore use PUCCH slot 402. Each applicable DCI 1_1 carries the HARQ process number, DAI, K1, PRI, and CBG transmission information (CBGTI). For this simplified initial-transmission example, assume CBGTI indicates that all four groups are transmitted.

PDSCH B has only three actual CBGs, but the configured maximum is four, so its last position is filled with NACK. With DCI A followed by DCI B, the Type-2 payload is:

[A-CBG0..3, B-CBG0..3] = [1, 1, 0, 1, 1, 0, 1, 0]

O_ACK = 8. Resource set 1 is selected, and the last applicable DCI’s PRI selects resource 20 / PUCCH Format 2 in this configuration. Notice how just two DCIs produced eight HARQ-ACK information bits.

Example 5: The Codebook Is Due on PUCCH, but It Is Sent on PUSCH

Return to Example 2, whose logical Type-2 codebook is [1, 0, 1] in slot 204. Suppose the gNB also sends DCI 0_1 scheduling a PUSCH that overlaps the intended PUCCH in slot 204, and assume the priorities and timing satisfy the UCI-on-PUSCH multiplexing rules.

PUSCH-Config:
  uci-OnPUSCH = setup:
    betaOffsets = semiStatic:
      betaOffsetACK-Index1 = ...  // up to 2 HARQ-ACK bits
      betaOffsetACK-Index2 = ...  // more than 2 and up to 11 bits
      betaOffsetACK-Index3 = ...  // more than 11 bits
      scaling = ...
                

• The HARQ-ACK codebook itself does not change: it is still [1, 0, 1].
• The UE resolves the PUCCH/PUSCH overlap and multiplexes those UCI bits onto the scheduled PUSCH.
• Because O_ACK = 3, the semi-static configuration uses the category associated with betaOffsetACK-Index2. The beta offset helps determine how many PUSCH resources are used to protect the HARQ-ACK bits.
• The UE does not also transmit the original HARQ-ACK PUCCH in this assumed case. UL-SCH data and HARQ-ACK UCI share the PUSCH according to the 38.212 multiplexing procedure.

If dynamic beta offsets are configured instead, the applicable DCI 0_1/0_2 field selects the beta-offset entry. DCI 0_1 can also contain a DAI field used by the PUSCH HARQ-ACK procedure. These are uplink-grant controls; they do not replace the downlink DAI values that built the Type-2 ordering.

Example 6: Type-3 One-Shot Report

Assume two serving cells, one TB per PDSCH, eight DL HARQ processes per cell, and no CBG feedback. RRC enables pdsch-HARQ-ACK-OneShotFeedback. A DCI sets the One-shot HARQ-ACK request field to 1, provides K1 leading to slot 504, and provides PRI = 0.

Suppose the stored results are:

• Cell 0, processes 0..7: [ACK, ACK, NACK, ACK, NACK, NACK, ACK, ACK]
• Cell 1, processes 0..7: [NACK, ACK, ACK, NACK, ACK, ACK, NACK, ACK]

The basic Type-3 ordering walks serving cells in ascending index and, within each cell, HARQ processes in ascending index:

[1,1,0,1,0,0,1,1, 0,1,1,0,1,1,0,1]

O_ACK = 16, so resource set 1 is selected in the common configuration. PRI = 0 selects resource 20 / PUCCH Format 2. For a process whose applicable HARQ-ACK information is not available, the detailed Type-3 procedure supplies the specified NACK value. Enhanced Type 3 can limit the requested serving cells and process numbers, reducing the payload.

Common Points of Confusion

• Codebook does not mean compression. The payload is still a sequence of HARQ-ACK information bits.
• Type 1 is not selected by DAI. It is selected by the semi-static RRC setting and derives positions from candidate occasions. DAI is central to Type 2.
• Type 3 is not beam feedback. It is a one-shot, serving-cell/HARQ-process-oriented status report.
• CBG feedback is a granularity option. It can be used within the applicable codebook construction; it is not a replacement for Type 1 or Type 2.
• PUCCH and PUSCH do not define different codebook families. They are different uplink carriers of the HARQ-ACK UCI, with separate detailed procedures.
• One PDSCH is not always one bit. Two TBs or CBG-based reporting can create more than one HARQ-ACK bit for a single PDSCH reception.

Reference

• 3GPP TS 38.213 / ETSI TS 138 213, clause 9.1: HARQ-ACK codebook determination
• 3GPP TS 38.212 / ETSI TS 138 212: UCI channel coding and multiplexing on PUCCH/PUSCH
• 3GPP TS 38.331: RRC definitions for PhysicalCellGroupConfig, PDSCH-ServingCellConfig, and related fields
• 3GPP TS 38.214 / ETSI TS 138 214: PDSCH procedures and CBG determination
• ShareTechnote: 5G/NR Code Block Group (CBG)
• ShareTechnote: 5G/NR PUCCH