WO2025024982A1

WO2025024982A1 - Hybrid automatic repeat request (harq) management for multi-dci based pusch

Info

Publication number: WO2025024982A1
Application number: PCT/CN2023/109918
Authority: WO
Inventors: Yushu Zhang; Jia-Hong Liou
Original assignee: Google LLC
Current assignee: Google LLC
Priority date: 2023-07-28
Filing date: 2023-07-28
Publication date: 2025-02-06
Anticipated expiration: 2026-01-28

Abstract

Systems, methods and apparatuses perform multi-DCI based PUSCH with Hybrid Automatic Repeat request (HARQ). A network entity (120) transmits (404) a configuration of control resource set (CORESET) pool indexes to a user equipment (UE) (110). The network entity transmits (408) a first uplink grant associated with a first CORESET pool index and a first HARQ process number that schedules a first physical uplink shared channel (PUSCH), and transmits (410) a second uplink grant associated with a second CORESET pool index and a second HARQ process number scheduling a second PUSCH. The UE generates (412) a first TB for the first PUSCH and a second TB for the second PUSCH based on whether or not the first HARQ process number and the second HARQ process number indicate the same HARQ process. The UE transmits (414) the first PUSCH and the second PUSCH to the network entity.

Description

HYBRID AUTOMATIC REPEAT REQUEST (HARQ) MANAGEMENT FOR MULTI-DCI BASED PUSCH

TECHNICAL FIELD

Aspects of the present disclosure relate generally to wireless communication and techniques for hybrid automatic repeat request (HARQ) management for wireless communication systems.

BACKGROUND

The reliability and efficiency of communications between a user equipment (UE) and a network entity may be improved through the use of Hybrid Automatic Repeat request (HARQ) processes. HARQ is a mechanism used for error detection and retransmission between the UE and the network entity which attempts to minimize the amount of data that is retransmitted in the case of a transmission error. A UE can be configured with one or more HARQ processes that can manage retransmission of data. The network entity can configure a UE with the number of HARQ processes for physical uplink shared channel (PUSCH) transmissions scheduled by downlink control information (DCI) . For each scheduled PUSCH, the network entity can indicate a HARQ process index (or HARQ process number) via the scheduling DCI. The network entity can indicate whether a scheduled transport block (TB) on the PUSCH is a new transmission or retransmission using a new data indicator (NDI) in the DCI.

BRIEF SUMMARY

The systems, methods, and devices of this disclosure each have several innovative aspects, no single one of which is solely responsible for the desirable attributes disclosed herein.

One innovative aspect of the subject matter described in this disclosure can be implemented as a method for wireless communications by a network entity. The method may include transmitting, to a user equipment, a configuration of a plurality of control resource set (CORESET) pool indexes, the plurality of CORESET pool indexes including a first CORESET pool index associated with a first CORESET pool and a second CORESET pool index associated with a second CORESET pool. The method may further include transmitting, to the UE, a first uplink grant scheduling a first physical uplink shared channel (PUSCH) , the first uplink grant being associated with the first CORESET pool index and a first hybrid automatic repeat request (HARQ) process number. The method may further include transmitting, to the UE, a second uplink grant scheduling a second PUSCH, the second uplink grant being associated with the second CORESET pool index and a second HARQ process number. The method may further include receiving, from the UE, the first PUSCH and the second PUSCH, the first PUSCH having a first transport block (TB) and the second PUSCH having a second TB, the first TB and the second TB being generated based on whether or not the first HARQ process number and the second HARQ process number indicate a same HARQ process.

Another innovative aspect of the subject matter described in this disclosure can be implemented as a method for wireless communications by a user equipment. The method may include receiving, from a network entity, a configuration of at least two control resource set (CORESET) pool indexes, the at least two CORESET pool indexes including a first CORESET pool index associated with a first CORESET pool and a second CORESET pool index associated with a second CORESET pool. The method may further include receiving, from the network entity, a first uplink grant scheduling a first physical uplink shared channel (PUSCH) , the first uplink grant being associated with the first CORESET pool index and a first hybrid automatic repeat request (HARQ) process number. The method may further include receiving, from the network entity, a second uplink grant scheduling a second PUSCH, the second uplink grant being associated with the second CORESET pool index and a second HARQ process number. The method may further include generating a first transport block (TB) and a second TB based on whether or not the first HARQ process number and the second HARQ process number indicate a same HARQ process. The method may further include transmitting, to the network entity, the first PUSCH and the second PUSCH, the first PUSCH having the first TB and the second PUSCH having the second TB.

Details of one or more implementations of the subject matter described in this disclosure are set forth in the accompanying drawings and the description below. Other features, aspects, and advantages will become apparent from the description, the drawings, and the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

Note that the relative dimensions of the following figures may not be drawn to scale. Like reference numbers and designations in the various drawings indicate like elements. To easily identify the discussion of any particular element or act, the most significant digit or digits in a reference number refer to the figure number in which that element is first introduced.

Figure 1 is a diagram illustrating an example wireless system including a user equipment communicating with a network entity via multiple transmit/receive points (TRPs) .

Figure 2A is a diagram illustrating multiple downlink control information (multi-DCI) based physical uplink shared channel (PUSCH) .

Figure 2B is a diagram illustrating multi-DCI based PUSCH where each PUSCH has the same indicated hybrid automatic repeat request process number.

Figure 3 is a block diagram illustrating example configurations of a network entity and a user equipment.

Figure 4 is a sequence diagram illustrating example operations of a communications process for HARQ process management for multi-DCI based PUSCH.

Figure 5 is a sequence diagram illustrating example operations of a communications process for HARQ process management for multi-DCI based PUSCH, where the network entity may indicate the same HARQ process for multiple PUSCHs.

Figure 6 is a flow chart diagram illustrating example UE operations of a method for HARQ process management for multi-DCI based PUSCH where the network entity may indicate the same HARQ process for multiple PUSCHs.

Figure 7 is a flow chart diagram illustrating example network entity operations of a method for HARQ process management for multi-DCI based PUSCH.

Figure 8 is a diagram illustrating an example per-TRP candidate HARQ process list configuration.

Figure 9 is a diagram illustrating an example TRP-specific HARQ entity.

Figure 10 is a diagram illustrating an example HARQ process associated with a HARQ process ID and TRP ID.

Figure 11 is a diagram illustrating example PUSCH schedule offsets.

DETAILED DESCRIPTION

The following description is directed to certain implementations for the purpose of describing the innovative aspects of this disclosure. However, a person having ordinary skill in the art will readily recognize that the teachings herein can be applied in a multitude of different ways. Some of the examples in this disclosure are based on wireless communication according to the 3rd Generation Partnership Project (3GPP) wireless standards, such as the 4th generation (4G) Long Term Evolution (LTE) and 5th generation (5G) New Radio (NR) standards. However, the described implementations can be implemented in any device, system, or network that is capable of transmitting and receiving radio frequency signals according to any of the wireless communication standards, including any of the Institute of Electrical and Electronics Engineers (IEEE) 802.11, 802.15, or 802.16 wireless standards, or other known signals that are used to communicate within a wireless, cellular, or internet of things (IOT) network, such as a system utilizing 3G, 4G, 5G, WiFi or future radio technology.

As discussed above, some wireless communication systems use HARQ to improve wireless communication reliability and efficiency. HARQ may be combined with multiple transmit/receive point (multi-TRP) operation to further improve wireless communication reliability and efficiency. In multi-TRP operation, a network entity can schedule a PUSCH for each TRP. For example, a network entity can schedule multiple PUSCHs with multiple DCIs, where each DCI schedules a PUSCH from a different TRP. The scheduled PUSCHs may be fully or partially overlapping in the time domain. Each DCI indicates different parameters for the scheduled PUSCH, including a HARQ process number used to identify the HARQ process for the PUSCH. The UE transmits the scheduled PUSCHs according to the parameters in corresponding DCI using different spatial domain filters (e.g., different transmission beams) .

A potential problem with using multiple DCIs to schedule multiple PUSCHs that overlap in the time domain is that the same HARQ process number may be inadvertently used for two different PUSCHs scheduled for two different TRPs. For example, the same HARQ process number may be used in two DCIs that are used to schedule PUSCHs that overlap in the time domain. In this case, there can be ambiguity as to whether the same HARQ process number is intended to refer to the transmission of the same TB for each PUSCH or transmission of a different TB for each PUSCH. Similarly, different HARQ process numbers may be mapped to the same HARQ process for the different overlapping PUSCHs. There can be ambiguity as to whether the different HARQ process numbers are referring to the transmission of the same TB for each PUSCH or to transmission of different TBs for each PUSCH. As a result of these ambiguities, a network entity may fail to properly determine and decode a TB.

According to aspects of the disclosure, different techniques may be used by a UE and network entity to remove ambiguities with respect to the HARQ processes indicated by HARQ process numbers when the network entity schedules overlapping PUSCHs. Some of the disclosed techniques reduce UE complexity in HARQ process management, thereby increasing the efficiency of the operation of the UE 110. A network entity can reduce UE complexity in HARQ process management by configuring a UE with two different sets of HARQ process numbers that refer to two different sets of HARQ processes, where the HARQ processes in one set are orthogonal to the HARQ processes in the second set. Thus, as long as a DCI for an overlapping PUSCH uses a different HARQ number than the DCI for the overlapped PUSCH, there can be no ambiguity that a different TB is intended for each PUSCH.

Some other disclosed techniques may improve communications reliability. Using such techniques, a network entity can generate DCIs that schedule PUSCHs causing the UE to transmit the same transport block (e.g., payload data) from CORESETs with different CORESET pool index values and different TRPs. If the network entity fails to receive one of the transport blocks from a TRP correctly, the network entity may be able to use the other transport block received from the other TRP to properly process the transport block. In these techniques, the network entity can indicate whether the UE is to transmit the same transport block using HARQ process numbers that refer to the same HARQ process and toggling the new data indicator (NDI) in the DCIs used to schedule the PUSCHs.

