3GPP TSG RAN WG1 #103e-E R1-

200xxxx
e-Meeting, October 26th – November 13th, 2020

Source: Moderator (ZTE)

Title: Summary of AI 8.4.3 for HARQ for NTN
Agenda Item: 8.4.3
Document for: Discussion and Decision

1. Introduction
In RAN1#102e meeting, agreements w.r.t the extension of HARQ process number and enabling/disabling on HARQ
feedback for downlink transmission have been made. In this meeting, companies’ views to refine the details and on other
remaining issues are summarized with corresponding observations/proposals on following aspects with detailed proposals
from each company listed in appendix.
 Enhanced HARQ process ID indication

 HARQ codebook enhancements

 Restriction on HARQ feedback disabling

 Performance enhancements

 PDSCH/PUSCH scheduling restriction

2. Enhanced HARQ process ID indication

According to the agreement in last meeting, the maximal supported HARQ process number is extended to 32. Detailed
solutions are proposed in [Huawei, CAICT, Apple, vivo, CMCC, Intel, Xiaomi, CATT, Panasonic, Ericsson, QC, Sony,
Lenovo, Spreadtrum, LG, ZTE, OPPO] with following options:
 Option 1: Slot index as the MSB [QC,HW, Sony, Lenovo]
In this option, the slot index is interpreted as MSB for HARQ ID calculation along with the indicated HARQ ID in
existing DCI field.
 Option 1-a: Slot index as the LSB [CMCC, ZTE]
In this option, the slot index is interpreted as LSB for HARQ ID calculation along with the indicated HARQ ID in
existing DCI field.
 Option 2: Reusing one bit from other bit field [CATT, CMCC, Apple, VIVO, ZTE]
In this way, one bit from other bit field is interpreted for HARQ ID calculation along with the indicated HARQ ID
in existing DCI field.
 Option 3: Extending the HARQ process ID field up to 5 bits [Ericsson, Panasonic, CAICT]
In this option, the existing HARQ process ID field is extended to 5 directly.
 Option 4: CCE index associated [LG]
In this option, the determination of HARQ process ID will be coupled with the index of CCE, which carrying the
scheduling information for transmission.
 Option 5: Additional scrambling for scheduling grant [Spreadtrum]

1/22
 In this option, the determination of HARQ process ID will be up to additional scrambling on the scheduling grant.
 Option 6: DM-RS index associated [HW]
In this option, the determination of HARQ process ID will be coupled with the DM-RS index, which is associated
to the transmission.
Moreover, [Intel] is supportive to associate the HARQ ID determination with slot index, but without detailed proposals.
[OPPO, Xiaomi] highlights that the solution with lower DCI overhead, e.g., unchanged size is preferred. Meanwhile, as
mentioned in [CMCC], extension of HARQ process ID field up to 5 is only used for DCI 0-2/1-2.
According to the above summary, the following proposals are listed as majority views:
[Initial Proposal 1]: Enhanced HRAQ process ID indication is supported by at least one of options:
 Option 1: Slot index as the MSB

 Option 1-a: Slot index as the LSB

 Option 2: Reusing one bit from other bit field

 Option 3: Extending the HARQ process ID field up to 5 bits

Company Comments and Views

MediaTek Option 3

CATT Option 2 and option 3 are both ok for us.

Maybe we first decide whether it is based on explicit (option 3) or implicit

(other options) indication. Regarding implicit indication, we still think it is
LG
beneficial to consider CCE based indication which is already used in NR for
PUCCH resource allocation.

OPPO Option 1

We support option 3 considering only 1 bit needs to be added. The extension

of HARQ process ID field should be applied to DCI 0-1, 0-2 and 1-1, 1-2, i.e.
Panasonic
not to add DCI 0_0 and 1_0.
If adding even 1 bit is undesired, option 1 (or 1-a) would be also acceptable.

We support Option 3 for non-fallback DCI (0_1/1_1 and 0_2/1_2). For

fallback DCI (0_0/1_0) it is acceptable to limit the number of HARQ
processes to 16.

The design rationale of non-fallback DCI is to support adding new features

with configurable fields, so it is natural to add one bit to the HARQ process
Ericsson ID field in non-fallback DCI if 32 HARQ processes are configured.

The fundamental NR HARQ design is asynchronous and thus flexible. Slot

index-based method is not aligned with this principle and re-introduces
unnecessary scheduling restriction from LTE. This is against the agreement
that the solution should be “minimizing the impacts on specification and
scheduling”.

2/22
 In addition, w.r.t the supports for larger HARQ process number, [Samsung, CMCC, OPPO, Apple, MTK, Xiaomi, Asia
Pacific Telecom, IDC] prefer to define it as optional UE capability. And [Ericsson, ZTE] highlight that larger HARQ
process number is only enabled via the RRC configuration.
According to the above summary, the following proposals are listed as majority views:
[Initial Proposal 2] Support on the maximal HARQ process number is up to UE capability.

Company Comments and Views

MediaTek Agree

This proposal needs more clarification, no sure if it is only corresponding to

32 HARQ processes, or other number less than 32 is up to UE capability.

CATT In addition, if only single codeword is supported for NTN UE, no special UE
capability definition is needed. Since 16 HARQ processes with two
codewords have been supported in NR Rel-15, the new UE capability
definition seems not needed.

LG Agree

OPPO Agree

Up to 32 HARQ processes can be supported without too much complexity

Panasonic considering the number of MIMO layers and modulation order would be
restrictive in NTN. Our preference is mandatory feature for NTN UE.

Regardless of UE capability, as a general principle, a new feature should be

Ericsson accompanied with RRC parameter(s) for configurability. This should be
applied to the configuration of up to 32 HARQ processes as well.

3. HARQ codebook enhancements

In RAN1#102e, preliminary discussion on the potential enhancements for HARQ codebook are conducted. In this meeting,
views from companies are provided on this aspect. More specifically:
1. W.r.t the Type-1 Codebook (semi-static codebook):
The enhancement for Type-1 codebook is highlighted by [HW, VIVO, ZTE Samsung, Sony, Ericsson]. More
specifically, the codebook size will be reduced by skipping the HARA-ACK feedback for disabled HARQ process. For
example, the skipping can be conducted according to the indication (e.g., bitmap) from gNB [Samsung] or if all
transmissions within same slot [ZTE] or all slots [vivo] are scheduled with disabled HARQ feedback. Also,
improvement on the feedback overhead may also be achieved via different TDRA configuration as mentioned by
[Sony].
However, as highlighted in [OPPO, CATT, Apple], enhancements on Type-1 is unnecessary.
2. W.r.t the Type-2 Codebook (Dynamic codebook):
The enhancement for Type-2 codebook is highlighted by [CATT, Samsung, OPPO, Sony, Apple, Intel, Asia Pacific
Telecom, CAICT, QC]. More specifically, for example, the codebook size will be reduced by directly without counting
DAI for the scheduling via HARQ process with disabled feedback [Ericsson]. But, to ensure the error correction
capability [Asia Pacific Telecom, ZTE], one additional parameter (e.g., to count the number of scheduling with enabled
feedback) can be considered to construct the codebook [ZTE].

