CBG (Code Block Group) retransmissions in 5G

Hello Experts,
Question about CBG (code block group) retransmissions in 5G.
Say we have a TB scheduled in 5G that failed to be decoded by UE.
Inside that TB there are 24 CB(code blocks) among those 24, 22 were decoded correctly where as 2 failed to be decoded (I see that UE tries 16 times to decode them but still fails).

My question is: how gNB knows which 2CB failed to be decoded among the 24 sent?
Will this 2 CBs be included in a new transmission and will NDI bit will be toggled or not?

My understanding so far: Ack Nack at L1 is given for each code block separately. And these CB are only retransmitted again.

Not sure it is this way.
In my case, the very same TB was retransmitted again (although 22 CB were ok and 2 were nok) with another RV and MCS = 31( not changed) and recombine packets.
And it is the same procedure for all TBs that fails.
All are retransmitted again (with same TB size, different RV, using recombining between 1st transmission and retransmission and with MCS = 31).
Then what’s the use of CBs?

This doesn’t.look.correct. The retransmission should be CBG based, with each CBG having it’s own Harq ID.

Agree with @Nitin
Harq is either by TB or by CBG (max 8 groups)
CBG retx should be configured by RRC
Which vendor implemented CBG based retx?!

A CBG is a group of code blocks (CBs) based on which HARQ ACK/NACK and re-transmissions will be performed in NR. The UE will decode these CBGs and will send the ACK/NACK for each of the individual CBG and only the erroneously received CBGs are retransmitted by the gNB. A Code Block Group Transmission Information (CBGTI) field is included in the DCI format 1_1 to tell the UE which CBGs are retransmitted. The CBGTI field uses a bitmap of length equal to the configured number of CBG per TB.

1 Like

We have also observed same behavior which you had explained but need to check CBGTI.
Thanks

In this video you can also find a great explanation on CBG (Code Block Group) :point_right: https://www.youtube.com/watch?v=n5y_ZpG8Zdk&t=277s