Figure 1 is a conceptual diagram illustrating an example wireless system including a user equipment communicating with a network entity via multiple transmit/receive points (TRPs) . In the example shown in Figure 1, wireless communication system 100 includes a UE 110 that wirelessly communicates with a network entity 120 via TRPs 122A and 122B in a multi-TRP mode of operation. Network entity 120 may be coupled to TRPs 122A and 122B via respective fronthaul networks 130A and 130B. For example, fronthaul networks 130A and 130B may be high performance networks such as fiber optic networks.

Although illustrated as a smartphone in Figure 1, the UE 110 may be implemented as any suitable computing or electronic device, such as a mobile communication device, a modem, cellular phone, gaming device, navigation device, media device, laptop computer, desktop computer, tablet computer, smart appliance, vehicle-based communication system, an Internet-of-things (IoT) device (e.g., sensor node, controller/actuator node, combination thereof) , and the like. Network entity 120 (e.g., base station, an Evolved Universal Terrestrial Radio Access Network Node B (E-UTRAN Node B) , evolved Node B, eNodeB, eNB, Next Generation Node B, gNode B, gNB, ng-eNB, access point, radio head or the like) may be implemented in a macrocell, microcell, small cell, picocell, or the like, or any combination thereof. The network entity 120 may be configured to use multiple-input and multiple-output (MIMO) communication in which multiple TRPs (e.g., TRPs 122A and 122B) associated with the network entity 120 are used to exchange wireless communication signals with UE 110.

In some aspects, the functionality, and thus the hardware components, of the network entity 120 may be distributed across multiple network nodes or devices and may be distributed in a manner to perform the functions described herein. As one example, the functionality of network entity 120 may be distributed across a radio unit (RU) , distributed unit (DU) , or central unit (CU) .

The UE 110 may communicate with network entity 120 and TRPs 122A and 122B using wireless links (not shown in Fig. 1) , which may be implemented as any suitable type of wireless link. The wireless links may include one or more wireless links (e.g., radio links) or bearers implemented using any suitable communication protocol or standard, or combination of communication protocols or standards, such as 3rd Generation Partnership Project Long-Term Evolution (3GPP LTE) , Fifth Generation New Radio (5G NR) , and so forth. Multiple wireless links may be aggregated in a carrier aggregation to provide a higher data rate for the UE 110.

The network entity 120 and TRPs 122A and 122B support wireless communication with one or more UEs, such as UE 110, via radio frequency (RF) signaling using one or more applicable radio access technologies (RATs) as specified by one or more communications protocols or standards. The network entity 120 and the TRPs 122A and 122B may employ any of a variety of RATs, such as operating as a NodeB (or base transceiver station (BTS) ) for a Universal Mobile Telecommunications System (UMTS) RAT (also known as “3G” ) , operating as an enhanced NodeB ( “eNB” ) for a Third Generation Partnership Project (3GPP) Long Term Evolution (LTE) RAT, operating as a 5G node B ( “gNB” ) for a 3GPP Fifth Generation (5G) New Radio (NR) RAT, and the like.

The network entity 120 and TRPs 122A and 122B may be part of a radio access network (RAN) , for example, an Evolved Universal Terrestrial Radio Access Network, E-UTRAN, 5G NR RAN, or NR RAN. The network entity 120 may be connected to a core network 150. For example, the network entity 120 may connect to the core network 150 through an NG2 interface for control-plane signaling and using an NG3 interface for user-plane data communications when connecting to a 5G core network, or using an Si interface for control-plane signaling and user-plane data communications when connecting to an Evolved Packet Core (EPC) network. The network entity 120 may communicate using an Xn Application Protocol (XnAP) through an Xn interface or using an X2 Application Protocol (X2AP) through an X2 interface to exchange user-plane and control-plane data. The UE 110 may connect, via the core network 150, to one or more wide area networks (WANs) 160 or other packet data networks (PDNs) , such as the Internet.

Communications between network entity 120 and UE 110 utilize an uplink (UL) transmission path 112 for RF transmissions from the UE 110 to the network entity 120 and a downlink (DL) transmission path 114 for RF transmissions from the network entity 120 to the UE 110. As such, in the context of the UL transmission path 112, the UE 110 serves as the data sending device and the network entity 120 serves as the data receiving device, whereas in the context of the DL transmission path 114, the network entity 120 serves as the data sending device and the UE 110 serves as the data receiving device. UL transmission path 112 and DL transmission path 114 may utilize multiple communications channels for signal transmission. The multiple channels may each have different purposes.

UL transmission path 112 may include a Physical Uplink Shared Channel (PUSCH) , a Physical Uplink Control Channel (PUCCH) , and a Physical Random Access Channel (PRACH) . The PUSCH is used for the transmission of user data, such as voice data, video data, or text message data from UE 110 to network entity 120. Additionally, the PUSCH may be used to transmit control information (e.g., uplink control information (UCI) ) . The PUSCH may be shared by multiple UEs. The PUCCH is used for transmitting control information (e.g., UCI) from the UE to the network, such as channel quality feedback, scheduling requests, and acknowledgments. The PRACH is used for random access in the uplink direction, enabling the UE to access the system.

DL transmission path 114 may include one or more of a Physical Downlink Shared Channel (PDSCH) , a Physical Downlink Control Channel (PDCCH) , a Physical Broadcast Channel (PBCH) , or a paging channel. The PDSCH is used for transmission of user data from the network entity to the UE. The PDSCH may be shared by multiple UEs. As with the PUSCH, the data may be any type of information, such as voice data, video data, or text message data. The paging channel is used to notify the UE 110 that there is incoming traffic for it from the network entity 120.

As discussed above, the network entity 120 and the UE 110 may utilize HARQ to improve wireless communications reliability and efficiency. For a bandwidth part (BWP) , the network entity 120 can configure the UE 110 with one or more than one uplink HARQ processes. Each of the HARQ processes may be identified by a HARQ process number. The HARQ process number may be determined by the network entity 120 during an initial connection setup with the UE 110. The process number is used to differentiate between different HARQ processes that may be simultaneously ongoing for the UE 110 and facilitates tracking and managing the retransmission and error correction procedures associated with each specific process. In some aspects, the network entity 120 can configure the number of HARQ processes for physical uplink shared channel (PUSCH) scheduled by downlink control information (DCI) format 0_1 and DCI format 0_2 by radio resource control (RRC) signaling. e.g., RRC parameter harq-ProcessNumberSizeDCI-0-1 and harq-ProcessNumberSizeDCI-0-2. For DCI format 0_0, the network entity 120 can indicate one of 16 HARQ processes. For each scheduled PUSCH, the network entity can indicate the HARQ process index associated with the PUSCH via the DCI scheduling the PUSCH. The network entity 120 can indicate whether a scheduled transport block (TB) on the PUSCH is a new transmission or retransmission by the DCI, e.g., by toggling the new data indicator (NDI) field of the DCI for the TB.

The network entity 120 can schedule multiple PUSCHs using multiple downlink control information (DCI) , where each DCI schedules one PUSCH. Each DCI of the multiple DCIs are from different control resource sets (CORESETs) with different CORESET pool indexes, e.g., the CORESETs are configured with different values of the RRC parameter coresetPoolIndex. A CORESET is a set of physical resources in the time-frequency domain allocated for the transmission of control information. The control information sent through the CORESET includes DCI and other control channels like PDCCH. Each DCI may indicate the time and frequency resource, modulation and coding scheme (MCS) , HARQ process, NDI, redundancy version for the scheduled PUSCH, etc.

The UE 110 may transmit the scheduled PUSCHs by different spatial domain filters (e.g., beams 124A and 124B) , where the UE determines the spatial domain filters based on the transmission configuration indication (TCI) states (joint or uplink TCI state (s) ) indicated by the network entity via RRC signaling, Medium Access Control (MAC) Control Element (CE) , or DCI. The scheduled PUSCHs may be fully or partially overlapped in time domain.

Figure 2A is a conceptual diagram illustrating an example multi-DCI based PUSCH 200. In the example shown in Figure 2A, the network entity (e.g., network entity 120 of Figure 1) has scheduled two PUSCHs 202A and 202B. PUSCH 202A may be scheduled by DCI 204A using resources from CORESET pool 0, and PUSCH 202B may be scheduled by DCI 204B using resources from CORESET pool 1. As seen in Figure 2A, PUSCH 202A overlaps in the time domain with PUSCH 202B.

Returning to Figure 1, a potential problem with using multiple DCIs to schedule multiple PUSCHs that overlap in the time domain is that the same HARQ process number may be inadvertently used for two different PUSCHs scheduled for two different TRPs. For example, the same HARQ process number may be used in two DCIs that are used to schedule PUSCHs that overlap. In this case, there can be ambiguity as to whether the same HARQ process number is intended to refer to the transmission of the same TB for each PUSCH or transmission of a different TB for each PUSCH. Similarly, different HARQ process numbers may be mapped to the same HARQ process for the different overlapping PUSCHs. There can be ambiguity as to whether the different HARQ process numbers are referring to the transmission of the same TB for each PUSCH or to transmission of a different TB for each PUSCH. As a result of these ambiguities, a network entity may fail to properly determine and decode a TB.

Figure 2B is a conceptual diagram illustrating multi-DCI based PUSCH 210 where each PUSCH has the same indicated HARQ process number. In the example shown in Figure 2B, DCI 204A has used the same HARQ process number k (206A) as the HARQ process number k (206B) used by DCI 204B. Thus, there is ambiguity as to whether the HARQ process with process number k is associated with a first TB scheduled for transmission via DCI 204A or a second TB scheduled for transmission via DCI 204B. As a result of this ambiguity, network entity 120 may not be able to properly decode the TB to obtain the correct payload data.