3/22
3. W.r.t the enhanced Type-2 (Enhanced Dynamic Type-2) and Type-3 Codebook (Oneshot-feedback):
For these two cases, enhancements are not preferred by [CATT, Samsung, Apple, Intel, ZTE, and CAICT] since such
functionalities are introduced only for unlicensed spectrum (i.e., shared spectrum) [Samsung, ZTE]. But, [Ericsson]
highlights that it is also beneficial to improve it.
According to the above summary, the following proposals are listed as majority views:
[Initial Proposal 3]: Enhancement on Type-1 and Type-2 HARQ codebook is supported.

Company Comments and Views

Type I codebook is semi-statically configured, so we don’t think it needs

CATT
special optimization to reduce codebook size.

Agree with FL’s proposal. Regarding Type-3 HARQ codebook, following

agreements were made during RAN1#103-e NR-U maintenance session.

Agreements:
 The FG10-15/16 are also applicable to licensed bands
 The FG10-20a is also applicable to licensed bands
 Note: this agreement should not cause any specification impact
Where
10- One- 1. Support feedback of type 3 HARQ-ACK
LG 16 shot codebook, triggered by a DCI 1_1 scheduling a
HARQ PDSCH
ACK 2. Support feedback of type 3 HARQ-ACK
feedbac codebook , triggered by a DCI 1_1 without
k scheduling a PDSCH using a reserved FDRA
value

According to above agreement, Type-3 codebook can be applicable to L-bands.

Thus, we think it is worthwhile to consider Type-3 codebook for NTN as well.

For the ‘enhancement’ of type 1 codebook, some companies proposed to replace

HARQ-ACK information with NACK for disabled HARQ, some other
companies proposed to reduce the type 1 codebook size. Which direction are we
referring with ‘enhancement’?

OPPO From our point of view, if the number of HARQ-ACK bit is not reduced, it does
not make sense to force UE reporting NACK for disabled HARQ. If we are
heading towards type 1 CB size reduction, we need to first discuss different
enhancement alternatives and the respective spec impact, before making firm
decision on supporting type-1 codebook enhancement. We fear that the spec
effort may be unaffordable.

HARQ codebook is beneficial for TDD and/or CA especially large number of

Panasonic CCs, which would not be main focus in NTN. Therefore, optimization would
not be needed.

Ericsson We support this proposal. For Type-3, they can be FFS.

4/22
4. Restriction on HARQ feedback disabling
In addition to the agreement that disabling of HARQ feedback is done per UE per HARQ process via RRC, for ensuring the
efficiency and reliability of transmission carrying the signalling, e.g., RRC configuration/MAC CE command, as
highlighted in [CATT, Sony, MTK, ZTE, Ericsson], at least one HARQ process with feedback should be kept. Meanwhile,
w.r.t the SPS release, the corresponding feedback should also be kept [Sony]. W.r.t the corresponding specification impact,
down selection between following two options are proposed in [Ericsson]:
 Option 1: UE expects that at least one HARQ process is configured with UL HARQ feedback;

 Option 2: UE does not expect a MAC CE activation/deactivation command, which would become effective 3 msec
after the UE would transmit the corresponding HARQ-ACK, to be scheduled on a downlink HARQ process with
disabled feedback.
Meanwhile, LS with RAN1’s recommendation to inform RAN2 is proposed by [ZTE].
According to the above summary, the following proposals are listed as majority views:
[Initial Proposal 4]: UE expects that at least one HARQ process is configured with HARQ feedback.

Company Comments and Views

MediaTek Agree

CATT Agree

We would like to understand what is the motivation of this proposal? If at

least one HARQ process is configured with HARQ feedback, how does the
OPPO UE expect the gNB to use this HARQ process? If it is completely up to gNB
implementation, we don’t see the necessity to have this constraint, as the
configuration should naturally be up to gNB implementation as well.

The basic assumption of above two options might be that MAC CE is always
transmitted with HARQ enabled process. Before discussing the two options,
we think it should be determined first whether to mandate MAC CE
transmission with HARQ enabled process or to leave it up to network
Panasonic
implementation. Our position is up to network implementation, but this
should be determined in RAN2. Handling of MAC CE transmitted in DL and
UL can be different as what information is to be sent in DL is usually up to
network operation but UL may be specified.

Ericsson We support this proposal.

5. Performance enhancements
For enhancing the performance of transmission, in last meeting, different solutions including potential parameters
configurations are proposed by companies. In this meeting, following aspects are categorized into following aspects
according to the views from each company:
1. Enhancements on aggregated transmission (including repetition)
For this aspect, view from 12 companies are elaborated with corresponding enhancements mainly includes:
 Value of aggregation factor:

5/22
 As highlighted by [vivo, CATT, CMCC, MTK, ETRI, Ericsson, ZTE, Spreadtrum, Lenovo], supports of the
larger aggregation factor is beneficial for NTN.
 Indication of aggregation factor:
[CMCC, Lenovo] prefer to introduce different configurations for the transmission via HARQ process with
enabled or disabled feedback. But, the unified parameters configuration is preferred by [CATT].
Meanwhile, DCI based indication for the repetition/aggregation related information is mentioned by [HW,
Samsung]. More specifically, enhancement under the Rel-16 framework (e.g., numberOfRepetitions-r16
included in TDRA configuration)) is preferred by [Samsung].
 Transmission scheme:
In case of supports on larger aggregation factor, the time-interleaved transmission is mentioned in [CATT,
CMCC, vivo]. Moreover, as results shown in [ZTE], performance gain can be achieved for the transmission
with reduced DM-RS density. [Panasonic] proposes to introduce the scaling factor for TBS determination.
2. Enhancements on MCS (including CQI report)
For this aspect, view from 8 companies are elaborated with corresponding enhancements mainly includes:
 Different MCS table configuration:
[vivo, Ericsson] prefer to introduce different configurations of MCS table in TBS determination for
transmission via HARQ process with enabled or disabled feedback. But, the unified parameters configuration
is preferred by [CATT, Lenovo, ZTE].
 CQI report:
