Summary of proposals on CBG-based retransmission 3GPP TSG RAN WG1 Meeting #90bis R1-17xxxxx Prague, CZ, 9th – 13th, October 2017 Agenda item: 7.3.3.3 Summary of proposals on CBG-based retransmission LG Electronics

Open Issues Number of CBGs for multiple CW case Maximum configurable number of CBGs Handling on the case of TB CRC check fail DCI composition for CBGTI, CBGFI, and NDI Support of TB level HARQ-ACK feedback

Issue 1: Number of CBGs for multiple CW case How to configure the maximum number of CBGs per TB in case configured with multiple CWs for MIMO? Alt 1: The maximum number of CBGs per TB is configured to be the same between TBs (majority) Alt 2: The maximum number of CBGs per TB is separately configured for each TB Alt 3: A single maximum number of CBGs is configured to be shared by multiple TBs Observation: According to the companies’ contributions, each alternative seems to have some benefits in terms of HARQ operation simplicity or CBG configuration flexibility or TBS-dependent CBG assignment. Considering potential further efforts and the majority view, I suggest to go with Alt 1 Possible proposal 1 In multiple CW case, the maximum number of CBGs per TB is configured to be the same between TBs

Issue 2: Maximum configurable number of CBGs On the maximum configurable number of CBGs, a few companies provide the potential values as follows: 8 : ZTE 4 ~ 12 : Nokia ceil(TBSmax/D), where D = 8448 bits : AT&T Observation: According to offline discussions with some companies (at least, Samsung, Qualcomm), the companies (including LG) suggest “8” as the maximum configurable number of CBGs, with consideration of both DCI and UCI overhead So, I suggest the followings for single CW case and multiple CW case where the latter case would need further discussion Possible proposal 2 In single CW case, the maximum configurable number of CBGs per TB is 8 In multiple CW case, following two alternatives are down-selected Alt 1: the maximum configurable number of CBGs per TB is 8 (e.g. total number of CBGs per PDSCH could be 16) Alt 2: the maximum configurable number of CBGs per PDSCH is 8 (e.g. number of CBGs per TB could at most be 4)

Issue 3: Handling on TB CRC check fail case There is one FFS in the previous agreement on: How to handle the case if TB CRC check is failed while CB CRC check is passed for all the CBs, when the semi-static HARQ-ACK codebook which includes HARQ-ACK corresponding to all the CBGs (including the non-scheduled CBG(s)) is used Observation: In my understanding, this issue has clear majority and no more concern, so the following can be agreeable Possible proposal 3 For the case when the semi-static HARQ-ACK codebook with HARQ-ACK multiplexing which includes HARQ-ACK corresponding to all the CBGs (including the non-scheduled CBG(s)) is used, NACK is reported for all the CBGs if TB CRC check is not passed while CB CRC check is passed for all the CBs NACK is mapped for the empty CBG index if the number of CBs for a TB is smaller than the configured maximum number of CBGs

Issue 4: DCI composition for CBGTI, CBGFI, NDI Currently, the main issue is: 1) whether to support joint coding of CBGTI and NDI, OR 2) whether to support reinterpretation between NDI and CBGFI Observation: It seems we need to discuss on the case considered as an error for each approach, possibly with on the following observations

Issue 4: DCI composition for CBGTI, CBGFI, NDI Alt 1: NDI  CBGFI (reinterpretation case) Initially, gNB schedules NDI “0” (TB1) with CBGTI “1111” UE transmits HARQ-ACK “AAAA” and the HARQ-ACK is correctly decoded in gNB Next, gNB schedules NDI “1” (TB2) with CBGTI “1111” Case 1: UE misses the DCI, but partial D-to-A error as “NNAA” happens in gNB gNB schedules TB2 with CBGTI “1100” by replacing NDI into CBGFI “1” BUT, UE may misunderstand the scheduled TB2’s CBG index 0/1 as TB1’s CBG index 0/1 This seems new error type which does not happen in LTE Question 1: what could be the UE behavior in terms of DCI treatment and/or HARQ-ACK feedback? Question 2: is this case need to be handled (differently from the case 2 below)? Case 2: UE misses the DCI, but full D-to-A error happens in gNB gNB schedules NDI “0” (TB3) with CBGTI “1111” BUT, UE may misunderstand the scheduled TB3 as TB1 This also happens in LTE and is not handled specially

Issue 4: DCI composition for CBGTI, CBGFI, NDI Alt 2: CBGTI  NDI (joint coding case) Initially, gNB schedules TB1 with CBGTI “1111” UE transmits HARQ-ACK “AAAA” and the HARQ-ACK is correctly decoded in gNB Next, gNB schedules TB2 with CBGTI “0000” Case 1: UE misses the DCI, but partial D-to-A error as “AANN” happens in gNB gNB schedules TB2 with CBGTI “1100” BUT, UE may misunderstand the scheduled TB2’s CBG index 2/3 as TB1’s CBG index 0/1 This seems new error type which does not happen in LTE Question 1: what could be the UE behavior in terms of DCI treatment and/or HARQ-ACK feedback? Question 2: is this case need to be handled (differently from the case 2 below)? Case 2: UE misses the DCI, but full D-to-A error happens in gNB gNB schedules TB3 with CBGTI “1111” BUT, UE may misunderstand the scheduled TB3 as TB1 This also happens in LTE and is not handled specially

Issue 5: Support of TB level HARQ-ACK feedback It seems most of companies consider the necessity of fallback operation to TB level HARQ-ACK feedback even in case when CBG based retransmission is configured However, the companies seem to have different view in terms of when and/or how to apply/support the TB level HARQ-ACK feedback Observation: It seems this issue also needs to be discussed further in terms of when and/or how to apply/support the TB level HARQ-ACK feedback, possibly with the following alternatives from the contributions

Issue 5: Support of TB level HARQ-ACK feedback When to apply the TB level HARQ-ACK feedback: Alt 1: For the case if all HARQ-ACKs corresponding to all CBGs are ACK or NACK Alt 2: For the case if PDSCH is scheduled by PDCCH via common search space or PDCCH by fallback DCI format Alt 3: For the case if TB level A/N feedback is explicitly indicated by gNB How to support the TB level HARQ-ACK feedback in terms of HARQ-ACK payload composition and PUCCH resource allocation: Alt 1: generate 1-bit bundled A/N per TB, then transmit PUCCH format supporting small UCI payload which can be different from the PUCCH format conveying multi-bit CBG- level A/N per TB Alt 2: generate bundled A/N per TB, then transmit using the same PUCCH format used for conveying multi-bit CBG-level A/N per TB