Returning to Figure 1, according to aspects of the disclosure, different techniques may be used by a UE and network entity to remove ambiguities with respect to the HARQ processes indicated by HARQ process numbers when the network entity schedules overlapping PUSCHs. Some of the disclosed techniques reduce UE complexity in HARQ process management. A network entity can reduce UE complexity in HARQ process management by configuring a UE with two different sets of HARQ process numbers that refer to two different sets of HARQ processes, where the HARQ processes in one set are orthogonal to the HARQ processes in the second set. Thus, as long as a DCI for an overlapping PUSCH uses a different HARQ number than the DCI for the overlapped PUSCH, there can be no ambiguity that a different TB is intended for each PUSCH.

Some other disclosed techniques may improve communications reliability. Using such techniques, a network entity can generate DCIs that schedule PUSCHs causing the UE to transmit the same transport block (e.g., payload data) from different TRPs. If the network entity fails to receive one of the transport blocks from a TRP correctly, the network entity may be able to use the other transport block received from the other TRP to properly process the transport block. In these techniques, the network entity can indicate whether the UE is to transmit the same transport block using HARQ process numbers that refer to the same HARQ process and the NDI in the DCIs used to schedule the PUSCHs.

In the example shown in Figure 1, two TRPs 122A and 122B are illustrated. However, a wireless communications system may include more than two TRPs.

Further details of various techniques and aspects of disclosure are provided below with respect to Figures 3-11.

Figure 3 is a block diagram illustrating example configurations of a network entity and a user equipment. Note that the depicted hardware configurations represent the processing components and communication components related to HARQ process management by a network entity 120 and UE 110. The depicted hardware configurations may omit certain components well-understood to be frequently implemented in such electronic devices, such as displays, peripherals, power supplies, and the like.

The UE 110 includes antennas 302, a radio frequency front end (RF front end) 304, and radio-frequency transceivers (e.g., an LTE transceiver 306 and a 5G NR transceiver 308) for communicating with network entity 120 and/or one or more TRPs (e.g., TRPs 122A and 122B of Figure 1) .

The RF front end 304 includes one or more modems configured for the corresponding RAT(s) employed (for example, Third Generation Partnership Project (3GPP) Fifth Generation New Radio (5G NR) ) , one or more analog-to-digital converters (ADCs) , one or more digital-to-analog converters (DACs) , signal processors, and the like. In the example illustrated in Figure 3, the RF front end 304 of the UE 110 may couple or connect the LTE transceiver 306, and the 5G NR transceiver 308 to the antennas 302 to facilitate various types of wireless communication. The RF front end 304 operates, in effect, as a physical (PHY) transceiver interface to conduct and process signaling between the one or more processors 314 and the antennas 302 so as to facilitate various types of wireless communication.

The antennas 302 of the UE 110 may include an array of multiple antennas that may be tuned to one or more frequency bands associated with a corresponding RAT. The antennas 302 and the RF front end 304 may be tuned to, and/or be tunable to, one or more frequency bands defined by the 3GPP LTE and 5G NR communication standards and implemented by the LTE transceiver 306, and/or the 5G NR transceiver 308. Additionally, the antennas 302, the RF front end 304, the LTE transceiver 306, and/or the 5G NR transceiver 308 may be configured to support beamforming for the transmission and reception of communications with the network entity 120 and/or with one or more TRPs (e.g., TRPs 122A and 122B of Figure 1) . By way of example and not limitation, the antennas 302 and the RF front end 304 may be implemented for operation in sub-gigahertz bands, sub-6 GHz bands, and/or above 6 GHz bands that are defined by the 3GPP LTE and 5G NR communication standards.

The UE 110 also includes processor (s) 314 and computer-readable storage media (CRM) 316. The processor 314 may include, for example, one or more central processing units, graphics processing units (GPUs) , or other application-specific integrated circuits (ASIC) , and the like. To illustrate, the processors 314 may include an application processor (AP) utilized by the UE 110 to execute an operating system and various user-level software applications, as well as one or more processors utilized by modems or a baseband processor of the RF front end 304.

CRM 316 may include any suitable memory or storage device such as random-access memory (RAM) , static RAM (SRAM) , dynamic RAM (DRAM) , non-volatile RAM (NVRAM) , read-only memory (ROM) , Flash memory, solid-state drive (SSD) or other mass-storage devices, and the like useable to store one or more sets of executable software instructions and associated data that manipulate the one or more processors 314 and other components of the UE 110 to perform the various functions described herein and attributed to the UE 110. The sets of executable software instructions include, for example, an operating system (OS) and various drivers (not shown) , and various software applications (not shown) , which are executable by processor (s) 314 to enable user-plane communication, control-plane signaling, and user interaction with the UE 110. The data 318 stored in the CRM 316 represents, for example, user data, multimedia data, beamforming codebooks, software application configuration information, and the like. Data 318 may include HARQ processes 319, DCIs 320, and TBs 321.

CRM 316 also includes a communications controller 322. Alternately or additionally, the communications controller 322 may be implemented in whole or part as hardware logic or circuitry integrated with or separate from other components of the UE 110. In some aspects, communications controller 322 configures the RF front end 304, the LTE transceiver 306, and/or the 5G NR transceiver 308 to implement the techniques described herein for HARQ process management associated with multi-DCI based PUSCH.

Turning to the hardware configuration of the network entity 120, it is noted that although Figure 3 illustrates an implementation of the network entity 120 as a single network node (for example, a 5G NR Node B, or “gNB” ) , the functionality, and thus the hardware components, of the network entity 120 instead may be distributed across multiple network nodes or devices and may be distributed in a manner to perform the functions described herein. As one example, the functionality of network entity 120 may be distributed across a radio unit (RU) , distributed unit (DU) , or central unit (CU) .

The network entity 120 includes antennas 352, a radio frequency front end (RF front end) 354, one or more LTE transceivers 356, and/or one or more 5G NR transceivers 358 for communicating with the UE 110. The RF front end 354 of the network entity 120 may couple or connect the LTE transceivers 356 and the 5G NR transceivers 358 to the antennas 352 to facilitate various types of wireless communication. Similar to RF front end 304, the RF front end 354 includes one or more modems, one or more ADCs, one or more DACs, and the like. RF front end 354 receives the one or more RF signals, for example, RF signals from UE 110, and pre-processes the one or more RF signals to generate data from the RF signals that is provided as input to processes and/or applications executing on network entity 120. This pre-processing may include, for example, power amplification, conversion of band-pass signaling to baseband signaling, initial analog-to-digital conversion, and the like.

The antennas 352 of the network entity 120 may be configured individually and/or as one or more arrays of multiple antennas. The antennas 352 and the RF front end 354 may be tuned to, and/or be tunable to, one or more frequency band defined by the 3GPP LTE and 5G NR communication standards, and implemented by the LTE transceivers 356, and/or the 5G NR transceivers 358. Additionally, the antennas 352, the RF front end 354, the LTE transceivers 356, and/or the 5G NR transceivers 358 may be configured to support beamforming, such as Massive-MIMO, for the transmission and reception of communications with the UE 110.

The network entity 120 also includes processor (s) 360 and computer-readable storage media (CRM) 362. The processor 360 may include, for example, one or more central processing units, graphics processing units (GPUs) , or other application-specific integrated circuits (ASIC) , and the like. To illustrate, the processors 360 may include an application processor (AP) utilized by the network entity 120 to execute an operating system and various user-level software applications, as well as one or more processors utilized by modems or a baseband processor of the RF front end 354 to enable communication with the UE 110.

CRM 362 may include any suitable memory or storage device such as random-access memory (RAM) , static RAM (SRAM) , dynamic RAM (DRAM) , non-volatile RAM (NVRAM) , read-only memory (ROM) , or Flash memory useable to store device data of the network entity 120. The device data may include data 364, which includes network scheduling data, radio resource management data, beamforming codebooks, software application configuration information, UE transmitter power levels, and/or TRP configuration data and the like. Data 364 may further include DCIs 361 and transport blocks 363.

CRM 362 additionally includes a communications controller 371. Alternately or additionally, the communications controller 371 may be implemented in whole or part as hardware logic or circuitry integrated with or separate from other components of the network entity 120. Like communications controller 322 of UE 110, communications controller 371 configures the RF front end 354, the LTE transceiver 356, and/or the 5G NR transceiver 358 to implement the techniques described herein for HARQ process management associated with multi-DCI based PUSCH.

CRM 362 also includes an RF resource manager 365. In some aspects, the RF resource manager 365 of the network entity 120 is implemented to perform various functions associated with allocating physical access (for example, resource blocks) or communication resources for the air interface of the network entity 120. The air interface of the network entity 120, may be partitioned or divided into various units (for example, frames, subframes, or slots) of one or more of bandwidth, time, symbols, or spatial layers. For example, within a framework of a 5G NR protocol, the RF resource manager 365 may allocate bandwidth and time intervals of access in resource blocks, each of which may be allocated in whole, or in part, to one or more channels for communicating with the UE 110. The channels may include one or more of a PRACH, a PUCCH, a PUSCH, a PDCCH, a PDSCH, a PBCH, or a paging channel. The resource blocks may include multiple subcarriers that each span a portion of a frequency domain of the resource blocks. The subcarriers may be further divided into resource elements, or orthogonal frequency-division multiplexing (OFDM) symbols, that each span a portion of a time domain of the subcarriers. Consequently, a resource block includes multiple OFDM symbols that may be grouped into subcarriers with other OFDM symbols having a common frequency bandwidth.