A new CQI table with larger BLER e.g., 1% [IDC] is proposed by [Thales, IDC, Qualcomm]. But this part is
not preferred by [ZTE] since similar performance can be achieved by implementation of scheduling.
3. Blind retransmission
As highlighted by [Nomor Research GmbH, Thales, IDC, Spreadtrum, Apple,], supports on blind PDSCH
(re)transmission of the same packet by MAC scheduling without waiting for the transmission of the HARQ feedback
can be considered. But as highlighted by [CATT], the gain for blind retransmission is not clear and also from [ZTE]
perspective, this solution can be conducted by implementation once the time domain scheduling restriction for
PDSCH with same HARQ process is updated.
4. UCI
As highlighted in [Xiaomi, Qualcomm, ETRI, LG], in case of scheduling with disabled HARQ feedback, additional
new UCI feedback, e.g., to report the decoding statistic or reporting DL transmission disruption and/or requesting DL
scheduling changes, can be considered to improve the scheduling configuration from gNB side.
5. UE assistance information
As mentioned in [Samsung, Huawei], report for the assist information from UE side, e.g., the buffer situation in the
DL HARQ procedure [Samsung] via reserved resource [Huawei], is beneficial for scheduling the decision for HARQ
scheduling with enabled/disabled feedback.
In addition, other solutions, e.g., long CSI periodicity [Thales, Nomor Research GmbH], RV limitation for scheduling [QC]
is proposed.
Based on the above analysis, following proposal is provided according to majority view:
[Initial Proposal 5]: Study on following enhancements is prioritized:
 Enhancements on aggregated transmission (including repetition)

6/22
 Enhancements on MCS (including CQI report)

Company Comments and Views

Per https://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_103-e/Docs/R1-
2008802.zip we have demonstrated significant performance gains arising
from adaptive blind repetitions (ABR) based on CQI feedback, specifically in
Ligado NTN where channel blockage is a larger concern than multipath fading.
Ligado commends this analysis to companies. The assertion [CATT] that the
gain for blind repetition is not clear does not consider the adaptive aspect.
ABR should at least be considered for further study.

MediaTek Agree

Aggregation transmission can be enhanced due to lower SINR scenario in

NTN.

For MCS enhancement, we need to consider it on top of URLLC feature with

BLER 10^-1 and BLER^-5, two MCS tables. In addition, in most of cases,
CATT NTN channel is similar to AWGN channel due to strong LOS presence. So
small fluctuation of SINR will have significantly impact to CQI estimation,
but larger feedback delay in NTN scenario will eat the gain of finer CQI
reporting since it is impossible to get very accurate CQI. Hence, we think the
MCS/CQI enhancement is not motivated.

Agree for first sub bullet.

LG
Regarding MCS enhancement, we share view with CATT.

We agree to discuss the aggregated transmission. However, as blind

retransmission is proposed by many companies too, it would be also
OPPO
meaningful to have some places for discussing blind retransmission. At least
to us, it is very clear why the blind retransmission is ruled out.

We support proposal 5.
Enhancement on aggregated transmission (including repetition) can be
beneficial for throughput improvement with a limited number of HARQ
processes as well as reliability improvement. As the enhancement, we
propose to introduce TB scaling factor with repetition (aggregated
transmission) in order to use the repetition to improve the user throughput.
User throughput for 32 HARQ processes is still restrictive especially for Ka-
band (i.e. larger SCS) because the number of slots that can be scheduled
Panasonic within RTT is too low (e.g. 32 out of 335 slots in case of SCS 120kHz). By
using scaling factor (> 1) for transport block size determination to gather with
repetition, user throughput can be improved. For example, 4 times larger TB
size is used for 4 times repetitions. In this way, the number of slots used for
the transmission and amount of data within RTT can be increased by 4 times,
thus throughput is improved with a limited number of HARQ processes like
32.
Note that because scaling factor for transport block size determination (≤1) is
already used for PDSCH scheduled by RA-RNTI and P-RNTI, additional
complexity would be trivial.
7/22
 Prioritization of which enhancements to study can be left to each contributing
company. The necessity of proposed enhancements should be justified with at
least simulation results. Then companies could check the results and discuss
whether a specific enhancement is needed.
Ericsson
Note that we do not propose larger aggregation factor but configuration of
different aggregation factors for enabled/disabled HARQ processes. So we
would appreciate if FL could move our company name from the first sub-
bullet in (1) to the second sub-bullet in (1).

6. PDSCH/PUSCH scheduling restriction

In existing specification following restrictions are considered for the PUSCH and PDSCH scheduling with same HARQ
process ID, respectively:

To
PUSCH
The UE is not expected to be scheduled to transmit another PUSCH by DCI format 0_0, 0_1 or 0_2 scrambled by
C-RNTI or MCS-C-RNTI for a given HARQ process until after the end of the expected transmission of the last
PUSCH for that HARQ process.
PDSCH
The UE is not expected to receive another PDSCH for a given HARQ process until after the end of the expected
transmission of HARQ-ACK for that HARQ process...
enable the scheduling flexibility via the HARQ with disabled feedback, views on the PDSCH/PUSCH scheduling are
elaborated below:
1. PDSCH:
[Ericsson] propose to update the restriction as: For a DL HARQ process with disabled HARQ feedback, the UE is not
expected to receive another PDSCH for the given HARQ process until after the end of the expected reception of the
last PDSCH for that HARQ process.
[OPPO] propose to update the restriction with consideration a new scheduling constraint to ensure enough PDSCH
processing time between two PDSCH receptions with same HARQ ID.
2. PUSCH:
[Qualcomm, OPPO] propose to define a minimum gap between two PUSCHs of a HARQ process, for example, T_pro
is defined in [OPPO]. However, as proposed by [Ericsson], the existing scheduling rule should be kept for PUSCH.
Based on the above analysis, following proposal is provided according to majority view:
[Initial Proposal 6]: Following principle is supported for the PDSCH scheduling via same HARQ process with disabled
feedback:
 For a DL HARQ process with disabled HARQ feedback, the UE is not expected to receive another PDSCH for the given
HARQ process until after the end of the expected reception of the last PDSCH for that HARQ process.

Company Comments and Views

MediaTek Agree

CATT Agree

LG Agree
8/22
 We don’t agree with this proposal as is.

First of all, the proposal is not very clear to us. Is the ‘another PDSCH’ is a new
transmission of a given HARQ or a retransmission? Note that PDSCH repetition is
also another PDSCH.

Secondly, we think we should first discuss the issues on both PDSCH and PUSCH
scheduling restriction. Then based on the discussion outcome to make possible
agreement.

For PDSCH repetition, the network does not know if the UE needs to decode all
the PDSCH repetitions to get an ACK or part of them. Thus, the network should
give enough PDSCH processing time.

For PUSCH, we have a comment on Ericsson’s proposal for the case illustrated
their Tdoc and copied below

OPPO

In this case, we have strong concern that if there is no preparation time between
PUSCH1 and PUSCH2, the UE cannot prepare the PUSCH2 in the buffer that was
used for preparing PUSCH1 previously.

In summary, it would be good to have some discussions among companies to have

a clear understanding on the concerns before scrambling to have some quick
agreements.

Panasonic We support proposal 6.

Ericsson We support the proposal.

7. Conclusion
In this summary, following proposals are made according to the contribution submitted in AI 8.4.3:

9/22
Appendix
Contribution
Observation/Proposals
R1-2007571 Huawei
Observation 1: HARQ ID can be implicitly indicated via slot index at the cost of scheduling flexibility.
Observation 2: HARQ ID can be implicitly indicated via DMRS at the cost of false alarm ratio loss.
Proposal 1: The following mechanisms for implicit indication of HARQ process ID can be considered.
 Option 1: Associate HARQ process ID with slot index;

 Option 2: Associate HARQ process ID with DMRS sequence;

Proposal 2: The Type-1 HARQ-ACK codebook size can be reduced by skipping the HARQ-ACK feedback for disabled
HARQ processes.
Proposal 3: Transmission parameters shall be configurable and indicated via DCI.
Proposal 4: Reinterpreting idle bits in DCI for indicating transmission parameters shall be considered.
Proposal 5: UE assistance information reporting in reserved resource can be considered for NTN.
R1-2007662
vivo
Observation 1: Considering different target BLER MCS tables for different use cases is benefit to NTN.

Observation 2: Consider time interleaved slot aggregation for NTN.

- the slot interval depends on the traffic packet size and transmission scheme.

Observation 3: Considering different MCS tables and different aggregation factors for different NTN scenarios is benefit to
NTN.

Proposal 1: Support re-interpreting existing DCI field to indicate the extension of HARQ process number for NTN.

Proposal 2: Support different MCS tables and different aggregation factors for different NTN use cases and scenarios.

Proposal 3: At least one enabled HARQ process should be configured for NTN.

M A, c
Proposal 4: Support to report HARQ-ACK for disabled DL HARQ processes if enabled HARQ process(es) is within the
occasions for type-1 HARQ-ACK codebook.

R1-2007856
CATT
Proposal 1: At most 32 HARQ processes can be supported without UE capability report if only single layer transmission is
assumed in NTN.

Proposal 2: Specify supported HARQ process number for fallback case.

Proposal 3: Re-interprete DCI field to indicate 32 HARQ indexes.

Proposal 4: Keep at least one HARQ process with feedback if UE specific disabling is configured.
Proposal 5: A unified solution of configuration parameter is preferred for with and without HARQ .
Proposal 6: Support more than 8 repetitions in slot-aggreation transmission.

10/22
Proposal 7: No optimization is needed for type 1 HARQ-ACK codebook and no touch on type 3 HARQ-ACK codebook.
Proposal 8: Type 2 HARQ-ACK codebook can be optimized for NTN from saving overhead perspective.
Proposal 9: Blind retransmission is not supported in NTN case.
Proposal 10: Slot aggregation factor can be extended to 16 for very low SINR case.
Proposal 11: Support time interleaved slot aggregation to improve transmission reliability.

Proposal 12: No need to define a minimum time gap for without HARQ-ACK feedback case if blind retransmission is not
supported.

Observation 1: Blind retransmission doesn’t show clear benefits over slot aggregation but with redundant DCI indication.
Observation 2: Define a minimum time gap between two PDSCHs of a HARQ process without HARQ-ACK
feedbacks，which is necessary only for the blind retransmission.

Observation 3: There is no need for the enhancement on HARQ feedback.

R1-2008012
CMCC
Proposal 1: Support DCI format 0_2 and 1_2 with up to 5 bit HARQ process number field as configured by higher layer
parameter.
Proposal 2: The following solutions for up to 32 HARQ process ID indication can be further studied
- Re-interpretation of existing DCI field
- Slot/SFN-based solution with LSB value for HARQ ID determined by time information.
Proposal 3: Support different configuration on aggregation factor for HARQ process with/without feedback.
Proposal 4: Support larger aggregation factor in NTN.
Proposal 5: Support on the maximal HARQ process number is up to UE capability.
R1-2008166
Samsung
Proposal 1: Enhanced Type-2 and Type-3 HARQ-ACK codebooks are not supported for NTN.

Proposal 2: Enable a gNB to avoid HARQ-ACK information in a Type-1 HARQ-ACK codebook for HARQ processes with
disabled HARQ-ACK information by configuring a bitmap that indicates slots where the UE should generate
HARQ-ACK information.

Proposal 3: When HARQ-ACK information for a HARQ process with disabled HARQ-ACK information is included in a
HARQ-ACK codebook, the UE reports

 A predetermined HARQ-ACK information value, such as a NACK, for the HARQ process with disabled HARQ-
ACK information when the UCI payload size is no more than 11 bits.
 HARQ-ACK information based on a reception outcome of a corresponding TB for the HARQ process with disabled
HARQ-ACK information when the UCI payload size is more than 11 bits.
Proposal 4: A Type-2 HARQ-ACK codebook only includes HARQ-ACK information for HARQ processes with enabled
HARQ-ACK information report.

 DAI values change only when a TB in a corresponding PDSCH is associated with HARQ process with enabled
HARQ-ACK information report.
Proposal 5: Support a larger number of repetitions for NTN

11/22
  The number of repetitions is indicated by the DCI format as in Rel-16.
 Extend the “Time domain resource assignment” field to indicate the number of repetitions.
Proposal 6: For the maximum number of HARQ processes, consider the following options.

 Option 1. gNB broadcasts the maximum TBS to be configured for the cell and UE reports its capability for a number