CRM 362 further includes network entity manager 366. Alternately or additionally, the network entity manager 366 may be implemented in whole or part as hardware logic or circuitry integrated with or separate from other components of the network entity 120. In at least some aspects, the network entity manager 366 configures the LTE transceivers 356 and the 5G NR transceivers 358 for communication with the UE 110, communication with TRPs (e.g., TRPs 122A and 122B of Figure 1) via fronthaul interface 367, as well as communication with a core network 150 (Figure 1) .

In some aspects, the network entity 120 includes an inter-network entity station interface 368, such as an Xn and/or X2 interface, which the network entity manager 366 configures to exchange user-plane and control-plane data between another network entity, to manage the communication of the network entity 120 with the UE 110. The network entity 120 includes a core network interface 370 that the network entity manager 366 configures to exchange user-plane and control-plane data with core network functions and entities.

Figures 4-11 and the accompanying description below describe various techniques for HARQ process management for multi-DCI based PUSCH. In some examples that follow, the operations may be described as utilizing RRC signaling. Unless specified otherwise, RRC signaling may indicate a RRC reconfiguration message from the network entity to the UE, or a system information block (SIB) , where the SIB may be an existing SIB (e.g., SIB1) or a new SIB (e.g., SIB J, where J is an integer above 21) transmitted by the network entity.

Figure 4 is a sequence diagram illustrating example operations of a communications process 400 for HARQ process management for multi-DCI based PUSCH. Although not illustrated for the sake of illustration clarity, various acknowledgements for messages illustrated in Figure 4 may be implemented to ensure reliable operations for HARQ process management associated with multi-DCI based PUSCH.

At operation 402, the UE 110 may transmit or report to network entity 120 the UE’s capability (s) for supporting HARQ process management for multi-DCI based PUSCH. In some aspects, UE 110 may communicate UE capability information to the network entity 120 during an initial communication session setup process between the UE 110 and the network entity 120. UE capability information may include supported frequency bands, radio access technologies, maximum transmission power, maximum data rates, and network protocols. In some implementations, the UE 110 may report UE capability information indicating whether the UE supports the same HARQ process for the PUSCHs scheduled by multiple DCIs, that fully or partially overlap with each other in time domain.

In the example of Figure 4, the UE 110 transmits UE capability information to network entity 120. In some implementations, the network entity may receive the UE capability from a core network (e.g., from an access and mobility management function (AMF) of the core network 150 of Figure 1) . In some other implementations, the network entity receives the UE capability from another network entity (e.g., a gNB or eNB) .

At operation 404, the network entity 120 may, depending on the UE capability information received at operation 402, configure at least two CORESETs with different CORESET pool indexes. In some aspects, the network entity 120 may configure the CORESETS using control signaling, e.g., RRCReconfiguration. The network entity 120 may configure other parameters for multi-DCI based PUSCH, e.g., more than one sounding reference signal (SRS) resource sets for codebook or non-codebook based transmission.

In some implementations, at operation 406, the network entity 120 may configure candidate HARQ processes for each CORESET pool. Various implementations may configure candidate HARQ processes in different ways depending on UE capability and operational considerations such as reduced UE complexity and/or increased reliability. Examples of various configurations of candidate HARQ processes are detailed below with reference to Figures 8-11.

At operation 408, the network entity 120 may transmit a first DCI including an uplink grant scheduling a first PUSCH for a first TRP using a first CORESET pool. The first DCI includes a first HARQ process number indicating a first HARQ process. The network entity 120 may select the first HARQ process number from candidate HARQ processes for a first CORESET associated with a first TRP (e.g., TRP 122A of Figure 1) . In some implementations, the network entity 120 may transmit the first DCI by RRC signaling. In some other implementations, the network entity may transmit the first DCI by PDCCH.

At operation 410, the network entity may transmit a second DCI including an uplink grant scheduling a second PUSCH for a second TRP using a second CORESET pool different from the first CORESET pool. The second DCI includes a second HARQ process number different from the first HARQ process number, where the second HARQ process number indicates a second HARQ process that is different from the first HARQ process indicated by the first HARQ process number. The network entity 120 may select the second HARQ process number from candidate HARQ processes for a second CORESET associated with a second TRP (e.g., TRP 122B of Figure 1) . In some implementations, the network entity may transmit the second DCI by RRC signaling. In some other implementations, the network entity may transmit the second DCI by PDCCH.

At operation 412, the UE 110 determines and generates the TB for each scheduled PUSCH based on the first DCI and the second DCI.

At operation 414, the UE 110 transmits, to the network entity 120, the scheduled first PUSCH and second PUSCH with separate TBs for each PUSCH. The first PUSCH and second PUSCH may be transmitted such that they overlap in the time domain.

At operation 416, the network entity 120 calculates the TB size for each scheduled PUSCH to decode the PUSCHs based on the respective DCIs scheduling the first and second PUSCH.

Figure 5 is a sequence diagram illustrating example operations of a communications process 500 for HARQ process management for multi-DCI based PUSCH, where the network entity 120 may indicate the same HARQ process for multiple PUSCHs. Compared to the communications process 400 of Figure 4, the difference in communications process 500 is that the network entity 120 may indicate the same HARQ process for the scheduled PUSCHs, and the network entity 120 may optionally provide RRC parameters for a common TB based on PUSCH repetitions scheduled by multi-DCI based PUSCH. Although not illustrated for the sake of illustration clarity, various acknowledgements for messages illustrated in Figure 5 may be implemented to ensure reliable operations for HARQ process management.

At operation 402, like operation 402 of Figure 4, the UE 110 may transmit or report to network entity 120 the UE’s capability (s) for supporting HARQ process management for multi-DCI based PUSCH. In some aspects, UE 110 may communicate UE capability information to the network entity 120 during an initial communication session setup process between the UE 110 and the network entity 120. UE capability information may include supported frequency bands, radio access technologies, maximum transmission power, maximum data rates, and network protocols. In some implementations, the UE 110 may report UE capability information indicating whether the UE supports the same HARQ process for the PUSCHs scheduled by multiple DCIs, which fully or partially overlap with each other in time domain.

At operation 404, like operation 404 of Figure 4, the network entity 120 may, depending on the UE capability information received at operation 402, configure at least two CORESETs with different CORESET pool indexes by control signaling, e.g., RRCReconfiguration. The network entity 120 may configure other parameters for multi-DCI based PUSCH, e.g., more than one sounding reference signal (SRS) resource sets for codebook or non-codebook based transmission.

At operation 506, the network entity 120 may optionally provide RRC parameters for transmitting a common TB in different PUSCH transmissions scheduled by multi-DCI based PUSCH repetitions.

At operation 508, the network entity 120 may transmit a first DCI including an uplink grant scheduling a first PUSCH for a first TRP associated with a first CORESET pool. The first DCI includes a first HARQ process number indicating a first HARQ process. In some implementations, the network entity 120 may transmit the first DCI by RRC signaling. In some other implementations, the network entity may transmit the first DCI by PDCCH. The first DCI may optionally include parameters for multi-DCI based PUSCH repetitions of a common TB.

At operation 510, the network entity 120 may transmit a second DCI including an uplink grant scheduling a second PUSCH for a second TRP associated with a second CORESET pool different from the first CORESET pool. The second DCI includes a second HARQ process number indicating a second HARQ process. In some implementations, the network entity 120 may transmit the second DCI by RRC signaling. In some other implementations, the network entity 120 may transmit the second DCI by PDCCH. The second DCI may optionally include parameters for multi-DCI based PUSCH repetitions of a common TB.

At operation 512, the UE 110 determines that the first scheduled PUSCH and the second scheduled PUSCH are to transmit a common TB, that is, a TB having the same payload data. In this case, the UE 110 may determine a TB size (TBS) for the common TB. Because the TBs are transmitted by different PUSCHs, there may be issues in determining a TBS for the common TB. For example, the time and frequency resource, MCS, and number of layers for the scheduled PUSCHs could be different. The UE 110 may determine the TBS for a common TB in various ways. For example, the UE may determine the TB size based on one of the scheduling DCIs, based on both or all of the scheduling DCIs, or based on a configurable TBS determination scheme.

Examples where the UE and/or network entity determines the TBS based on one of the scheduling DCIs will now be described. In some aspects, the UE may determine the TBS based on the DCI associated with the first or last TRP, e.g., the first or last CORESET pool. In some other aspects, the UE may determine the TBS of scheduled PUSCHs based on the DCI that starts or ends earlier. In other words, the UE may determine the TBS of the scheduled PUSCHs based on the scheduling PDCCH that starts or ends earlier. A scheduling PDCCH could be a PDCCH carrying a DCI that schedules a PUSCH. If both DCIs or scheduling PDCCHs start or end at the same time, the UE may determine the TBS of scheduled PUSCH based on the DCI associated with a specific TRP, e.g., the first TRP, which in turn may be related to the first CORESET pool. In some other examples, the specific TRP could also be the second TRP (which may be related to the second CORESET pool) .

In some other aspects, the UE may determine the TBS based on the scheduling DCI that starts or ends later. If both DCIs start or end at the same time, the UE may determine the TBS based on the DCI associated with the first TRP, e.g., the first CORESET pool.

In some other aspects, the network entity may configure or indicate which DCI is to be used for TBS determination using RRC signaling, a MAC CE, or DCI. In one example, the network entity may utilize RRC signal to configure whether to determine the TBS based on the DCI associated with the first or second TRP, e.g., the first or second CORESET pool. In another example, the network entity indicates in the scheduling DCI whether the DCI is to be used for TBS selection. In some other implementations, the DCI with a particular DCI format type may be used for TBS determination, e.g., DCI format 0_1 or 0_2.

In some other aspects, when the network entity 120 indicates the same HARQ process in the scheduling DCIs, the network entity 120 may refrain from indicating the time and frequency resources, MCS, and number of layers in the DCIs that lead to a different TBS for each of the scheduled PUSCHs. In one example, when the network entity 120 indicates the same HARQ process in the scheduling DCIs, the network entity 120 may indicate the same value for at least one of the parameters including time domain resource, frequency domain resource, MCS, and number of layers in the DCIs.

In some other implementations, the UE may determine the TBS based on the DCI indicating that the corresponding TB is for an initial transmission. In such implementations, the network entity may refrain from indicating initial transmission for the same HARQ process in the scheduling DCIs to avoid ambiguity as to which DCI is to be used for TBS determination.

In some implementations, the network entity and/or the UE may determine the minimum scheduling offset for the PUSCHs based on the last symbol of the DCI used to determine the TBS, the last symbol of the scheduling DCI/PDCCH, the first symbol of the PUSCHs, and the minimum PUSCH preparation delay. The minimum PUSCH preparation delay is the minimum amount of time that the UE requires to prepare a PUSCH for transmission after a UL grant for the PUSCH is received. The minimum preparation delay may vary depending on the capabilities and configuration of the UE. The UE can inform the network entity of the UE’s minimum preparation delay as part of the UE capability information transmitted at operation 402 of Figures 4 and 5, and at block 602 of Figure 6.

In some implementations, the network entity can determine the TBS based on one or more time resources of the uplink grants scheduling the PUSCHs.

Figure 11 illustrates one example for the scheduling offset determination. In the example shown in Figure 11, DCIs 204A and 204B have scheduled PUSCHs 202A and 202B, where DCI 204B is used to determine the TBS (e.g., TB size = x) . The last symbol of DCI 204B is at time t₀=0 of the graph 1100. In this example, PUSCH 202A is the first PUSCH to be transmitted, and the first symbol of PUSCH 202A is scheduled for transmission at time t₁. Offset 1104 is the timing offset representing the minimum PUSCH preparation delay. In this example, offset 1102 represents the minimum scheduling offset, and is based on the last symbol of DCI 204B, the first symbol of PUSCH 202A, and the minimum PUSCH preparation delay. In some aspects, the offset 1102 may be based on the last symbol of one of the DCIs 204A or 204B, the first symbol of one of the scheduled PUSCHs 202a or 202B, and the minimum PUSCH preparation delay.

Examples where the UE determines the TBS based on both or all of the scheduling DCIs will now be described. In some aspects, the UE may determine the TBS of scheduled PUSCHs based on both or all of the scheduling DCIs from CORESETs with different CORESET pool indexes.

In some other aspects, the UE may determine the TBS for each DCI. The UE may then determine the TBS based on the total TBS across the DCIs. In some other aspects, the UE may determine the TBS based on the minimum TBS across the DCIs. In some other aspects, the UE may determine the TBS based on the maximum TBS across the DCIs. In some other aspects, the UE may determine the TBS based on the average TBS across the DCIs.

In some other aspects, the UE may determine a target number of resource elements (REs) per layer or across layers for TBS determination based on the minimum, maximum, or average number of REs per layer or across layers for TBS determination across the DCIs. The UE may then determine a target spectrum efficiency (SE) per layer or across layers based on the minimum, maximum or average SEs per layer or across layers indicated by the MCS for each DCI. Then the UE may determine the TBS based on the target number of REs and target SE. In one example implementation, the UE may determine the TBS as follows:

where N_RE indicates the target number of REs and f_SE indicates the target SE.

Examples where the UE determines the TBS based on based on a configurable TBS determination scheme will now be described. In some aspects, the network entity may configure the UE to determine the TBS based on one of the scheduling DCIs or both/all scheduling DCIs. The network entity configures the UE by RRC signaling, a MAC CE, or DCI.

In one example implementation, the network entity utilizes an RRC parameter to configure the UE to determine the TBS based on one of the scheduling DCIs or both/all scheduling DCIs. In another example implementation, the network entity utilizes an RRC parameter to configure the UE to determine the TBS based on the first, second or both scheduling DCIs. In another example implementation, the network entity utilizes a DCI field to configure the UE to determine the TBS based on each DCI, where the first state may indicate the UE does not determine the TBS based on the DCI and the second state may indicate the UE determines the TBS based on the DCI. If the DCI field for both scheduling DCI indicates the second state, the UE determines the TBS based on both DCIs.

In some implementations, the UE may indicate whether the UE supports determining the TBS based on one DCI or both DCIs via UE capability information (see e.g., operations 402 of Figures 4 and 5 described above) .

Returning to Figure 5, at operation 514, the UE 110 transmits the first PUSCH and the second PUSCH having the common TB.

At operation 516, the network entity determines a common TB size (TBS) to decode the first PUSCH and the second PUSCH based on the respective first DCI and second DCI.

Figure 6 is a flow chart diagram illustrating example UE operations of a method 600 for HARQ process management for multi-DCI based PUSCH where the network entity may indicate the same HARQ process for multiple PUSCHs. The example operations of method 600 may be performed, for example, by UE 110 of Figures 1, 3, 4, and 5.

At block 602, and as described above with respect to Figures 4 and 5 operation 402, the UE may transmit or report to the network entity information regarding the UE’s capability (s) for supporting HARQ process management for multi-DCI based PUSCH. The UE capability information may include supported frequency bands, radio access technologies, maximum transmission power, maximum data rates, and network protocols. In some implementations, the UE may report UE capability information indicating whether the UE supports the same HARQ process for the PUSCHs scheduled by multiple DCIs that fully or partially overlap with each other in time domain.

At block 604, and as described above with respect to Figures 4 and 5 operation 404, the UE may receive a configuration of at least two CORESETs with different CORESET pool indexes by control signaling, e.g., RRCReconfiguration. The UE may also receive configuration information for other parameters for multi-DCI based PUSCH, e.g., more than one sounding reference signal (SRS) resource sets for codebook or non-codebook based transmission.

At block 606 and as described above with respect to Figure 5, operation 506, the UE may receive, from the network entity, RRC parameters for transmitting a common TB in different PUSCH transmissions scheduled by multi-DCI based PUSCH repetitions.

At block 608 and as described above with respect to Figure 5, operation 508, the UE may receive a first DCI including an uplink grant scheduling a first PUSCH for a first TRP associated with a first CORESET pool. The first DCI includes a first HARQ process number indicating a first HARQ process. In some implementations, the UE may receive the first DCI via RRC signaling. In some other implementations, the UE may receive the first DCI via PDCCH. The first DCI may optionally include parameters for multi-DCI based PUSCH repetitions of a common TB.

At block 610 and as described above with respect to Figure 5, operation 510, the UE may receive a second DCI including an uplink grant scheduling a second PUSCH for a second TRP associated with a second CORESET pool different from the first CORESET pool. The second DCI includes a second HARQ process number indicating a second HARQ process. In some implementations, the UE may receive the second DCI by RRC signaling. In some other implementations, the UE may receive the second DCI by PDCCH. The second DCI may optionally include parameters for multi-DCI based PUSCH repetitions of a common TB.

At decision block 612, the UE determines if the first DCI scheduling the first PUSCH and the second DCI scheduling the second PUSCH have specified respective first and second HARQ process numbers that refer to the same HARQ process. The HARQ process numbers themselves need not be the same to refer to the same HARQ process. For example, the HARQ numbers may be associated with different CORESET pools, but may refer configured such that HARQ process number x from a first CORESET pool refers to the same HARQ process a HARQ process number y from the second CORESET pool, where x is not equal to y.

If the UE determines that the first and second HARQ process numbers refer to different HARQ processes ( “NO” branch of decision block 612) , then at block 614, the UE determines a first TB for the first PUSCH and a second TB for the second PUSCH based on the first and second DCIs received to schedule the first and second PUSCH, respectively. In this case, the first and second TBs carry different payload data.

At block 616, the UE transmits the first PUSCH and the second PUSCH as scheduled by the first DCI and the second DCI.

If the UE determines that the first and second HARQ process numbers refer to the same HARQ process ( “YES” branch of decision block 612) , then at block 618, the UE determines a common TB for transmission by the first and second PUSCHs based on the first and second DCIs. Thus, in this case, the TBs transmitted via the first and second PUSCHs carry the same payload data.

At block 620, the UE transmits the first PUSCH and the second PUSCH to the network entity as scheduled by the first DCI and the second DCI.

Figure 7 is a flow chart diagram illustrating example network entity operations of a method for HARQ process management for multi-DCI based PUSCH. The example operations of method 700 may be performed by a network entity, for example, network entity 120 of Figures 1, 3, 4, and 5.

At block 702, and as described above with respect to Figures 4 and 5 operation 402, the network entity may receive, from the UE, information regarding the UE’s capability (s) for supporting HARQ process management for multi-DCI based PUSCH. The UE capability information may include supported frequency bands, radio access technologies, maximum transmission power, maximum data rates, and network protocols. In some implementations, the UE may report UE capability information indicating whether the UE supports the same HARQ process for the PUSCHs scheduled by multiple DCIs that fully or partially overlap with each other in time domain.

At block 704, and as described above with respect to Figures 4 and 5 operation 404, the network entity may configure at least two CORESETs with different CORESET pool indexes. In some aspects, the network entity may configure the CORESETs using control signaling, e.g., RRCReconfiguration. In some aspects, the network entity may configure other parameters for multi-DCI based PUSCH, e.g., more than one sounding reference signal (SRS) resource sets for codebook or non-codebook based transmission.

At block 706 and as described above with respect to Figure 5, operation 506, the network entity may optionally provide RRC parameters for transmitting a common TB in different PUSCH transmissions scheduled by multi-DCI based PUSCH repetitions.