of HARQ processes.
 Option 2. UE reports its capability for a number of pairs of {maximum number of HARQ processes, maximum TBS
constraint}.
Proposal 7: UE assistance information for HARQ should be studied for NTN.
R1-2008255
OPPO
Proposal 1: The enabling/disabling of HARQ processes for both DL and UL scheduling via RRC or DCI should be supported.
Proposal 2: HARQ-ACK information for disabled DL HARQ processes should be reported at least in Type-1 HARQ-ACK
codebook and FFS in Type-2 HARQ-ACK codebook.
Proposal 3: Support on the maximal HARQ process number is up to UE capability.
Proposal 4: Low DCI overhead methods should be considered if the number of HARQ processes is 32.
Proposal 5: Enhancements to PDSCH/PUSCH with disabled HARQ process to achieve a higher reliability should be
considered.
Proposal 6: PUSCH processing time should be updated in NTN.
Proposal 7: PDSCH reception constraint for a given enabled DL HARQ process should be enhanced in NTN.
Proposal 8: PDSCH reception constraint for a given disabled DL HARQ process should be considered in NTN.
Proposal 9: PUSCH transmission constraint for a given enabled UL HARQ process should be enhanced in NTN.
Proposal 10: PUSCH transmission constraint for a given disabled UL HARQ process should be considered in NTN.
R1-2008361
Sony
Observation 1: The beam switching is a time-sensitive behavior due to the movement of satellite. Waiting for the HARQ
feedback for PDSCH carrying MAC CE for beam switching may miss the favorable time.
Observation 2: The redundant feedback of Type-1 / semi-static HARQ codebook would be large based on current HARQ
codebook design.
Proposal 1: Support slot-based HARQ process ID indication when maximal supported HARQ process number is extended to
32.
Proposal 2: Support at least one HARQ process with HARQ feedback enabled.
Proposal 3: When the MAC CE for beam switching is carried by PDSCH without HARQ feedback. UE applies the
corresponding action with the reference to slots of the end of PDSCH transmission.
Proposal 4: At least adjustment for HARQ codebook Type-1 and Type-2 should be considered.
 Enhancement on Type-1/ Semi-static HARQ codebook to reduce the redundant feedback should be studied.
Following method can be considered:
 Separate TDRA table configuration for HARQ process with HARQ-ACK disabling and HARQ-ACK enabling.
 DAI is not incremented for a PDCCH which is scheduling a HARQ process with HARQ-ACK disabling.
Proposal 5: When the HARQ process of SPS PDSCH is HARQ feedback disabled, UE reports HARQ feedback information

12/22
for the SPS PDSCH activation.

R1-2008412
LG
Proposal 1: The maximum number of HARQ process is up to UE capability.

Proposal 2: Consider CCE index based HARQ process id identification for NTN.

Proposal 3: FFS on the use case and clear benefit of dynamic HARQ enabling/disabling.

Proposal 4. Consider recommended repetition factor, PDSCH decoding results or probability as new CSI contents.

Proposal 5: Consider HARQ-ACK codebook enhancement when HARQ feedback is disabled.

R1-2008467 Apple
Proposal 1: Supporting the maximal HARQ process number of 32 is up to UE capability.

Proposal 2: Consider always applying LBRM for UE operating with 32 HARQ processes.

Proposal 3: The HARQ process number field in DCI is remained to be 4 bits, and DCI fields are re-interpreted to indicate up
to 32 HARQ process numbers.

Proposal 4: Support to have different configurations for HARQ processes with or without HARQ feedback.

Proposal 5: Support blind PDSCH and PUSCH retransmissions for NTN.

Proposal 6: In type-1 HARQ-ACK codebook construction, UE does not reduce the HARQ-ACK codebook size for HARQ
processes with disabled HARQ feedback.

Proposal 7: In type-2 HARQ-ACK codebook construction, UE does not expect to receive increased counter DAI for HARQ
processes with disabled HARQ feedback.

R1-2008810
MTK
Proposal 1: Support of 32 HARQ processes in the device is a UE capability in NR NTN.
Observation 1: To improve reliability in case UL HARQ feedback is disabled via configuration, faster ARQ re-transmissions
over the RLC layer could be configured – e.g. every 5 ms, 10 ms, 15 ms, 20 ms, ...
Observation 2: Reliability of Message 3 in RACH procedure cannot be achieved via RLC ARQ as RLC AM is not possible
before contention resolution has completed.
Proposal 2: UL HARQ retransmissions is not disabled for Message 3 transmission in RACH procedure.
Proposal 3: Whether UE should expect that at least one HARQ process is configured with UL HARQ feedback for MAC CE
activation / de-activation is specified or up to network configuration.
Proposal 4: The HARQ parameters for HARQ processes with enabling/disabling on HARQ feedback for downlink
transmission can be configured differently to ensure adequate reliability – i.e. Block error rate target, MCS table, aggregation
factor, Time Domain and Frequency Domain resource allocation, PRB bundling, etc.
Proposal 5: The network can configure one HARQ process pool with UL HARQ feedback enabled and one HARQ process
pool with UL HARQ feedback disabled.
Proposal 6: Whether HARQ process IDs with UL HARQ feedback disabled via RRC can do HARQ soft combining is a UE
capability.
Observation 3: In NR specifications, the MCS selection, time domain allocation, and frequency resource allocation type 0 and

13/22
type 1 can be done first as in the specifications. Then, repetitions with values 2, 4, or 8 to increase the reliability of each
transmissions as in URLLC can be done based on pdsch-AggregationFactor for DL or repK for UL based on RRC
configuration.
Observation 4: An SNR gain in the order of 1 dB is required to achieve a BLER target of e-3 compare to BLER target of e-1 in
TDL-D channel profile in NR NTN. This represents less than a CQI step for the gNB scheduler.
Proposal 7: Higher level of slot aggregation / repetitions than 8 is FFS
R1-2008852
ZTE
Proposal 1: Re-interpretation of bits in DCI should be considered as the baseline to support the HARQ process indication
with extended maximum HARQ process number.

Proposal 2: LS to RAN2 is recommend to capture the identified impacts (along with RAN1’s suggestions) on scheduling due to
disabled HARQ feedback.

Proposal 3: Enhancement on the Type-1/2 codebook can be considered.

Proposal 4: Enlarged aggregation factor and reduced DM-RS density should be supported to improve the performance for
NTN.

Proposal 5: Following enhancements are not needed to be supported.

 Blind transmission:
 CQI with new BLER target
 UCI including DL decoding Infor/MCS request
 Different parameters configuration
(a) MCS table
(b) Time domain resource allocation table
(c) Frequency resource allocation type 0 and type 1
(d) Block error rate target
(e) Physical resource block (PRB) bundling configuration
(f) PDSCH mapping type A and type B
R1-2008881 Nomor Research GmbH, Thales
Observation 1: Considering 15UEs per cell, the DL UE throughput is similar for 16 and 32 HARQ processes if a
restriction to schedule less than 4UEs per TTI is applied.

Observation 2: Considering 15UEs per cell with a restriction to schedule up to 4UEs per TTI, the 50%-tile DL UE
throughput is 7% higher, if up to 32 instead of 16 HARQ processes can be configured per UE.

Observation 3: Increasing the number of UEs per cell from 15 to 20, the difference of the DL UE throughput
between systems where up to 16 or 32 HARQ processes per UE can be configured disappears.