At block 708 and as described above with respect to Figure 5, operation 508, the network entity may transmit a first DCI scheduling a first PUSCH for a first TRP associated with a first CORESET pool. The first DCI includes a first HARQ process number indicating a first HARQ process. In some implementations, the network entity may transmit the first DCI by RRC signaling. In some other implementations, the network entity may transmit the first DCI by PDCCH. The first DCI may optionally include parameters for multi-DCI based PUSCH repetitions of a common TB.

At block 710 and as described above with respect to Figure 5, operation 510, the network entity may transmit a second DCI scheduling a second PUSCH for a second TRP associated with a second CORESET pool different from the first CORESET pool. The second DCI includes a second HARQ process number indicating a second HARQ process. In some implementations, the network entity may transmit the second DCI by RRC signaling. In some other implementations, the network entity may transmit the second DCI by PDCCH. The second DCI may optionally include parameters for multi-DCI based PUSCH repetitions of a common TB.

At decision block 712, the network entity determines if the first DCI scheduling the first PUSCH and the second DCI scheduling the second PUSCH have specified respective first and second HARQ process numbers that refer to the same HARQ process. The HARQ process numbers themselves need not be the same to refer to the same HARQ process. For example, the HARQ numbers may be associated with different CORESET pools, but may refer configured such that HARQ process number x from a first CORESET pool refers to the same HARQ process a HARQ process number y from the second CORESET pool, where x is not equal to y.

If the network entity determines that the first and second HARQ process numbers refer to different HARQ processes ( “NO” branch of decision block 712) , then at block 714 the network entity determines first TB parameters based on the first DCI used to schedule the first PUSCH and second TB parameters based on the second DCI used to schedule the second PUSCH.

At block 716, the network entity receives the scheduled first and second PUSCHs from the UE. The network entity uses the first TB parameters to determine the payload data of the first TB and the second TB parameters to determine the payload data of the second TB.

If the network entity determines that the first and second HARQ process numbers refer to the same HARQ process ( “YES” branch of decision block 712) , then at block 718, the network entity determines that the first PUSCH and the second PUSCH are scheduled to transmit common TBs. That is, the payloads of the first TB and the second TB will be the same. The UE determines TB parameters based on first DCI and the second DCI.

At block 720, the network entity receives the first and second PUSCHs from the UE. The network entity determines the common payload data for at least one of the TBs based on the TB parameters of the PUSCH that transmitted the TB.

As discussed above with respect to Figure 4, operation 406, Figure 5, operation 506, Figure 6, block 606, and Figure 7, block 706, a network entity (e.g., network entity 120) may transmit configurations of candidate HARQ processes to a UE. These configurations may vary depending on whether UE complexity with respect to HARQ processing is to be reduced or if communications reliability is to be increased. Figures 8-10 discussed below illustrate example configurations of candidate HARQ processes for CORESET pools that may be utilized in various implementations. The examples shown in Figures 8-10 assume that eight HARQ processes have been configured for multi-DCI based PUSCH. However, in other examples, the number of HARQ processes configured for multi-DCI based PUSCH may be less than eight or greater than eight.

Figure 8 is a conceptual diagram illustrating an example per-TRP candidate HARQ process configuration. The per-TRP candidate HARQ process shown in Figure 8 may be used, for example, to reduce UE complexity for HARQ processing. In this example, the network entity (e.g., network entity 120) refrains from indicating a common HARQ process, i.e., the same HARQ process number, when scheduling and/or activating PUSCHs that overlap with each other fully or partially in the time domain in a bandwidth part. In such examples, the network entity transmits DCIs from CORESETs with different CORESET pool index values.

In some implementations, the network entity refrains from configuring or indicating a common HARQ process, i.e., the same HARQ process number, for DCIs and/or uplink grants configured by RRC signaling when scheduling, configuring, or activating PUSCHs that overlap with one another either fully or partially in time domain in a bandwidth part.

In the same or other implementations, the network entity may configure or indicate a common HARQ process, e.g., the same HARQ process number, for DCIs and/or uplink grants configured by RRC signaling when scheduling, configuring, or activating PUSCHs which do not overlap with each other in the time domain in a bandwidth part.

Thus, the network entity may refrain from configuring or scheduling PUSCHs in a bandwidth part with a common HARQ process number for various combinations of PUSCH types, including at least one of the following combinations:

● Dynamic-grant based PUSCH (DG-PUSCH) + DG-PUSCH

● DG-PUSCH + Configured-grant based PUSCH (CG-PUSCH)

● CG-PUSCH + CG-PUSCH

For DG-PUSCH, the network entity may transmit the uplink grant for a PUSCH by PDCCH. For Type1 CG-PUSCH, the network entity may configure the uplink grant for PUSCH by RRC signaling. For Type2 CG-PUSCH, the network entity may transmit the uplink grant for an activated semi-persistent-scheduling (SPS) based PUSCH by PDCCH.

In some aspects, the network entity may configure the candidate HARQ processes for each TRP, e.g., CORESET pool, by RRC signaling, MAC CE, or DCI. In one example, the network entity may configure two lists of candidate HARQ processes, where each list corresponds to one TRP, e.g., one CORESET pool. In another example, the network entity may configure a first number of candidate HARQ processes N₁ and a second number of candidate HARQ processes N₂.Then the HARQ process 0, 1, …, N₁-1 are for the first TRP and the HARQ process N₁, N₁+1, …, N₁+N₂-1 are for the second TRP.

In some aspects, the network entity may configure common candidate HARQ process lists for DCI format 0_1 and DCI format 0_2. In some other aspects, the network entity may configure separate candidate HARQ process lists for DCI format 0_1 and DCI format 0_2. Then in the corresponding DCI, the network entity indicates the HARQ process index within the candidate HARQ process for the corresponding TRP.

In some aspects, the network entity refrains from configuring the same HARQ process in the HARQ process lists for different TRPs. Thus, the network entity configures orthogonal HARQ process lists for the TRPs.

In some aspects, the UE may implement the multi-DCI based PUSCH by implementing the signals associated with one CORESET pool for one component carrier (CC) . For this type of implementation, the network entity configures the candidate HARQ processes such that the candidate HARQ processes associated with each CORESET pool are orthogonal to one another. Thus, the DCIs from different CORESET pools do not schedule a PUSCH using the same HARQ process as a DCI used to schedule different PUSCH, thereby avoiding any ambiguity regarding which HARQ process is to be used for a TB.

In the example of Figure 8, the UE may be configured with eight HARQ processes 800 that are associated with one CORESET pool for one CC (e.g., CC1) . For example, the network entity can configure the first four HARQ processes (e.g., HARQ processes associated with HARQ process numbers 1-4) in a HARQ process list 802A for a first TRP (e.g., TRP 122A of Figure 1) . The network entity can configure the second four HARQ processes (e.g., HARQ processes associated with HARQ process numbers 5-8) in a HARQ process list 802B for a second TRP (e.g., TRP 122B of Figure 1) . In this example, the HARQ process numbers 1-8 associated with the HARQ processes 800 each indicate a different HARQ process. As a result, the HARQ processes in list 802A for the first TRP are orthogonal to the HARQ processes in list 802B for the second TRP.

In the example of Figure 8, a network entity may schedule a first PUSCH for a first TRP with a DCI 804A indicating a first HARQ process number 0. The process number in the DCI 804A may be used as an index into the candidate HARQ process list 802A, which indicates HARQ process 1 to be the actual HARQ process that will be used. Similarly, the network entity may schedule a second PUSCH for a second TRP with a DCI 804B indicating a second HARQ process number 2. The process number may be used as an index into candidate HARQ process list 802A, which indicates HARQ process 7 as the actual HARQ process that will be used.

In the example shown in Figure 8, HARQ process lists 802A and 802B have an equal number of HARQ processes (e.g., four HARQ processes) . However, in other examples, the number of HARQ processes in HARQ process list 802A may be different from the number of HARQ processes in HARQ process list 802B.

Figures 9 and 10 illustrate examples of per-TRP HARQ process management. Like the example discussed above with respect to Figure 8, the examples shown in Figures 9 and 10 may be used, for instance, to reduce UE complexity for HARQ processing. In the examples of Figures 9 and 10, the UE determines that HARQ processes having the same HARQ process number, but for different TRPs, e.g., different CORESET pools, are in fact different HARQ processes. Thus, the UE maintains different HARQ processes for the HARQ process with the same HARQ process number when the HARQ processes are for different TRPs. In some implementations, the network entity may configure whether the UE maintains the HARQ process for different TRPs separately or not by RRC signaling, MAC CE, or DCI.

In some implementations, the network entity may configure a common number of HARQ processes for each TRP for DCI format 0_1 and DCI format 0_2 separately. In some other implementations, the network entity may configure separate number of HARQ processes for each TRP for DCI format 0_1 and DCI format 0_2 separately.

Figure 9 is a conceptual diagram illustrating an example TRP-specific HARQ entity. In the example shown in Figure 9, the UE may maintain one HARQ entity per TRP for a serving cell, where each HARQ entity includes a number of parallel HARQ processes for the TRP. For example, HARQ entity 1 for a first TRP may have an associated HARQ process list 902A having HARQ process numbers 1-4. HARQ entity 2 for a second TRP may have an associated HARQ processes list 902B also having HARQ process numbers 1-4. DCI 804A used to schedule a first PUSCH is configured with a HARQ process number 0, which may be used as an index into HARQ process list 902A, thus referring to HARQ process 1 of HARQ entity 1. Similarly, DCI 804B used to schedule a second PUSCH is configured with a HARQ process number 2, which may be used as an index into HARQ process list 902B, thus referring to HARQ process 3 of HARQ entity 2.

Figure 10 is a conceptual diagram illustrating an example HARQ process associated with a HARQ process ID and TRP ID. In the example shown in Figure 10, the UE may maintain one HARQ entity across TRPs, where the HARQ entity includes a number of parallel HARQ processes for a serving cell, and each HARQ process is associated with a HARQ process number and a TRP index, e.g., CORESET pool index. Thus, in the example shown in Figure 10, HARQ processes 1002A of HARQ entity 1 are associated with a first TRP, and HARQ processes 1002B of HARQ entity 1 are associated with a second TRP. DCI 804A used to schedule a first PUSCH is configured with a HARQ process number 0, which may be used as an index into HARQ processes 1002A, thus referring to HARQ process 1 of HARQ entity 1. Similarly, DCI 804B used to schedule a second PUSCH is configured with a HARQ process number 2, which may be used as an index into HARQ processes 1002B, thus referring to HARQ process 7 of HARQ entity 1.

As discussed above, in some aspects, the UE and network entity may cooperate to enhance reliability of wireless communications using HARQ process management. In some aspects, the network entity may indicate a common HARQ process and common NDI toggling for a first PUSCH and a second PUSCH. For example, the network entity may specify the same HARQ process by specifying HARQ process numbers that refer to the same HARQ process in the respective DCIs scheduling the PUSCHs. Further, the network entity may indicate a common NDI for the first PUSCH and the second PUSCH. For example, the network entity may specify the same NDI toggling indication in the DCIs scheduling the first PUSCH and the second PUSCH. In some aspects, the DCIs may schedule the PUSCHs such that the PUSCHs overlap with each other fully or partially in time domain in a bandwidth part. In some aspects, the PUSCHs scheduled by the DCIs may not overlap with each other. Thus, when scheduling the PUSCHs with a common HARQ process, the network entity may configure or indicate the PUSCHs with the common state of initial transmission and common state of retransmission. Accordingly, the network entity may provide one of the following indications:

● Initial transmission in a first DCI and initial transmission in a second DCI

● Retransmission in a first DCI and retransmission in a second DCI

In some aspects, if the UE receives a first DCI and a second DCI that both indicate initial transmission, the UE determines the DCIs indicate the initial transmission for the same TB. In some other aspects, if the UE receives a first DCI and a second DCI that both indicate initial transmission, whether the UE determines the DCIs indicate the initial transmission for the same TB or different TBs may be configured by the network entity via RRC signaling, a MAC CE, or DCI. For example, the network entity may configure whether to enable the multi-DCI based PUSCH repetitions by RRC signaling. If multi-DCI based PUSCH repetitions are enabled, the UE may the DCIs indicate the initial transmission for the same TB. If multi-DCI based PUSCH repetitions are not enabled, the UE may determine that the DCIs indicate the initial transmission for different TBs.

In some aspects, the network entity may indicate a common HARQ process and different NDIs for initial transmission. For example, the network entity may specify the same HARQ process by specifying HARQ process numbers that refer to the same HARQ process in the first and second DCIs scheduling the first and second PUSCHs, and may indicate different NDIs for the first and second PUSCHs. The first and second PUSCHs may overlap with each other fully or partially in time domain in a bandwidth part or may not overlap with one another. The network entity may provide one of the following indications:

● Initial transmission in a first DCI and retransmission in a second DCI

● Retransmission in a first DCI and initial transmission in a second DCI

● Retransmission in a first DCI and retransmission in a second DCI

In some aspects, in the case where the network entity miss-detects a DCI indicating initial transmission, the network entity may transmit a DCI indicating whether the retransmission is for a new TB or not. In one example, the network entity may provide the indication by the DCI. If the UE only receives the DCI with retransmission for a new TB, in some aspects, the UE may refrain from transmitting the PUSCH. In some other aspects, the UE may transmit the PUSCH based on a new TB, and determine that the previous transmission for the same HARQ process was correctly decoded by the network entity.

In some other aspects, if the UE only receives a DCI scheduling a retransmission, the UE retransmits the TB in previous transmission for the same HARQ process. In some implementations, the UE may further report whether it is a TB for retransmission or initial transmission. In some aspects, the UE may provide the report by PUSCH scramble sequence. The network entity may configure different scramble IDs for initial transmission and retransmission by RRC signaling, a MAC CE, or DCI. The UE may select a corresponding scramble ID to transmit the PUSCH. In some other implementations, the UE may provide the report by demodulation reference signal (DMRS) sequence. The network entity may configure a different DMRS sequence or different DMRS scramble IDs for initial transmission and retransmission by RRC signaling, a MAC CE, or DCI. The UE may select corresponding DMRS sequences to transmit the DMRS.

In some aspects, if the UE receives a first DCI indicating initial transmission and a second DCI indicating retransmission for the same HARQ process, in some aspects, the UE may transmit a same new TB for the first and second PUSCHs. In some other aspects, the UE retransmits the same TB that was previously transmitted for the HARQ processes for the PUSCHs.

In some aspects, if the UE receives first and second DCIs that both indicate retransmission for the same HARQ process, the UE retransmits the same TB as was previously transmitted for the HARQ processes for the PUSCHs.

It is noted that throughout this disclosure, an expression of “X/Y” may include meaning of “X or Y” . It is noted that throughout this disclosure, an expression of “X/Y” may include meaning of “X and Y” . It is noted that throughout this disclosure, an expression of “X/Y” may include meaning of “X and/or Y” . It is noted that throughout this disclosure, an expression of “ (A) B”or “B (A) ” may include concept of “only B” . It is noted that throughout this disclosure, an expression of “ (A) B” or “B (A) ” may include concept of “A+B” or “B+A” .

It is noted that some or all of the foregoing or the following implementations can be jointly combined or formed to be a new or another one implementation.

It is noted that the foregoing or the following techniques can be used to solve at least (but not limited to) the issue (s) or scenario (s) mentioned in this disclosure.

The following additional considerations may apply to the foregoing and the following discussions.

It is noted that any two or more than two of the foregoing or the following paragraphs, (sub) -bullets, points, actions, or claims described in each method/technique/implementation may be combined logically, reasonably, and properly to form a specific method.

It is noted that any sentence, paragraph, (sub) -bullet, point, action, or claim described in each of the foregoing or the following technique (s) /implementation (s) /concept (s) may be implemented independently and separately to form a specific method. Dependency, such as “based on”, “more specifically” , “where” or etc., in technique (s) /implementation (s) /concept (s) mentioned in this disclosure is just one possible implementation which would not restrict the specific method.