Observation 4: Considering 15UEs per cell with a restriction to schedule up to 3UEs per TTI, the 50%-tile UL UE
throughput is 11% higher, if up to 32 instead of 16 HARQ processes per UE are used.

Observation 5: Considering 20UEs per cell with a restriction to schedule up to 3UEs per TTI, the 50%-tile UL UE
throughput is 9% higher, if up to 32 instead of 16 HARQ processes can be configured per UE.

Observation 6: Considering 30UEs per cell the with a restriction to schedule up to 3UEs per TTI, the CDF of the
UL UE throughput is similar if up to 32 or 16 HARQ processes can be configured per UE.

Observation 7: If the propagation delay decreases, e.g. for a system using a lower orbit, the round trip time
decreases and 16 HARQ processes per UE will be sufficient.
14/22
Observation 8: The main purpose of NTN is to provide coverage everywhere and to support high mobility. In real
NTN scenarios, there is no need to schedule a UE in each TTI.

Observation 9: Considering a GEO Ka-Band scenario with FR3 and 10 LOS UEs per cell, the TP per UE is on
average 30% lower (8.8Mbit/s vs. 12.6Mbit/s) if link adaptation is performed based on the
instantaneous channel state.

Observation 10: Considering a GEO Ka-Band scenario with FR3 and 10 LOS UEs per cell, the probability of an
RLC error rate per UE larger than 3% is 4% if link adaptation is performed based on the
instantaneous channel state and BLER offset, while it is 0.6% if link adaptation is performed based
on initial channel state measurement and BLER offset.

Observation 11: Considering a GEO Ka-Band scenario with FR3 and 10 LOS UEs per cell, it is useful to do an
averaging in terms of BLER rather than taking into account the instantaneous channel state due to
the expiration of the channel state information upon receiving the CQI at the gNB because of the
large transmission delay.

Observation 12: Applying a CQI feedback with 1% PHY BLER target performs better in terms of TP than applying
a CQI feedback with 10% PHY BLER target and an additional offset.

Observation 13: The probability of an RLC error rate per UE larger than 2% is 0.8% if a PHY BLER target of 1% is
applied and 0.5% if an averaged SINR in dB and an offset of -4.5dB is used for link adaptation. In
the other considered cases of averaged SINR the RLC error rate is significantly larger.

Observation 14: Considering a GEO Ka-Band scenario with FR3 and 10 LOS UEs per cell, the mean TP per UE
increases from 13.2Mbit/s to 14.0Mbit/s if a PHY BLER target of 2% instead of 1% is applied.

Observation 15: Considering a GEO Ka-Band scenario with FR3 and 10 LOS UEs per cell, the 5%-tile of the TP per
UE increases from 8.4Mbit/s to 9.2Mbit/s if a PHY BLER target of 2% instead of 1% is applied.

Observation 16: Considering a GEO Ka-Band scenario with FR3 and 10 LOS UEs per cell, the mean RLC error rate
per UE increases from 1.1% to 2.2% if a PHY BLER target of 2% instead of 1% is applied.

Observation 17: Considering a GEO Ka-Band scenario with FR3 and 10 LOS UEs per cell, the 5%-tile of the RLC
error rate per UE increases from 0.8% to 1.8% if a PHY BLER target of 2% instead of 1% is
applied.

Observation 18: The specified 5QI match either packet error rate or delay of a GEO scenario but not both.

Proposal 1: The support of 32 HARQ processes is up to UE capability.

Proposal 2: Allow to send blind PDSCH (re)transmission of the same packet by MAC scheduling without
waiting for the transmission of the HARQ feedback.

Proposal 3: Introduce larger CSI-Report periodicity values in TS 38.331 to avoid unnecessary overhead in
scenarios with large transmission delay.

Proposal 4: Introduce a target BLER for CQI-Reporting to support NTN scenarios with HARQ disabled.

Proposal 5: RAN1 to discuss reasonable assumptions for operator defined 5QI requirements to support GEO
satellite communication in NR.

R1-2008924,
Lenovo, Motorola Mobility

15/22
Proposal 1: The HARQ process number is tied to SFN/slot index of PDCCH/PUSCH/PDSCH.

Proposal 2: Different numbers of HARQ processes is configured based on UE capability.

Proposal 3: UE assumes the HARQ feedback disabling where HARQ ID belongs to the RRC configured HARQ process
disabling subset.

Proposal 4: The multiple transmissions of same TBs in consecutive or interlaced slots can be considered when HARQ is
disabled

Proposal 5: Repetition transmission number and interlace transmission interval can be indicated in corresponding DCI when
HARQ process disabling.

Proposal 6: A unified configuration should be considered for each HARQ process with/without feedback except aggregation
factor if benefit identified.

R1-2008991 Intel

Proposal 1:

 Support Rel. 15 Type I HARQ codebook for the case where HARQ feedback is disabled for a subset of HARQ
processes

 For Type II HARQ codebook, PDSCH with disabled HARQ feedback is not counted for DAI and the corresponding
ACK/NACK is not transmitted by the UE

Proposal 2:

 If 32 parallel HARQ processes are supported for NTN,

o HARQ process ID is determined based on DCI indication and slot index of the corresponding transmission

 4 bits are used for HARQ process ID indication in DCI

R1-2009017
ETRI
Observation 1 : The worst scenarios for transmission correspond to the cases having both GEO and handheld.

 For SC5, the DL geometry SINR range might be from 1.5 dB (5%) to 5 dB (95%).

 For other cases (SC4,19,20), the DL geometry SINR range might be from -6 dB (5%) to 1 dB (95%).

Observation 2 : Under the worst NTN scenario, S(I)NR might be narrower and lower than TN.

 For all cases(SC4,5,19,20), 90 % (between 5% and 95%) of the links are concentrated within 4 dB

 For SC5, 95 % of the links are below 5 dB.

 For other cases (SC4,19,20), 95 % of the links are below 1 dB.

Observation 3 : Within low S(I)NR region, the slot aggregation could enhance BLER and SE simultaneously.

Observation 4 : The slot aggregation might have shorter latency than HARQ retransmission.

Observation 5 : The slot aggregation has no specification impact.

16/22
Observation 6 : If aggregation factor is determined properly, the optimal channel adaptation between BLER and SE might be
possible.

 The transmission parameter should be determined properly.

 Too reliable parameter : throughput loss

 Proper parameter : optimal adaptation

 Too un-reliable parameter : reliability/latency loss (might be unable to communicate)

Observation 7 : The appropriate aggregation factor value might be varying depending on the channel condition and the target
performance