Certain techniques are described in this disclosure as including logic or a number of components or modules. Modules may be software modules (such as code stored on non-transitory machine-readable medium) or hardware modules. A hardware module is a tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. A hardware module can comprise dedicated circuitry or logic that is permanently configured (such as a special-purpose processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC) ) to perform certain operations. A hardware module may also comprise programmable logic or circuitry (for example, as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. The decision to implement a hardware module in dedicated and permanently configured circuitry, or in temporarily configured circuitry (for example, configured by software) may be driven by cost and time considerations.

Figures 1, 2A, 2B, and 3-11 and the operations described herein are examples meant to aid in understanding example implementations and should not be used to limit the potential implementations or limit the scope of the claims. Some implementations might include additional operations, fewer operations, operations in parallel or in a different order, and some operations differently.

As used herein, the terms “component” and “module” are intended to be broadly construed as hardware, firmware, or a combination of hardware and software. As used herein, a processor is implemented in hardware, firmware, or a combination of hardware and software. As used herein, the phrase “based on” is intended to be broadly construed to mean “based at least in part on. ”

Some aspects are described herein in connection with thresholds. As used herein, satisfying a threshold may refer to a value being greater than the threshold, greater than or equal to the threshold, less than the threshold, less than or equal to the threshold, equal to the threshold, not equal to the threshold, or the like.

As used herein, a phrase referring to “at least one of” or “one or more of” a list of items refers to any combination of those items, including single members. For example, “at least one of: a, b, or c” is intended to cover the possibilities of: a only, b only, c only, a combination of a and b, a combination of a and c, a combination of b and c, and a combination of a and b and c.

In this disclosure, the term "can" indicates a capability, or alternatively indicates a possible implementation option. The term "may" indicates a permission or a possible implementation option.

The various illustrative components, logic, logical blocks, modules, circuits, operations and algorithm processes described in connection with the implementations disclosed herein may be implemented as electronic hardware, firmware, software, or combinations of hardware, firmware or software, including the structures disclosed in this specification and the structural equivalents thereof. The interchangeability of hardware, firmware and software has been described generally, in terms of functionality, and illustrated in the various illustrative components, blocks, modules, circuits and processes described above. Whether such functionality is implemented in hardware, firmware or software depends upon the particular application and design constraints imposed on the overall system.

The hardware and data processing apparatus used to implement the various illustrative components, logics, logical blocks, modules and circuits described in connection with the aspects disclosed herein may be implemented or performed with a general purpose single-or multi-chip processor, a digital signal processor (DSP) , an application specific integrated circuit (ASIC) , a field programmable gate array (FPGA) or other programmable logic device (PLD) , discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, or any conventional processor, controller, microcontroller, or state machine. A processor also may be implemented as a combination of computing devices, for example, a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. In some implementations, particular processes, operations and methods may be performed by circuitry that is specific to a given function.

As described above, in some aspects implementations of the subject matter described in this specification can be implemented as software. For example, various functions of components disclosed herein, or various blocks or steps of a method, operation, process or algorithm disclosed herein can be implemented as one or more modules of one or more computer programs. Such computer programs can include non-transitory processor-or computer-executable instructions encoded on one or more tangible processor-or computer-readable storage media for execution by, or to control the operation of, data processing apparatus including the components of the devices described herein. By way of example, and not limitation, such storage media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that may be used to store program code in the form of instructions or data structures. Combinations of the above should also be included within the scope of storage media. When implemented in software, the techniques can be provided as part of the operating system, a library used by multiple applications, a particular software application, etc. The software can be executed by one or more general-purpose processors or one or more special-purpose processors.

As used herein, the terms “user device” , “user equipment” (for example, UE 110) , “wireless communication device” , “mobile communication device” , “communication device” , or “mobile device” refer to any one or all of cellular telephones, smartphones, portable computing devices, personal or mobile multi-media players, laptop computers, tablet computers, smartbooks, Internet-of-Things (IoT) devices, palm-top computers, wireless electronic mail receivers, multimedia Internet enabled cellular telephones, wireless gaming controllers, display sub-systems, driver assistance systems, vehicle controllers, vehicle system controllers, vehicle communication system, infotainment systems, vehicle telematics systems or subsystems, vehicle display systems or subsystems, vehicle data controllers, point-of-sale (POS) terminals, health monitoring devices, drones, cameras, media-streaming dongles or another personal media devices, wearable devices such as smartwatches, wireless hotspots, femtocells, broadband routers or other types of routers, and similar electronic devices which include a programmable processor and memory and circuitry configured to perform operations as described herein. Further, the user device in some cases may be embedded in an electronic system such as the head unit of a vehicle or an advanced driver assistance system (ADAS) . Still further, a mobile-internet device (MID) . Depending on the type, the user device can include one or more general-purpose processors, a computer-readable memory, a user interface, one or more network interfaces, one or more sensors, etc.

Various modifications to the implementations described in this disclosure may be readily apparent to persons having ordinary skill in the art, and the generic principles defined herein may be applied to other implementations without departing from the spirit or scope of this disclosure. Thus, the claims are not intended to be limited to the implementations shown herein but are to be accorded the widest scope consistent with this disclosure, the principles and the novel features disclosed herein.

Additionally, various features that are described in this specification in the context of separate implementations also can be implemented in combination in a single implementation. Conversely, various features that are described in the context of a single implementation also can be implemented in multiple implementations separately or in any suitable subcombination. As such, although features may be described above as acting in particular combinations, and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. Further, the drawings may schematically depict one or more example processes in the form of a flowchart or flow diagram. However, other operations that are not depicted can be incorporated in the example processes that are schematically illustrated. For example, one or more additional operations can be performed before, after, simultaneously, or between any of the illustrated operations. In some circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the implementations described above should not be understood as requiring such separation in all implementations, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products. Additionally, other implementations are within the scope of the following claims. In some cases, the actions recited in the claims can be performed in a different order and still achieve desirable results.

The foregoing disclosure provides illustration and description but is not intended to be exhaustive or to limit the aspects to the precise form disclosed. Modifications and variations may be made in light of the above disclosure or may be acquired from practice of the aspects. While the aspects of the disclosure have been described in terms of various examples, any combination of aspects from any of the examples is also within the scope of the disclosure. The examples in this disclosure are provided for pedagogical purposes.

Claims

A method for wireless communications by a network entity, comprising:

transmitting (404, 704) , to a user equipment (UE) (110) , a configuration of a plurality of control resource set (CORESET) pool indexes, the plurality of CORESET pool indexes including a first CORESET pool index associated with a first CORESET pool and a second CORESET pool index associated with a second CORESET pool;

transmitting (408, 508, 708) , to the UE, a first uplink grant scheduling a first physical uplink shared channel (PUSCH) (202A) , the first uplink grant being associated with the first CORESET pool index and a first hybrid automatic repeat request (HARQ) process number;

transmitting (410, 510, 710) , to the UE, a second uplink grant scheduling a second PUSCH (202B) , the second uplink grant being associated with the second CORESET pool index and a second HARQ process number; and

receiving (414, 514, 716, 720) , from the UE, the first PUSCH and the second PUSCH, the first PUSCH having a first transport block (TB) and the second PUSCH having a second TB, the first TB and the second TB being generated based on whether or not the first HARQ process number and the second HARQ process number indicate a same HARQ process.
The method of claim 1, further comprising calculating (416) a TB size (TBS) of either or both the first TB and the second TB based on at least one of:

either or both the first uplink grant and the second uplink grant;

a time resource of the first uplink grant or the second uplink grant;

a total TBS of the first uplink grant and the second uplink grant;

a minimum TBS of the first uplink grant and the second uplink grant;

a maximum TBS of the first uplink grant and the second uplink grant;

an average TBS for of the first uplink grant and the second uplink grant; or

a number of resource elements and modulation and coding scheme (MCS) for the first uplink grant and the second uplink grant.
The method of any of claims 1-2, further comprising transmitting (406, 706) , to the UE (110) , configuration information, the configuration information including at least one of:

a first configuration of a first set of one or more candidate HARQ process numbers for the first CORESET pool and a second set of one or more candidate HARQ process numbers for the second CORESET pool;

a second configuration enabling per-CORESET pool HARQ process management;

a third configuration indicating which of the first uplink grant or the second uplink grant is used for TBS determination;

a fourth configuration indicating whether to determine a TBS based on one or both of the first uplink grant and the second uplink grant; or

a fifth configuration indicating whether an uplink grant indicates a retransmission for a new TB.
The method of claim 3, wherein a first set of one or more HARQ processes indicated by the first set of one or more candidate HARQ process numbers (802A, 902A) is orthogonal to a second set of one or more HARQ processes indicated by the second set of one or more candidate HARQ process numbers (802B, 902B) .
The method of any of claims 1-4, further comprising:

indicating the first HARQ process number in a first downlink control information (DCI) (204A) corresponding to the first uplink grant and the second HARQ process number in a second DCI (204B) corresponding to the second uplink grant,

wherein the first HARQ process number is based on a first set of one or more candidate HARQ processes associated with the first CORESET pool and the second HARQ process number is based on a second set of one or more candidate HARQ processes associated with the second CORESET pool.
The method of any of claims 1-5, further comprising determining whether a received PUSCH is for a new TB or a previous TB of a previous transmission based on at least one of:

the received PUSCH; or

a demodulation reference signal (DMRS) sequence.
The method of any of claims 1-6, further comprising:

selecting a first HARQ process based on the first HARQ process number and the first CORESET pool index; and

selecting a second HARQ process based on the second HARQ process number and the second CORESET pool index.
The method of any of claims 1-7, further comprising scheduling the first PUSCH and the second PUSCH to fully or partially overlap with each other in a time domain.
A method for wireless communications by a user equipment (UE) , comprising:

receiving (404, 604) , from a network entity (120) , a configuration of at least two control resource set (CORESET) pool indexes, the at least two CORESET pool indexes including a first CORESET pool index associated with a first CORESET pool and a second CORESET pool index associated with a second CORESET pool;

receiving (408, 508, 608) , from the network entity, a first uplink grant scheduling a first physical uplink shared channel (PUSCH) , the first uplink grant being associated with the first CORESET pool index and a first hybrid automatic repeat request (HARQ) process number;

receiving (410, 510, 610) , from the network entity, a second uplink grant scheduling a second PUSCH, the second uplink grant being associated with the second CORESET pool index and a second HARQ process number;

generating (412, 512, 614, 618) a first transport block (TB) and a second TB based on whether or not the first HARQ process number and the second HARQ process number indicate a same HARQ process; and

transmitting (414, 514, 616, 620) , to the network entity, the first PUSCH and the second PUSCH, the first PUSCH having the first TB (321) and the second PUSCH having the second TB (321) .
The method of claim 9, further comprising determining a PUSCH scrambling ID based on whether the first PUSCH and the second PUSCH are for a new TB associated with the indicated HARQ process or a previous TB in a previous transmission associated with the indicated HARQ process.
The method of any of claims 9-10, further comprising selecting a demodulation reference signal (DMRS) sequence based on whether the first PUSCH and the second PUSCH are for a new TB or a previous TB of a previous transmission of the indicated HARQ process.
The method of any of claims 9-11, further comprising transmitting (402, 602) , to the

network entity (120) , UE capability information including at least one of:

a first indicator indicating support for the first PUSCH and the second PUSCH indicating the same HARQ process; or

a second indicator indicating support for determining a transport block size based on either or both the first uplink grant or the second uplink grant.
The method of any of claims 9-12, further comprising determining at least one of:

a first HARQ process based on the first HARQ process number associated with the first uplink grant and a first set of one or more candidate HARQ processes for the first CORESET pool, or

a second HARQ process based on the second HARQ process number associated with the second uplink grant and a second set of one or more candidate HARQ processes for the second CORESET pool.
The method of any of claims 9-13, wherein generating the first TB and the second TB comprises at least one of:

generating (614) the first TB based on a first downlink control information (DCI) (320) associated with the first uplink grant and generating the second TB based on a second DCI (320) associated with the second uplink grant when the first HARQ process number and the second HARQ process number do not indicate the same HARQ process; or

generating (618) a common TB for the first TB and the second TB when the first HARQ process number and the second HARQ process number indicate the same HARQ process.
The method of any of claims 9-14, wherein transmitting the first PUSCH and the second PUSCH comprises at least one of:

transmitting a first new TB in the first PUSCH and a second new TB in the second PUSCH when the first uplink grant indicates initial transmission or the second uplink grant indicates initial transmission and the first HARQ process number and the second HARQ process number indicate the same HARQ process; or

retransmitting, in the first PUSCH and the second PUSCH, a previously generated TB associated with the same HARQ process indicated by the first HARQ process number and the second HARQ process number when both the first uplink grant and the second uplink grant indicate retransmission and the first HARQ process number and the second HARQ process number indicate the same HARQ process.
An apparatus, comprising:

a communication unit; and

a processing system configured to control the communication unit to implement any one of the methods of claims 1-15.