Observation 8 : In NR, if the slot aggregation is used, gNB cannot distinguish between just proper parameter and too reliable
parameter.

 0 CRC OK in a bundle (too un-reliable parameter) : NACK

 only 1 CRC OK in a bundle (proper parameter) : ACK

 multiple(>1) CRC OK in a bundle (too reliable parameter) : ACK

Observation 9 : In NR, If the slot aggregation is used, gNB cannot optimally react to some cases.

 toward better reliability : possible (reaction for receiving NACK quite consistently)

 maintain : possible (reaction for receiving ACKs quite consistently)

 toward better throughput : (seems to be )impossible

Observation 10 : In NR, there is no feedback mechanism to guide AF into lower value for better throughput

 Once the AF value gets larger, it may be impossible to be reduced again

Observation 11 : If all the HARQ feedback are disabled, gNB might have no HARQ feedback.

Observation 12 : If all the HARQ feedback are disabled, gNB cannot optimally react to all cases

 toward better reliability : (seems to be )impossible

 maintain : (seems to be )impossible

 toward better throughput : (seems to be )impossible

Observation 13 : UL feedback via MAC-CE/RRC might be preferred rather than UL feedback via UCI.

 specification impact would be minimized

 soft combinable retransmission mechanism on PUSCH might be beneficial for compensating in low S(I)NR under
NTN

Observation 14 : Each parameter (especially IMCS) has its own optimal aggregation factor value.

Observation 15 : For optimal adaptation, different aggregation factor should be applied depending on the parameter (especially
IMCS)

Observation 16 : The optimal aggregation factor might be different, depending on the target performance.

17/22
Observation 17 : For optimal adaptation, different aggregation factor should be applied depending on the target performance.

Observation 18 : In NR, various kinds of transport channels are multiplexed into PDSCH/PUSCH.

 Each transport port channel might have its own transmission purpose (target performance).

 Transport channel might be distinguishable by checking the RNTI type of PDSCH/PUSCH

 PDSCH related RNTI : {P,SI,RA,MSGB,TC,C,MCS-C,CS}-RNTI

 PUSCH related RNTI : {TC,C,MCS-C,CS}-RNTI

Observation 19 : In NTN, different target performance might be defined by the HARQ feedback availability.

Proposal 1 : Consider the slot aggregation (“larger aggregation factor”) as the solution for “#Issue 4: Enhancement on the
transmission” in Error: Reference source not found.

Proposal 2 : Consider the UCI for scheduling change request as the solution for both “6.4 #Issue 4: Enhancement on the
transmission” in Error: Reference source not found and the adaptation feasibility issue described in this paper.

 UCI can include information such as

 request for increasing/decreasing pdsch-AggregationFactor

 request for increasing/decreasing MCS

 DL decoding statistics

 combinations of the above

 MAC-CE/RRC might be also acceptable, instead of UCI.

 for minimizing specification impact.

 for compensating low S(I)NR in NTN by using soft combinable retransmissions on PUSCH

Proposal 3 : Consider “Introducing the separate aggregation factors depending on followings” as the solution for “6.2 #Issue 2:
Mechanism for disabling/enabling HARQ feedback” in Error: Reference source not found.

 (a group of) MCS index

 (a group of) RNTI type (or search space)

 PDSCH related RNTI : {P,SI,RA,MSGB,TC,C,MCS-C,CS}-RNTI

 PUSCH related RNTI : {TC,C,MCS-C,CS}-RNTI

 HARQ feedback availability (enabled/disabled)

 (a group of) HARQ process number

 combinations of the above

 subsets of the above

R1-2009034
Xiaomi
Proposal 1: The number of supported HARQ processes is subject to the UE’s capability.

18/22
Proposal 2: The length of the HARQ process indicator bit-field in the scheduling grant should be kept unchanged.

Proposal 3: Dynamic HARQ enabling/disabling is not supported.

Proposal 4: Enhancement on the UCI reporting such as the data decoding statistics should be introduced.

R1-2009050
Panasonic
Proposal 1: The maximum number of HARQ processes for NTN is 32.
Proposal 2: 1 bit is added for HARQ process ID indication in DCI format 0_1, 1_1 and 0_2, 1_2.
Proposal 3: Enhancement of PDSCH/PUSCH transmission to improve user throughput without further increasing the number
of HARQ processes should be discussed.
Proposal 4: Transport block size scaling in case of repetition should be supported to improve user throughput with a limited
number of HARQ processes.
R1-2009059
Asia Pacific Telecom
Proposal 1Support on the maximal HARQ process number is up to UE capability.
Proposal 2More than 16 HARQ shall only be supported by VAST and mounted devices.
Proposal 3RAN1 impact on HARQ UL retransmission enabling/disabling shall be discussed.
Proposal 4Timing enhancement on the Type-1 HARQ-ACK codebook shall be needed.
Proposal 5HARQ-ACK disabling shall not change the Type-1 HARQ-ACK codebook size.
Proposal 6Timing enhancement on the Type-2 HARQ-ACK codebook shall be needed.
Proposal 7DAI enhancement on the Type-2 HARQ-ACK codebook shall ensure the error correction capability.
R1-2009078
CAICT
Proposal 1: Support up to 32 HARQ processes indication with one additional bit field in the DCI.
Proposal 2: Configure two subsets of HARQ processes for enabled HARQ processes and disabled HARQ processes
respectively via RRC signaling. To decide the HARQ disable/enable state with HARQ process ID indication in the scheduling
DCI.
Proposal 3: HARQ-ACK for disabled HARQ is not included in the dynamic HARQ-ACK codebook.
Proposal 4: Consider enhancements on DCI formats and corresponding PDCCH detection when DL HARQ process with
feedback disabled and enabled are simultaneously supported for one UE.
Proposal 5: Enabling/disabling of HARQ feedback for DL SPS/UL CG is configured per configuration.
Proposal 6: Provide higher priority order for the HARQ disabled transmission than the priority order for HARQ enabled
transmission.
R1-2009093
Ericsson
Observation 1 It is not necessary to schedule 32 HARQ processes using fallback DCI 0_0/1_0.
Observation 2 Adding an additional configurable bit in DCI 0_1/1_1 or 0_2/2_2 to support 32 HARQ processes minimizes the
impacts on specification and scheduling.

19/22
Observation 3 Time window-based method (and its variations) for supporting 32 HARQ processes is not aligned with
asynchronous NR HARQ design principle, introduces unnecessary scheduling restriction, and thus is against the RAN1
agreement of “minimizing the impacts on specification and scheduling.”
Observation 4 The intention of disabling HARQ feedback for a downlink transmission is not to send HARQ feedback for the
downlink transmission.
Observation 5 If the network schedules a PDSCH on a HARQ process with feedback disabled, it is clear that the network is not
interested in receiving the feedback.
Observation 6 Sending feedback from UE for a HARQ process with disabled feedback leads to waste of radio resource and UE
power consumption, as well as increased interference.
Observation 7 The uplink HARQ process reuse rule that “the UE is not expected to be scheduled to transmit another PUSCH
for a given HARQ process until after the end of the expected transmission of the last PUSCH for that HARQ process” does
not impose restriction that would lead to throughput reduction in the presence of large RTT, regardless of whether the DL and
UL frame timings are aligned or not at the gNB/UE.
Observation 8 The downlink HARQ process reuse rule that “the UE is not expected to receive another PDSCH for a given
HARQ process until after the end of the expected transmission of HARQ-ACK for that HARQ process” is not applicable to a
HARQ process with feedback disabled.
Proposal 1Whether 32 HARQ processes are used or not in the uplink can be configured by RRC.
Proposal 2Whether 32 HARQ processes are used or not in the downlink can be configured by RRC.
Proposal 3If 32 HARQ processes are configured, an additional bit is present in DCI 0_1/1_1. This additional bit, together with
the existing 4 bits in the HARQ process ID field, can be used to indicate 32 HARQ processes.
Proposal 4If 32 HARQ processes are configured, the size of the HARQ process ID field in DCI 0_2/2_2 is 5 bits.
Proposal 5RAN1 to down select one option: Option 1 – UE expects that at least one HARQ process is configured with UL
HARQ feedback; Option 2 – UE does not expect a MAC CE activation/deactivation command, which would become effective
3 msec after the UE would transmit the corresponding HARQ-ACK, to be scheduled on a downlink HARQ process with
disabled feedback.
Proposal 6RAN1 to discuss what parameters need to be configured differently for HARQ processes with feedback and HARQ
processes without feedback. Example parameters include MCS table and aggregation factor.
Proposal 7When HARQ processes are enabled/disabled on a per HARQ process basis, in the case of the NR Type-1 HARQ
codebook, the UE inserts NACKs in positions corresponding to PDSCHs associated with feedback disabled HARQ processes.
Proposal 8When HARQ processes are enabled/disabled on a per HARQ process basis, in the case of the NR Type-2 HARQ
codebook, the UE ignores counter DAI from a PDCCH that is associated with a feedback disabled HARQ process and counter
DAI is not incremented for such a PDCCH.
Proposal 9When HARQ processes are enabled/disabled on a per HARQ process basis, in the case of the NR Type-2 HARQ
codebook, the total DAI (if present) indicates the sum of all the scheduled PDCCHs associated with feedback enabled HARQ
process.
Proposal 10 When HARQ processes are enabled/disabled on a per HARQ process basis, in the case of the NR Type-3
HARQ codebook, the codebook size is dimensioned to include ACK/NACK information only for HARQ processes that are
enabled.
Proposal 11 Keep the existing uplink HARQ process reuse rule.
Proposal 12 For a DL HARQ process with disabled HARQ feedback, the UE is not expected to receive another PDSCH for
the given HARQ process until after the end of the expected reception of the last PDSCH for that HARQ process.

20/22
 R1-2009118
IDC
Observation-1: lowering target BLER for PDSCH when HARQ feedback is disabled is beneficial in terms of resource
utilization and latency as it can reduce the number of retransmissions in higher layer
Observation-2: use of a CQI table with a lower BLER target (e.g., 1%) could provide a better link adaptation with lower
PDSCH BLER target when HARQ feedback is disabled
Observation-3: increasing the maximum HARQ process number could provide benefits in terms of higher throughput, low
latency, better resource utilization over HARQ feedback disabling scheme when channel/interference changes dynamically
Observation-4: increasing the maximum HARQ process number is desirable only for some type of UEs (e.g., VSAT)
Proposal-1: a CQI table with a new target BLER (e.g., 1%) is considered when HARQ feedback is disabled
Proposal-2: blind retransmission is considered when HARQ feedback is disabled
Proposal-3: support maximum 32 HARQ process number as UE optional feature

R1- 2009154
Spreadtrum
Proposal 1: Additional scrambling for scheduling grant should be considered for enhancement on HARQ process number.
Proposal 2: Blind retransmission and larger aggregation/repetition factor can be considered for enhancing the performance of
transmission.

R1-2009244
Nokia
Observation 1: According to Error: Reference source not found, disabling HARQ may achieve similar throughput compared to
increasing the number of HARQ processes.

Observation 2: According to Error: Reference source not found, using 16 or 32 DL HARQ processes will give similar UE
experience in most scenarios

Observation 3: Using slot aggregation at low effective code rates will provide efficiency gains for cases with 2 or 4 slots being
aggregated.

Observation 4: Slot aggregation allows for supporting larger RTT delays while not compromising the HARQ performance.

Proposal 1: Limit the maximum of HARQ processes for NTN to 16 to ensure minimum specification changes

Proposal 2: For operating NTN systems, mechanisms like HARQ process disabling and slot aggregation are sufficient means
for addressing the HARQ stalling problem.

R1-2009264
QC
Proposal 1: For NTN, UE reports the capability on the number of HARQ processes.

Proposal 2: For NTN, more than 16 HARQ processes can be configured.

Proposal 3: For NTN, support slot number based HARQ process identification when more than 16 HARQ processes are
configured to a UE.

Proposal 4: Define a minimum time gap between two PDSCHs of a HARQ process without feedbacks

 Different numerologies may have different time gaps.

 FFS to introduce virtual k1.

21/22
Proposal 5: Consider new CQI BLER targets for HARQ processes without feedbacks.

Proposal 6: Support a new UCI feedback for reporting DL transmission disruption and/or requesting DL scheduling changes
when HARQ feedback is disabled.

 To study the new UCI format and associated resource allocation.

Proposal 7: For DL HARQ processes with HARQ feedback disabled, initial transmissions shall use RV 0 and retransmissions
shall not use RV 0.

Proposal 8: For Type-2 HARQ codebook, only PDSCHs of HARQ processes with feedback enabled are considered in DAIs
in DCI.

Proposal 9: Support search space configuration per HARQ process type.

Proposal 10: Support different transmit parameters and/or configurations per HARQ process or per HARQ process type
(retransmissions is enabled/disabled), including

 Power control
 MCS table
 UCI multiplexing parameters
 FFS other parameters
Proposal 11: For NTN, UE may receive a DCI scheduling a PUSCH of a given HARQ process before the end of the
transmission of another PUSCH of that HARQ process.

Proposal 12: Define a minimum time gap between two PUSCHs of a HARQ process.

22/22