EP4725147A1

EP4725147A1 - Methods and apparatuses for robust uplink control information multiplexing on multi-downlink control information based physical uplink shared channels

Info

Publication number: EP4725147A1
Application number: EP23748943.0A
Authority: EP
Inventors: Jia-Hong Liou; Yushu Zhang
Original assignee: Google LLC
Current assignee: Google LLC
Priority date: 2023-07-07
Filing date: 2023-07-07
Publication date: 2026-04-15
Also published as: WO2025010534A1; CN121488423A

Abstract

A user equipment (UE), receives (1215), from a network entity (104), a first indication that schedules a first physical uplink shared channel (PUSCH) associated with a first control resource set (CORESET) pool, the first PUSCH overlapping in time with a physical uplink control channel (PUCCH) associated with a second CORESET pool different from the first CORESET pool and transmits (1235), to the network entity (104), an uplink communication associated with an uplink control information (UCI) multiplexing scheme based on the first PUSCH overlapping in time with the PUCCH, without obtaining a second indication that schedules a second PUSCH associated with the second CORESET pool, the second PUSCH overlapping in time with the PUCCH.

Description

METHODS AND APPARATUSES FOR ROBUST UPLINK CONTROL INFORMATION MULTIPLEXING ON MULTI-DOWNLINK CONTROL INFORMATION BASED PHYSICAL UPLINK SHARED CHANNELS

TECHNICAL FIELD

The present disclosure relates generally to wireless communication, and more particularly, to robust uplink control information multiplexing on multi-downlink control information based physical uplink shared channels.

BACKGROUND

The Third Generation Partnership Project (3GPP) specifies a radio interface referred to as fifth generation (5G) new radio (NR) (5G NR) . An architecture for a 5G NR wireless communication system includes a 5G core (5GC) network, a 5G radio access network (5G-RAN) , a user equipment (UE) , etc. The 5G NR architecture seeks to provide increased data rates, decreased latency, and/or increased capacity compared to prior generation cellular communication systems.
Wireless communication systems, in general, may be configured to provide various telecommunication services (e.g., telephony, video, data, messaging, broadcasts, etc. ) based on multiple-access technologies, such as orthogonal frequency division multiple access (OFDMA) technologies, that support communication with multiple UEs. Improvements in mobile broadband continue the progression of such wireless communication technologies. For example, a UE may determine an error case where a scheduled physical uplink control channel (PUCCH) overlaps in time with a first scheduled physical uplink shared channel (PUSCH) associated with different control resource set (CORESET) pools and does not overlap in time with a second scheduled PUSCH associated with the same CORESET pool, due to decoding failure of downlink control information (DCI) scheduling the second PUSCH. In response, the UE may unnecessarily transmit a radio resource control (RRC) reconfiguration request to a network entity.
BRIEF SUMMARY
The following presents a simplified summary of one or more aspects in order to provide a basic understanding of such aspects. This summary is not an extensive overview of all contemplated aspects. This summary neither identifies key or critical elements of all aspects nor delineates the scope of any or all aspects. Its sole purpose is to present some concepts of one or more aspects in a simplified form as a prelude to the more detailed description that is presented later.
In fifth generation (5G) advanced and sixth generation (6G) wireless technology, a network entity may schedule two or more PUSCHs using two or more different CORESET pools (e.g., coresetPoolIndex values) . Each of the CORESET pools may be associated with a different transmission/reception point (TRP) . In some aspects, the network entity schedules two PUSCHs using two separate DCI messages (may be referred to as multi-DCI based PUSCH transmission) . However, in some instances, the UE may fail to receive or properly decode one of the DCIs. The UE may be unaware of whether the failure to receive or properly decode one of the DCIs is a result of a scheduling error by the network entity, interference in the channel, a decoding error, or some other cause. For example, the UE may determine an error case where a scheduled PUCCH overlaps in time with a scheduled PUSCH associated with different CORESET pools and does not overlap in time with a second scheduled PUSCH associated with the same CORESET pool, due to decoding failure of one of DCI scheduling the second PUSCH. In response, the UE may unnecessarily transmit a RRC reconfiguration request to the network entity.
Methods of the present disclosure avoid unnecessary RRC reconfiguration procedures which do not result from the network entity’s scheduling error but, rather, result from the DCI decoding failure. The unnecessary RRC reconfiguration procedures increase the latency and system overhead of the network. Therefore, methods of the present disclosure improve the network performance by avoiding the unnecessary RRC reconfiguration procedure caused by the DCI decoding failure at the UE.
In some aspects, the network entity may indicate to the UE how many DCIs scheduling PUSCHs are being transmitted to the UE. In this way, the UE knows whether the UE has failed to receive and/or properly decode all the DCIs transmitted by the network entity. For example, when the network entity transmits a first DCI and a second DCI to the UE, the first DCI may indicate that a second DCI is transmitted to the UE and the second DCI may indicate that a first DCI is transmitted to the UE. Additionally or alternatively, the network entity may transmit a dedicated DCI or a medium access control-control element (MAC-CE) including a schedule for a plurality of slots for the PUSCHs scheduled in different CORESET pools.
The UE determines an uplink communication to transmit to the network entity. The uplink communication includes a PUCCH only, a PUSCH only with or without uplink control information (UCI) multiplexing, the PUCCH and the PUSCH without UCI multiplexing, or the PUCCH and the PUSCH multiplexed with the UCI. The UE determines the uplink communication based on a configuration received from the network entity, content of the UCI, content of the PUSCH, and/or a hybrid automatic repeat request (HARQ) configuration. Additionally or alternatively, the UE may receive a configured grant (CG) for a PUSCH and transmit the CG PUSCH multiplexed with UCI.
The UE optionally transmits a capability indicator to the network entity indicating support for at least one of UCI multiplexing with the scheduled PUSCH, joint HARQ feedback mode, separate HARQ feedback mode, or scheduling a PUCCH overlapping in time with a PUSCH.
According to some aspects, a UE receives, from a network entity, a first indication that schedules a first PUSCH associated with a first CORESET pool, the first PUSCH overlapping in time with a PUCCH associated with a second CORESET pool different from the first CORESET pool. The UE transmits, to the network entity, an uplink communication associated with a UCI multiplexing scheme based on the first PUSCH overlapping in time with the PUCCH, without obtaining a second indication that schedules a second PUSCH associated with the second CORESET pool, the second PUSCH overlapping in time with the PUCCH.
According to some aspects, a network entity transmits, to a UE, a first indication that schedules a first PUSCH associated with a first CORESET pool, the first PUSCH overlapping in time with a PUCCH associated with a second CORESET pool different from the first CORESET pool. The network entity transmits, to the UE, a second indication that schedules a second PUSCH associated with the second CORESET pool, the second PUSCH overlapping in time with the PUCCH. The network entity receives, from the UE, an uplink communication associated with a UCI multiplexing scheme based on the first PUSCH overlapping in time with the PUCCH.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a diagram of a wireless communications system that includes a plurality of user equipments (UEs) and network entities in communication over one or more cells according to an embodiment.
FIGS. 2A and 2B are diagrams illustrating a UCI multiplexing scheme according to an embodiment.
FIGS. 3A and 3B are diagrams illustrating another UCI multiplexing scheme for multi-DCI based PUSCH transmission according to another embodiment.
FIGS. 4A and 4B are diagrams illustrating another UCI multiplexing scheme for multi-DCI based PUSCH transmission according to another embodiment.
FIGS. 5A and 5B are diagrams illustrating an example DCI decoding failure for multi-DCI based PUSCH transmission according to an embodiment.
FIGS. 6A and 6B are diagrams illustrating another UCI multiplexing scheme for multi-DCI based PUSCH transmission according to some embodiments.
FIGS. 7A and 7B are diagrams illustrating a PUSCH transmission without UCI according to some embodiments.
FIGS. 8A and 8B are diagrams illustrating a PUCCH transmission according to an embodiment.
FIGS. 9A and 9B are diagrams illustrating a PUSCH transmission with UCI according to another embodiment.
FIGS. 10A and 10B are diagrams illustrating a PUCCH and PUSCH transmission without UCI according to an embodiment.
FIGS. 11A and 11B are diagrams illustrating a PUCCH and PUSCH transmission with UCI according to another embodiment.
FIG. 12 is a signaling diagram illustrating a UCI multiplexing scheme for multi-DCI based PUSCH transmission according to an embodiment.
FIG. 13 is a flowchart of a method of a UCI multiplexing scheme for multi-DCI based PUSCH transmission at a UE according to an embodiment.
FIG. 14 is a flowchart of a method of a UCI multiplexing scheme for multi-DCI based PUSCH transmission at a network entity according to an embodiment.
FIG. 15 is a diagram illustrating a hardware implementation for an example UE apparatus according to some embodiments.
FIG. 16 is a diagram illustrating a hardware implementation for one or more example network entities according to other embodiments.

DETAILED DESCRIPTION

FIG. 1 illustrates a diagram 100 of a wireless communications system associated with a plurality of cells 190 according to an embodiment. The wireless communications system includes user equipments (UEs) 102 and base stations/network entities 104. Some base stations may include an aggregated base station architecture and other base stations may include a disaggregated base station architecture. The aggregated base station architecture utilizes a radio protocol stack that is physically or logically integrated within a single radio access network (RAN) node. A disaggregated base station architecture utilizes a protocol stack that is physically or logically distributed among two or more units (e.g., radio unit (RU) 106, distributed unit (DU) 108, central unit (CU) 110) . For example, a CU 110 is implemented within a RAN node, and one or more DUs 108 may be co-located with the CU 110, or alternatively, may be geographically or virtually distributed throughout one or multiple other RAN nodes. The DUs 108 may be implemented to communicate with one or more RUs 106. Any of the RU 106, the DU 108 and the CU 110 can be implemented as virtual units, such as a virtual radio unit (VRU) , a virtual distributed unit (VDU) , or a virtual central unit (VCU) . The base station/network entity 104 (e.g., an aggregated base station or disaggregated units of the base station, such as the RU 106 or the DU 108) , may be referred to as a transmission reception point (TRP) .
Operations of the base station 104 and/or network designs may be based on aggregation characteristics of base station functionality. For example, disaggregated base station architectures are utilized in an integrated access backhaul (IAB) network, an open-radio access network (O-RAN) network, or a virtualized radio access network (vRAN) , which may also be referred to a cloud radio access network (C-RAN) . For example, the base stations 104d/104e and/or the RUs 106a-106d may communicate with the UEs 102a-102d and 102s via one or more radio frequency (RF) access links based on a Uu interface. In examples, multiple RUs 106 and/or base stations 104 may simultaneously serve the UEs 102, such as by intra-cell and/or inter-cell access links between the UEs 102 and the RUs 106/base stations 104.
The RU 106, the DU 108, and the CU 110 may include (or may be coupled to) one or more interfaces configured to transmit or receive information/signals via a wired or wireless transmission medium. The CU 110 executes the aspects of the PDCP layer. The DU 108 executes the aspects of the RLC layer. For example, a wired interface can be configured to transmit or receive the information/signals over a wired transmission medium, such as via the fronthaul link 160 between the RU 106d and the baseband unit (BBU) 112 of the base station 104d associated with the cell 190d. The BBU 112 includes a DU 108 and a CU 110, which may also have a wired interface (e.g., midhaul link) configured between the DU 108 and the CU 110 to transmit or receive the information/signals between the DU 108 and the CU 110. In further examples, a wireless interface, which may include a receiver, a transmitter, or a transceiver, such as an RF transceiver, configured to transmit and/or receive the information/signals via the wireless transmission medium, such as for information communicated between the RU 106a of the cell 190a and the base station 104e of the cell 190e via cross-cell communication beams 136-138 of the RU 106a and the base station 104e.
The RUs 106 may be configured to implement lower layer functionality. For example, the RU 106 is controlled by the DU 108 and may correspond to a logical node that hosts RF processing functions, or lower layer PHY functionality, such as execution of fast Fourier transform (FFT) , inverse FFT (iFFT) , digital beamforming, physical random access channel (PRACH) extraction and filtering, etc. The functionality of the RU 106 may be based on the functional split, such as a functional split of lower layers.
The RUs 106 may transmit or receive over-the-air (OTA) communication with one or more UEs 102. For example, the RU 106b of the cell 190b communicates with the UE 102b of the cell 190b via a first set of communication beams 132 of the RU 106b and a second set of communication beams 134b of the UE 102b, which may correspond to inter-cell communication beams or, in some examples, cross-cell communication beams. For instance, the UE 102b of the cell 190b may communicate with the RU 106a of the cell 190a via a third set of communication beams 134a of the UE 102b and a fourth set of communication beams 136 of the RU 106a. DUs 108 can control both real-time and non-real-time features of control plane and user plane communications of the RUs 106.
Any combination of the RU 106, the DU 108, and the CU 110, or reference thereto individually, may correspond to a base station 104. Thus, the base station 104 may include at least one of the RU 106, the DU 108, or the CU 110. The base stations 104 provide the UEs 102 with access to a core network. The base stations 104 may relay communications between the UEs 102 and the core network (not shown) . The base stations 104 may be associated with macrocells for higher-power cellular base stations and/or small cells for lower-power cellular base stations. For example, the cell 190e may correspond to a macrocell, whereas the cells 190a-190d may correspond to small cells. Small cells include femtocells, picocells, microcells, etc. A network that includes at least one macrocell and at least one small cell may be referred to as a “heterogeneous network. ”
Transmissions from a UE 102 to a base station 104/RU 106 are referred to as uplink (UL) transmissions, whereas transmissions from the base station 104/RU 106 to the UE 102 are referred to as downlink (DL) transmissions. Uplink transmissions may also be referred to as reverse link transmissions and downlink transmissions may also be referred to as forward link transmissions. For example, the RU 106d utilizes antennas of the base station 104d of cell 190d to transmit a downlink/forward link communication to the UE 102d or receive an uplink/reverse link communication from the UE 102d based on the Uu interface associated with the access link between the UE 102d and the base station 104d/RU 106d.
Communication links between the UEs 102 and the base stations 104/RUs 106 may be based on multiple-input and multiple-output (MIMO) antenna technology, including spatial multiplexing, beamforming, and/or transmit diversity. The communication links may be associated with one or more carriers. The UEs 102 and the base stations 104/RUs 106 may utilize a spectrum bandwidth of Y MHz (e.g., 5, 10, 15, 20, 100, 400, 800, 1600, 2000, etc. MHz) per carrier allocated in a carrier aggregation of up to a total of Yx MHz, where x component carriers (CCs) are used for communication in each of the uplink and downlink directions. The carriers may or may not be adjacent to each other along a frequency spectrum. In examples, uplink and downlink carriers may be allocated in an asymmetric manner, with more or fewer carriers allocated to either the uplink or the downlink. A primary component carrier and one or more secondary component carriers may be included in the component carriers. The primary component carrier may be associated with a primary cell (PCell) and a secondary component carrier may be associated with a secondary cell (SCell) .
Some UEs 102, such as the UEs 102a and 102s, may perform device-to-device (D2D) communications over sidelink. For example, a sidelink communication/D2D link utilizes a spectrum for a wireless wide area network (WWAN) associated with uplink and downlink communications. Such sidelink/D2D communication may be performed through various wireless communications systems, such as wireless fidelity (Wi-Fi) systems, Bluetooth systems, Long Term Evolution (LTE) systems, New Radio (NR) systems, etc.
The base station 104 may include and/or be referred to as a network entity. That is, “network entity” may refer to the base station 104 or at least one unit of the base station 104, such as the RU 106, the DU 108, and/or the CU 110. The base station 104 may also include and/or be referred to as a next generation evolved Node B (ng-eNB) , a next generation NB (gNB) , an evolved NB (eNB) , an access point, a base transceiver station, a radio base station, a radio transceiver, a transceiver function, a basic service set (BSS) , an extended service set (ESS) , a TRP, a network node, network equipment, or other related terminology. The base station 104 or an entity at the base station 104 can be implemented as an IAB node, a relay node, a sidelink node, an aggregated (monolithic) base station, or a disaggregated base station including one or more RUs 106, DUs 108, and/or CUs 110. A set of aggregated or disaggregated base stations may be referred to as a next generation-radio access network (NG-RAN) . In some examples, the UE 102a operates in dual connectivity (DC) with the base station 104e and the base station/RU 106a. In such cases, the base station 104e can be a master node and the base station/RU 160a can be a secondary node.
When the discard report is an RLC discard report, the RLC receiving entity updates an Rx window pointer based on the discard report. The RLC receiving entity updates a Rx window pointer to an SN of an SDU that has not been completely received by the RLC receiving entity. The RLC transmitting entity updates a transmit window pointer based on the status report thereby maintaining synchronization between the receive window pointer in the RLC receiving entity and the transmit window pointer in the RLC transmitting entity.
In one embodiment, a unique field indicates (e.g., via a predefined value) that the discard report is reporting a PDCP SDU discard. In another embodiment, a unique field indicates (e.g., via a predefined value) that the discard report is reporting an RLC SDU discard. Further, the discard report indicates the discarded SDU (s) using any predefined format. For example, the indicator indicating the SN (s) of the discarded SDU (s) may include a starting SN and an ending SN of the discarded SDU (s) , the starting SN and a number of consecutive SNs following the starting SN, or a bitmap indicating the SN (s) of the discarded SDU (s) .
In some aspects, the transmitting entity starts a discard report prohibit timer based on a discard prohibit time period. When the transmitting entity is a UE, the discard report prohibit time period may be indicated by the receiving entity (e.g., the network entity) . Additionally or alternatively, the discard report prohibit time period is a predefined time period based on a communication standard, stored in a memory of the transmitting entity, and/or determined by the transmitting entity. The transmitting entity refrains from transmitting the discard report for the duration of the discard report prohibit timer and transmits the discard report after the discard report prohibit timer expires. The transmitting entity stores the SNs of SDUs discarded during the discard report prohibit time period and transmit indicators of the stored SNs as a batch after expiration of the discard report prohibit timer thereby reducing signaling overhead and increasing bandwidth efficiency. The discard report prohibit time period may be the same for all discarded SDU (s) or may be based on a radio bearer or quality of service (QoS) associated with the discarded SDU (s) .
In some aspects, the receiving entity starts a status report prohibit timer. The receiving entity refrains from transmitting the status report for the duration of the status prohibit time period and transmit the status report after the prohibit timer expires. However, in some aspects, if the receiving entity receives a discard report when the status prohibit timer is running, the receiving entity transmits the status report by overriding the remaining status prohibit time and restart the status prohibit timer after transmitting the status report.
In some aspects, the transmitting entity starts a discard report retransmission timer based on a retransmission time period. When the transmitting entity is a UE, the retransmission time period may be indicated by the receiving entity (e.g., the network entity) . Additionally or alternatively, the retransmission time period may be a predefined time period based on a communication standard, stored in a memory of the transmitting entity, and/or determined by the transmitting entity. The transmitting entity retransmits the discard report after expiration of the retransmission timer if the transmitting entity did not receive the status report from the receiving entity after transmitting the discard report.
Still referring to FIG. 1, in certain aspects, any of the UEs 102 may include a UCI multiplexing component 140 configured to receive, from a network entity 104, a first indication that schedules a first PUSCH associated with a first CORESET pool, the first PUSCH overlapping in time with a PUCCH associated with a second CORESET pool different from the first CORESET pool. The UCI multiplexing component 140 is further configured to transmit, to the network entity 104, an uplink communication associated with an UCI multiplexing scheme based on the first PUSCH overlapping in time with the PUCCH, without obtaining a second indication that schedules a second PUSCH associated with the second CORESET pool, the second PUSCH overlapping in time with the PUCCH.
In certain aspects, any of the base stations 104 or a network entity of the base stations 104 may include a UCI reception component 150 configured to transmit, to a UE 102, a first indication that schedules a first PUSCH associated with a first CORESET pool, the first PUSCH overlapping in time with a PUCCH associated with a second CORESET pool different from the first CORESET pool. The UCI reception component 150 is further configured to transmit, to the UE 102, a second indication that schedules a second PUSCH associated with the second CORESET pool, the second PUSCH overlapping in time with the PUCCH. The UCI reception component 150 is further configured to receive, from the UE, an uplink communication associated with an uplink control information (UCI) multiplexing scheme based on the first PUSCH overlapping in time with the PUCCH. Accordingly, FIG. 1 describes a wireless communication system that may be implemented in connection with aspects of one or more other figures described herein, such as aspects illustrated in FIGs. 2-16. Further, although the following description may be focused on 5G NR, the concepts described herein may be applicable to other similar areas, such as 5G-Advanced and future versions, and other wireless technologies, such as 6G.
FIGs. 2A and 2B are diagrams illustrating a UCI multiplexing scheme according to an embodiment. FIGs. 2A and 2B illustrate diagrams 200 and 220 of uplink resources for transmitting UCI. A network entity configures a UE to transmit UCI on PUCCH 204, such as in the diagram 200, or on PUSCH 202c, such as in the diagram 220, based on UCI multiplexing. The UCI may include a scheduling request, hybrid automatic repeat request-acknowledgement (HARQ-ACK) , and channel state information (CSI) . Thus, the UCI may have 7 permutations that correspond to HARQ-only, scheduling request-only, CSI-only, HARQ and scheduling request, HARQ and CSI, scheduling request and CSI, and HARQ + scheduling request + CSI. However, the UE does not transmit the scheduling request on the PUSCH. The CSI can also include CSI part 1 and CSI part 2, where the CSI part 2 supports variable lengths, such as CSI part 2-only, and may be punctured into two sections by a symbol with demodulation reference signal (DMRS) resource elements and data resource elements. If the network entity configures the UE to transmit the UCI on PUCCH 204 and data on PUSCH 202a in overlapped symbols, such as in diagram 200, the UE may transmit the UCI on PUSCH 202a, such as in diagram 220.
FIGs. 3A, 3B, 4A, 4B, 6A, and 6B illustrate various embodiments for uplink communications for UCI multiplexing scheme when multiple DCI communications are used to schedule multiple PUSCH communications using multiple CORESET pools (e.g., multi-DCI based PUSCH transmission) . In some aspects, each of the CORESET pools may be associated with a different TRP. A network entity can schedule multiple PUSCHs by multiple DCIs, where each DCI schedules one PUSCH and different DCIs are associated with CORESETs with different CORESET pool indexes (e.g., coresetPoolIndex0 and coresetPoolIndex1) . FIGs. 5A and 5B illustrate an example DCI decoding failure for a multi-DCI based PUSCH transmission.
FIGs. 3A and 3B are diagrams illustrating a UCI multiplexing scheme for multi-DCI based PUSCH transmission according to another embodiment. FIGs. 3A and 3B illustrate diagrams 340 and 360 of uplink resources for transmitting UCI. A UE receives a first DCI that schedules a first PUSCH 202a in a first CORESET pool. The UE receives a second DCI that schedules a second PUSCH 202b in a second CORESET pool. PUCCH 204 may be scheduled in either the first or second CORESET pool. The first PUSCH 202a and the second PUSCH 202b overlap in time (e.g., overlapping symbols) with the PUCCH 204.
In some aspects, if the UE is configured for joint HARQ-ACK feedback mode or the UCI only includes a CSI report, the UE transmits the UCI multiplexed with the PUSCH 202a scheduled by the first DCI in the first CORESET pool.
FIGs. 4A and 4B are diagrams illustrating a UCI multiplexing scheme for multi-DCI based PUSCH transmission according to another embodiment. FIGs. 4A and 4B illustrate diagrams 440 and 460 of uplink resources for transmitting UCI. In FIG. 4A the UE receives a first DCI that schedules a first PUSCH 202a in a first CORESET pool. The UE receives a second DCI that schedules a second PUSCH 202b in a second CORESET pool. PUCCH 204 is scheduled in the second CORESET pool. The first PUSCH 202a and the second PUSCH 202b overlap in time (e.g., overlapping symbols) with the PUCCH 204.
In some aspects, if the UE is configured for separate HARQ-ACK feedback mode and the UCI includes HARQ-ACK feedback, the UE transmits the UCI multiplexed with the PUSCH 202 having the same CORESET pool as the PUCCH 204. In the example of FIG. 4B the UE transmits the UCI multiplexed with the PUSCH 202b scheduled by the second DCI in the second CORESET pool.
FIGs. 5A and 5B are diagrams illustrating an example DCI decoding failure for multi-DCI based PUSCH transmission according to an embodiment. FIGs. 5A and 5B illustrate diagrams 540 and 560 of uplink resources for transmitting UCI. In FIG. 5A the UE receives a first DCI that schedules a first PUSCH 202a in a first CORESET pool. PUCCH 204 is scheduled in the second CORESET pool. The first PUSCH 202a overlaps in time (e.g., overlapping symbols) with the PUCCH 204.
The network entity transmits a second DCI that schedules a second PUSCH 202b in a second CORESET pool. However, in some instances, the UE may fail to receive or properly decode the second DCI. The UE may be unaware of whether the failure to receive or properly decode one of the DCIs is a result of a scheduling error by the network entity, interference in the channel, a decoding error, or some other cause. For example, the UE may determine an error case where PUCCH 204 overlaps in time with a first scheduled PUSCH 202a associated with the first CORESET pool (e.g., a different CORESET pool from the PUCCH) and does not overlap in time with a second scheduled PUSCH associated with the same CORESET pool, due to decoding failure of the second DCI that schedules the second PUSCH. In response, the UE may unnecessarily transmit a RRC reconfiguration request to the network entity. Methods of the present disclosure avoid unnecessary RRC reconfiguration procedures which do not result from the network entity’s scheduling error but, rather, result from the second DCI decoding failure. The unnecessary RRC reconfiguration procedures increase the latency and system overhead of the network. Therefore, methods of the present disclosure improve the network performance by avoiding the unnecessary RRC reconfiguration procedure caused by the second DCI decoding failure at the UE.
In some aspects, the network entity may indicate a scheduling status to the UE indicating how many DCIs scheduling PUSCHs are transmitted to the UE. In this way, the UE knows whether the UE has failed to receive and/or properly decode all the DCIs transmitted by the network entity. For example, when the network entity transmits the first DCI and the second DCI to the UE, the first DCI may indicate that the second DCI is transmitted to the UE and the second DCI may indicate that the first DCI is transmitted to the UE. Additionally or alternatively, the network entity may transmit an RRC message, a dedicated DCI, or a MAC-CE including a schedule for a plurality of slots for the PUSCHs scheduled in different CORESET pools. Based on the scheduling status received from the network entity, when the UE detects a PUCCH overlaps with PUSCH (s) from different CORESET pools, the UE determines whether it is due to an incorrect network entity configuration or the UE not receiving/decoding a DCI.
In some aspects, the network entity indicates whether there is a PUSCH scheduled by another DCI by a DCI field explicitly. The DCI field may be separate DCI field, (e.g., a flag indicating whether there is a scheduled PUSCH from another DCI) . In some aspects, the network entity provides the indication based on the reserved indication for existing DCI field (s) (e.g., antenna ports, precoder and number of layers) .
In some aspects, the network entity implicitly indicates whether there is a PUSCH scheduled by another DCI based on the resource location of the PDCCH carrying the DCI. In one example, the network entity implicitly indicates the indication based on the starting control channel element (CCE) index. For example, an odd CCE index may indicate there is no PUSCH scheduled by another DCI and an even CCE index may indicate there is a PUSCH scheduled by another DCI.
In some aspects, the network entity indicates whether there is a PUSCH scheduled by another DCI by indicating whether there is a PUSCH scheduled by another DCI from a CORESET associated with a different CORESETPoolIndex value.
In some aspects, the DCI scheduling status indication may be indicated by a downlink (DL) assignment or a dedicated DCI. For example, one DCI field in a DL assignment or a dedicated DCI may indicate whether the network entity schedules two PUSCHs associated with CORESETs with different CORESETPoolIndex values in a slot or in a next available UL slot.
In some aspects, the network entity indicates the scheduling status for a set of slots by MAC-CE or a dedicated DCI. In this regard, the network entity indicates whether there is a PUSCH scheduled for each slot for each CORESET pool separately. In some aspects, the network entity may indicate the number of scheduled PUSCHs. For example, no PUSCH, one PUSCH, or two PUSCHs, for each slot.
In some aspects, the network entity may indicate in MAC-CE or DCI a serving cell index indicating the target serving cell for the indication, a field indicating whether the MAC- CE or DCI is for uplink (UL) or supplemental uplink (SUL) , a bandwidth part index indicating the target bandwidth part for the indication, the slot index (es) for one or more PUSCHs, and/or a CORESET pool index.
FIGs. 6A and 6B are diagrams illustrating a UCI multiplexing scheme for multi-DCI based PUSCH transmission according to some embodiments. FIGs. 6A and 6B illustrate diagrams 640 and 660 of uplink resources for transmitting UCI. In FIG. 6A, the network entity transmits a first DCI that schedules a first PUSCH 202a in a first CORESET pool and a second DCI that schedules a second PUSCH 202b in a second CORESET pool. A PUCCH 204 is scheduled in the second CORESET pool. Further, the network entity indicates configured grant (CG) PUSCH 202c in the first CORESET and CG PUSCH 202d in the second CORESET. The first PUSCH 202a, the second PUSCH 202b, the CG PUSCH 202c, and the CG PUSCH 202d overlap in time (e.g., overlapping symbols) with the PUCCH 204. The CG PUSCH 202c and the CG PUSCH 202d resources may be reserved for UCI multiplexing by RRC signaling. In some aspects, the CG PUSCH 202c and the CG PUSCH 202d resources may only be used for UCI multiplexing in which the UE refrains from transmitting data on the CG PUSCH 202c and the CG PUSCH 202d resources. The network entity may configure at least one CG-PUSCH resource reserved for each CORESET pool. If the UE fails to decode the second DCI, the UE determines the UCI multiplexing scheme based on the reserved CG PUSCH 202c, the CG PUSCH 202d, and the first PUSCH 202a. In other words, if the UE detects the first DCI scheduling the first PUSCH on a slot where a PUCCH is to be transmitted, the UE determines the UCI multiplexing scheme based on the reserved CG PUSCH 202c, the CG PUSCH 202d, and the first PUSCH 202a. Thus, if the UE is configured for joint HARQ-ACK feedback mode or the PUCCH contains CSI report only, the UE transmits the UCI multiplexed with the first PUSCH 202a associated with the first CORESET pool, otherwise, the UE transmits the UCI multiplexed with the CG PUSCH 202d associated with the second CORESET pool, where the CG PUSCH 202d and the PUCCH 204 are associated with the second CORESET pool.
In some aspects, if the UE fails to decode both the first DCI and the second DCI, the UE transmits the PUCCH to the network entity without UCI multiplexing. If the UE successfully decodes both the first DCI scheduling the first PUSCH 202a and the second DCI scheduling the second PUSCH 202b, the UE determines the UCI multiplexing scheme based on the scheduled PUSCHs 202.
FIGs. 7A-11B illustrate various embodiments for uplink communications for UCI multiplexing scheme when PUCCH overlaps in time with PUSCH (s) from different CORESET pools only. As previously described in FIGs. 5A and 5B, the UE may determine an error case where PUCCH overlaps in time with a first scheduled PUSCH associated with a different CORESET pool (as the PUCCH) and does not overlap in time with a second scheduled PUSCH associated with the same CORESET pool, due to decoding failure of a second DCI that schedules the second PUSCH. However, the various embodiments described below with reference to FIGs. 7A-11B may help the UE avoid unnecessary error handling procedures which do not result from the network entity’s scheduling error but, rather, result from failure to obtain the second DCI.
FIGs. 7A and 7B are diagrams illustrating a PUSCH transmission without UCI according to an embodiment. FIGs. 7A and 7B illustrate diagrams 740 and 760 of uplink resources for transmitting UCI. In FIG. 7A the UE receives a first DCI that schedules a first PUSCH 202a in a first CORESET pool. PUCCH 204 is scheduled in the second CORESET pool. The first PUSCH 202a overlaps in time (e.g., overlapping symbols) with the PUCCH 204.
In some aspects, if the UE determines the PUCCH 204 in the second CORESET pool overlaps with the first PUSCH 202a in the first CORESET pool but does not overlap with any PUSCH from the second CORESET pool in the time domain, the UE may transmit, as shown in FIG. 7B, the first PUSCH 202a only without UCI multiplexing. Thus, the UE refrains from transmitting the PUCCH 204. In such cases, the UE may drop the UCI transmission.
FIGs. 8A and 8B are diagrams illustrating a PUCCH transmission according to an embodiment. FIGs. 8A and 8B illustrate diagrams 840 and 860 of uplink resources for transmitting UCI. In FIG. 8A the UE receives a first DCI that schedules a first PUSCH 202a in a first CORESET pool. PUCCH 204 is scheduled in the second CORESET pool. The first PUSCH 202a overlaps in time (e.g., overlapping symbols) with the PUCCH 204.
In some aspects, if the UE determines the PUCCH 204 in the second CORESET pool overlaps with the first PUSCH 202a in the first CORESET pool but does not overlap with any PUSCH from the second CORESET pool in the time domain, the UE may only transmit, as shown in FIG. 8B, the PUCCH 204. Thus, the UE refrains from transmitting the PUSCH 202a.
FIGs. 9A and 9B are diagrams illustrating a PUSCH transmission with UCI according to another embodiment. FIGs. 9A and 9B illustrate diagrams 940 and 960 of uplink resources for transmitting UCI. In FIG. 9A the UE receives a first DCI that schedules a first PUSCH 202a in a first CORESET pool. PUCCH 204 is scheduled in the second CORESET pool. The first PUSCH 202a overlaps in time (e.g., overlapping symbols) with the PUCCH 204.
In some aspects, if the UE determines the PUCCH 204 in the second CORESET pool overlaps with the first PUSCH 202a in the first CORESET pool but does not overlap with any PUSCH from the second CORESET pool in the time domain, the UE transmits, as shown in FIG. 9B, the first PUSCH 202a with UCI multiplexing. Thus, the UE refrains from transmitting the PUCCH 204 and transmits the first PUSCH 202a multiplexed with UCI.
FIGs. 10A and 10B are diagrams illustrating a PUCCH and PUSCH transmission without UCI according to an embodiment. FIGs. 10A and 10B illustrate diagrams 1040 and 1060 of uplink resources for transmitting UCI. In FIG. 10A the UE receives a first DCI that schedules a first PUSCH 202a in a first CORESET pool. PUCCH 204 is scheduled in the second CORESET pool. The first PUSCH 202a overlaps in time (e.g., overlapping symbols) with the PUCCH 204.
In some aspects, if the UE determines the PUCCH 204 in the second CORESET pool overlaps with the first PUSCH 202a in the first CORESET pool but does not overlap with any PUSCH from the second CORESET pool in the time domain, the UE transmits, as shown in FIG. 10B, both the first PUSCH 202a without UCI multiplexing and the PUCCH 204.
FIGS. 11A and 11B are diagrams illustrating a PUCCH and PUSCH transmission with UCI according to another embodiment. FIGs. 11A and 11B illustrate diagrams 1140 and 1160 of uplink resources for transmitting UCI. In FIG. 11A the UE receives a first DCI that schedules a first PUSCH 202a in a first CORESET pool. PUCCH 204 is scheduled in the second CORESET pool. The first PUSCH 202a overlaps in time (e.g., overlapping symbols) with the PUCCH 204.
In some aspects, if the UE determines the PUCCH 204 in the second CORESET pool overlaps with the first PUSCH 202a in the first CORESET pool but does not overlap with any PUSCH from the second CORESET pool in the time domain, the UE transmits, as shown in FIG. 11B, both the first PUSCH 202a with UCI multiplexing and the PUCCH 204. In this case, both the PUCCH 204 and the first PUSCH 202a may carry the UCI. The UE may transmit the UCI via the PUCCH 204 to a first TRP, and transmit the UCI via the first PUSCH 202a to a second, different TRP thereby increasing the reliability of the UCI through transmit diversity.
In some aspects, the network entity may indicate which of the UCI multiplexing schemes described with reference to FIGS. 2A-4B and 6A-11B is performed by the UE. In this regard, the network entity may transmit, to the UE, the indicator via RRC signaling, MAC-CE, DCI, or other suitable communication.
In some aspects, the network entity may indicate whether the UE performs UCI multiplexing or not when the UE determines that the PUCCH 204 overlaps in time with PUSCH (s) 202 from different CORESET pools but does not overlap in time with any PUSCH 202 from the same CORESET pool as the PUCCH 204. In this regard, the network entity may transmit, to the UE, the UCI multiplexing indicator via RRC signaling, MAC-CE, DCI, or other suitable communication.
In some aspects, the network entity may provide separate configurations for the case when the UE is configured for joint HARQ-ACK feedback or the UCI includes CSI only, and the case when the UE is configured for separate HARQ-ACK feedback and the UCI contains HARQ-ACK. Additionally or alternatively, the network entity may provide a common configuration for both cases.
In some aspects, the network entity may configure whether the UE drops the PUCCH 204 or PUSCH 202 if the UCI multiplexing is disabled. Additionally or alternatively, the decision whether the UE drops the PUCCH or PUSCH when UCI multiplexing is disabled may be predefined (e.g., stored in memory 1506’, 1526’) .
In some aspects, the network entity may indicate whether the UE transmits the PUSCH (s) 202 and PUCCH 204 simultaneously. The network entity may further configure whether the UE drops the PUSCH (s) 202 or PUCCH 204 if the simultaneous transmission is disabled. In this regard, the network entity may transmit, to the UE, the indicator via RRC signaling, MAC-CE, DCI, or other suitable communication. Additionally or alternatively, the decision whether the UE drops the PUCCH 204 or PUSCH 202 when simultaneous transmission is disabled may be predefined (e.g., stored in memory 1506’, 1526’) .
In some aspects, the UE determines whether to drop the PUCCH 204/PUSCH 202 or multiplex the UCI with the PUSCH 202 based on the content of the UCI and/or the HARQ-ACK feedback mode (e.g., joint HARQ-ACK feedback mode or separate HARQ-ACK feedback mode) . In some aspects, if the UE is configured for separate HARQ-ACK feedback and the UCI contains HARQ-ACK, the UE drops either the PUCCH 204 or the PUSCH 202, otherwise the UE multiplexes the UCI with the PUSCH 202.
In some aspects, if the UE determines that the PUCCH 204 overlaps in time with PUSCH (s) 202 from different CORESET pools but does not overlap in time with any PUSCH 202 from the same CORESET pool as the PUCCH 204 in the time domain (e.g., overlapping symbols) , the UE may determine whether to only transmit the PUSCH 202 or PUCCH 204 based on the contents carried by the PUSCH 202 and/or the PUCCH 204. For example, if the PUSCH 202 carries a MAC-CE of a certain type (e.g., beam failure recovery (BFR) MAC-CE, or MAC-CE for CG confirmation) , the UE may transmit the PUSCH (s) 202 only without UCI multiplexing and refrain from transmitting the PUCCH 204, otherwise the UE may only transmit the PUCCH 204 and refrain from transmitting the PUSCH 202.
In some aspects, the UE transmits, to the network entity, a UE capability indicator indicating support for at least one of UCI multiplexing for multiple DCI based PUSCH 202 transmission, UCI multiplexing for joint HARQ-ACK feedback mode, UCI multiplexing for separate HARQ feedback mode, and/or UCI multiplexing for overlapping scheduled PUCCH 204 and scheduled PUSCH 202 associated with different CORESET pools. The UE may transmit the UE capability separately or commonly for the case when the UE is configured for joint HARQ-ACK feedback or the UCI contains CSI only, and the case when the UE is configured for separate HARQ-ACK feedback mode and the UCI contains HARQ-ACK feedback.
In some aspects, the options described above may only be applicable when the UE determines that it fails to decode the DCI for the PUSCH 202 associated with the same CORESET pool index as the PUCCH 204.
FIG. 12 is a signal flow diagram of a communication method 1200 for multi-DCI based PUSCH transmission according to an embodiment. Aspects of the method 1200 can be executed by a computing device (e.g., a processor, processing circuit, and/or other suitable component) of a wireless communication device or other suitable means for performing the actions. For example, a wireless communication device, such as the UE 102 or the UE 1502 utilizes one or more components, such as the application processor 1506, the memory 1506’, the UCI multiplexing component 140a and/or 140b, the transceiver 1530, the wireless baseband processor 1526, the memory 1526’, and the one or more antennas 1540, to execute aspects of method 1200. In some aspects, a wireless communication device, such as the network entity 104 utilizes one or more components, such as the RU processor 1606, the memory 1606’, DU processor 1626, the memory 1626’, the CU processor 1646, the memory 1646’, the UCI reception component 150a and/or 150b, the transceiver 1630, and the one or more antennas 1640, to execute aspects of method 1200. The method 1200 employs similar mechanisms as in the network 100 and the aspects and actions described with respect to FIGs. 2A-11B. As illustrated, the method 1200 includes a number of enumerated actions, but the method 1200 can include additional actions before, after, and in between the enumerated actions. In some aspects, one or more of the enumerated actions can be omitted or performed in a different order.
The UE 102 optionally transmits 1205 UE capability information to the network entity 104. In this regard, the UE 102 may transmit 1205 the UE capability information to the network entity 104 using RRC signaling or other suitable communication. The UE 102 may transmit 1205 the UE capability information to the network entity 104 autonomously or in response to receiving a device capability indicator enquiry from the network entity 104. The UE capability information indicates the UE’s 102 capability for at least one of UCI multiplexing for multi-DCI based PUSCH transmission, UCI multiplexing for joint HARQ-ACK feedback mode, UCI multiplexing for separate HARQ feedback mode, and/or UCI multiplexing for overlapping scheduled PUCCH and scheduled PUSCH associated with different CORESET pools (e.g., coresetPoolIndex0 and coresetPoolIndex1) . The UE may transmit 1205 the UE capability separately or commonly for the case when the UE 102 is configured for joint HARQ-ACK feedback or the UCI contains CSI only, and the case when the UE 102 is configured for separate HARQ-ACK feedback mode and the UCI contains HARQ-ACK feedback. Additionally or alternatively, the UE’s 102 capability may be prestored in the UE 102 and the network entity 104.
The network entity 104 transmits 1210 a configuration to the UE 102. In this regard, the network entity 104 transmits 1210 the configuration to the UE 102 using RRC signaling, a MAC-CE, a DCI, or other suitable communication. The configuration may be associated with the first CORESET pool (e.g., coresetPoolIndex0) , the second CORESET pool (e.g., coersetPoolIndex1) , and/or a HARQ feedback mode. In some aspects, the configuration may further indicate an uplink communication to be transmitted to the network entity 104. The configuration may indicate the UE to transmit a PUCCH (see FIGs. 8A and 8B) , a PUSCH without UCI multiplexing (see FIGs. 7A and 7B) , a PUSCH with UCI multiplexing (see FIGs. 9A and 9B) , the PUCCH and the PUSCH without UCI multiplexing (see FIGs. 10A and 10B) , or the PUCCH and the PUSCH with UCI multiplexing (see FIGs. 11A and 11B) . The network entity 104 may determine the uplink communication based on at least one of the UE 102 being configured for joint HARQ feedback, the UE 102 being configured for separate HARQ feedback, the UCI comprising CSI, the UCI comprising HARQ feedback, the UE 102 being configured for UCI multiplexing, a priority associated with content of the PUSCH, and/or a priority associated with content of the UCI.
The network entity 104 transmits 1215 a first indicator to schedule a first PUSCH associated with a first CORESET pool overlapping in time (e.g., overlapping symbols) with a PUCCH associated with a second CORESET pool. In some aspects, the first PUSCH may partially overlap in time with the PUCCH. In some other aspects, the first PUSCH may fully overlap in time with the PUCCH. In some aspects, the first indicator may indicate a scheduling status to the UE 102 indicating how many DCIs scheduling PUSCHs are being transmitted to the UE 102. In this way, the UE 102 knows whether the UE 102 has failed to receive and/or properly decode all the DCIs transmitted by the network entity 104. For example, when the network entity 104 transmits a first DCI and a second DCI to the UE 102, the first DCI may indicate that the second DCI is transmitted to the UE 102 and the second DCI may indicate that the first DCI is transmitted to the UE 102. Additionally or alternatively, the network entity 104 may transmit an RRC message, a dedicated DCI, or a MAC-CE including a schedule for a plurality of slots for the PUSCHs scheduled in different CORESET pools. Based on the scheduling status received from the network entity 104, when the UE 102 detects a PUCCH overlaps with PUSCH (s) from different CORESET pools only, the UE 102 can determine whether it is due to a network entity configuration error or the UE 102 not obtaining a DCI (e.g., not receiving the DCI or failure decoding the DCI) .
In some aspects, the first indicator indicates whether there is a PUSCH scheduled by another DCI by an explicit DCI field. For example, the DCI field may be a separate DCI field, (e.g., a flag indicating whether there is a scheduled PUSCH from another DCI) . In another example, the network entity 104 transmits the first indicator based on the reserved indication for an existing DCI field (s) (e.g., antenna ports, precoder, and number of layers) .
In some aspects, the network entity 104 implicitly indicates whether there is a PUSCH scheduled by another DCI based on the resource location of the PDCCH carrying the DCI. In one example, the network entity implicitly indicates the indication based on the starting control channel element (CCE) index. For example, an odd CCE index may indicate there is no PUSCH scheduled by another DCI and an even CCE index may indicate there is a PUSCH scheduled by another DCI, or vice versa.
In some aspects, the network entity indicates whether there is a PUSCH scheduled by another DCI by indicating whether there is a PUSCH scheduled by another DCI from a CORESET associated with a different CORESETPoolIndex value.
In some aspects, the DCI scheduling status indication may be indicated by a downlink (DL) assignment or dedicated DCI. For example, one DCI field in a DL assignment or dedicated DCI may indicate whether the network entity schedules two PUSCHs associated with CORESETs with different CORESETPoolIndex values (e.g., coresetPoolIndex0 and coresetPoolIndex1) in a slot or in a next available UL slot.
In some aspects, the network entity 104 indicates the scheduling status for a set of slots by MAC-CE or a dedicated DCI. In this regard, the network entity 104 indicates whether there will be a PUSCH scheduled for each slot for each CORESET pool separately. In some aspects, the network entity 104 may indicate the number of scheduled PUSCHs. For example, no PUSCH, one PUSCH or two PUSCHs, for each slot.
The network entity 104 transmits 1220 a second indicator that schedules a second PUSCH associated with a second CORESET pool overlapping in time (e.g., overlapping symbols) with a PUCCH associated with the second CORESET pool. In some aspects, the second PUSCH may partially overlap in time with the PUCCH. In some other aspects, the first PUSCH may fully overlap in time with the PUCCH. However, in some instances, the UE 102 may fail to receive or properly decode the second DCI (see FIGs. 5A and 5B) . The UE 102 may be unaware of whether the failure to receive or properly decode one of the DCIs is a result of a scheduling error by the network entity 104, interference in the channel, a decoding error, or some other cause. For example, the UE 102 may determine an error case where a scheduled PUCCH overlaps in time with a scheduled PUSCH associated with different CORESET pools and does not overlap in time with a second scheduled PUSCH associated with the same CORESET pool, due to decoding failure of the second DCI. In response, the UE 102 may unnecessarily transmit a RRC reconfiguration request to the network entity. Methods of the present disclosure avoid unnecessary RRC reconfiguration procedures which do not result from the network entity’s scheduling error but, rather, result from failure of obtaining the second DCI.
The network entity 104 transmits 1225 a third DCI to the UE 102 that schedules the PUCCH. The PUCCH may be associated with the second CORESET pool and may be scheduled to carry UCI as described above with reference to FIGs. 2A-11B.
The UE 102 determines 1230 a UCI multiplexing scheme for the scheduled PUCCH/PUSCH (s) as described above with reference to FIGs. 2A-4B and 6A-11B. The UE determines the uplink communication based on a configuration received from the network entity, content of the UCI, content of the PUSCH, and/or a HARQ configuration. The UE 102 transmits 1235 an uplink communication (s) to the network entity 104 based on the determined 1230 UCI multiplexing scheme. The uplink communication includes a PUCCH only (see FIGs. 8A and 8B) , a PUSCH only without UCI multiplexing (see FIGs. 7A and 7B) , the PUSCH only with UCI multiplexing (see FIGs. 9A and 9B) , the PUCCH and the PUSCH without UCI multiplexing (see FIGs. 10A and 10B) , or the PUCCH and the PUSCH multiplexed with the UCI (see FIGs. 11A and 11B) . Additionally or alternatively, the UE may receive a configured grant (CG) for a PUSCH transmission and transmit the CG PUSCH multiplexed with UCI.
FIG. 13 illustrates a flowchart 1300 of a method of wireless communication for multi-DCI based PUSCH transmission at UE according to an embodiment. With reference to FIGs. 1-12, the method can be performed by the UE 102, the UE apparatus 1502, etc., which includes UCI multiplexing components 140a/140b, memory 1526', 1506', 1516, and which may correspond to the entire UE 102 or the entire UE apparatus 902, or a component of the UE 102 or the UE apparatus 1502, such as the wireless baseband processor 1526 and/or the application processor 1506.
The UE 102 transmits 1305, to a network entity, a UE capability indicator indicating support for UCI multiplexing on multi-DCI based PUSCH transmission. For example, referring to FIG. 12, the UE 102 transmits 1205, to network entity 104, a UE capability indicator indicating support for UCI multiplexing on multi-DCI based PUSCH transmission.
The UE 102 receives 1310, from the network entity 104, a configuration identifying the CORESET pools and HARQ-ACK feedback mode and, optionally, configured grant PUSCHs/uplink communication. For example, referring to FIG. 12, the UE 102 receives 1210, from the network entity 104, a configuration identifying the CORESET pools and HARQ-ACK feedback mode and, optionally, configured grant PUSCHs/uplink communication.
The UE 102 receives 1315, from the network entity 104, a first indication that schedules a first PUSCH associated with a first CORESET pool, the first PUSCH overlapping in time with a PUCCH associated with a second CORESET pool different from the first CORESET pool. For example, referring to FIG. 12, the UE 102 receives 1215, from the network entity 104, a first DCI that schedules a first PUSCH associated with a first CORESET pool, the first PUSCH overlapping in time with a PUCCH associated with a second CORESET pool different from the first CORESET pool. In some aspects, the first PUSCH may partially overlap in time with the PUCCH. In some other aspects, the first PUSCH may fully overlap in time with the PUCCH.
The UE 102 receives 1325, from the network entity 104, a third indication that schedules the PUCCH. The PUCCH may be associated with the second CORESET pool and may be scheduled to carry UCI. For example, referring to FIG. 12, the UE 102 receives 1225 a third indication that schedules the PUCCH.
The UE 102 determines 1330 a UCI multiplexing scheme for the scheduled PUSCHs. For example, referring to FIG. 12, the UE 102 determines 1230 a UCI multiplexing scheme for the scheduled PUSCHs.
The UE 102 transmits 1335, to the network entity 104, an uplink communication associated with a UCI multiplexing scheme based on the first PUSCH overlapping in time with the PUCCH, without obtaining a second indication that schedules a second PUSCH associated with the second CORESET pool, the second PUSCH overlapping in time with the PUCCH. In some aspects, the UE 102 may fail to decode the second indication that schedules the second PUSCH. In other aspects, the UE 102 may fail to receive the second indication that schedules the second PUSCH. For example, referring to FIG. 12, the UE 102 transmits 1225, to the network entity 104, an uplink communication associated with a UCI multiplexing scheme based on the first PUSCH overlapping in time with the PUCCH, without obtaining a second indication that schedules a second PUSCH associated with the second CORESET pool, the second PUSCH overlapping in time with the PUCCH. FIG. 13 describes a method from the point of view of a UE, whereas FIG. 14 describes a method from the point of view of a network entity.
FIG. 14 illustrates a flowchart 1400 of a method of wireless communication for multi-DCI based PUSCH transmission at a network entity according to an embodiment. With reference to FIGs. 1-12, the method can be performed by the network entity 104, the RU 106, the DU 108, the CU 110, etc., which includes the UCI reception components 150a/150b/150c, memory 1626', 1606', 1616, and which may correspond to the entire network 104, or a component of the network 104, such as the RU processor 1606, DU processor 1626 and/or the CU processor 1646.
The network entity 104 receives 1405, from UE 102, a UE capability indicator indicating support for UCI multiplexing on multi-DCI based PUSCH transmission. For example, referring to FIG. 12, the UE 102 transmits 1205, a UE capability indicator to the network entity 104 indicating support for UCI multiplexing on multi-DCI based PUSCH transmission.
The network entity 104 transmits 1410, to UE 102, a configuration identifying the CORESET pools and HARQ-ACK feedback mode and, optionally, configured grant PUSCHs/uplink communication. For example, referring to FIG. 12, the network entity 104 transmits 1210, to UE 102, a configuration identifying the CORESET pools and HARQ-ACK feedback mode and, optionally, configured grant PUSCHs/uplink communication.
The network entity 104 transmits 1415, to UE 102, a first indication that schedules a first PUSCH associated with a first CORESET pool, the first PUSCH overlapping in time with a PUCCH associated with a second CORESET pool different from the first CORESET pool and, optionally, indicating a scheduling status for a second PUSCH associated with the second CORESET pool. In some aspects, the first PUSCH may partially overlap in time with the PUCCH. In some other aspects, the first PUSCH may fully overlap in time with the PUCCH. For example, referring to FIG. 12, the network entity 104 transmits 1215, to UE 102, a first DCI that schedules a first PUSCH associated with a first CORESET pool, the first PUSCH overlapping in time with a PUCCH associated with a second CORESET pool different from the first CORESET pool.
The network entity 104 transmits 1420, to UE 102, a second indication that schedules a second PUSCH associated with the second CORESET pool, the second PUSCH overlapping in time with the PUCCH and, optionally, indicating a scheduling status for the first PUSCH associated with first CORESET pool. In some aspects, the second PUSCH may partially overlap in time with the PUCCH. In still other aspects, the second PUSCH may fully overlap in time with the PUCCH. For example, referring to FIG. 12, network entity 104 transmits 1220, to UE 102, a second indication that schedules a second PUSCH associated with the second CORESET pool, the second PUSCH overlapping in time with the PUCCH and, optionally, indicating scheduling status for first CORESET.
The network entity 104 transmits 1425, to UE 102, a third indication that schedules the PUCCH. The PUCCH may be associated with the second CORESET pool and may be scheduled to carry UCI. For example, referring to FIG. 12, network entity 104 transmits 1225, to UE 102, a third indication that schedules the PUCCH.
The network entity 104 receives 1435, from UE 102, an uplink communication associated with a UCI multiplexing scheme based on the first PUSCH overlapping in time with the PUCCH. In some aspects, the uplink communication may be associated with the UCI multiplexing schemes described with reference to FIGs. 7A-11B. For example, referring to FIG. 12, network entity 104 receives 1235, from UE 102, an uplink communication associated with a UCI multiplexing scheme based on the first PUSCH overlapping in time with the PUCCH.
FIG. 15 is a diagram 1500 illustrating an example of a hardware implementation for a UE apparatus 1502 according to some embodiments. The UE apparatus 1502 may be the UE 102, a component of the UE 102, or may implement UE functionality. The UE apparatus 1502 may include an application processor 1506, which may have on-chip memory 1506’. In examples, the application processor 1506 may be coupled to a secure digital (SD) card 1508 and/or a display 1510. The application processor 1506 may also be coupled to a sensor (s) module 1512, a power supply 1514, an additional module of memory 1516, a camera 1518, and/or other related components. For example, the sensor (s) module 1512 may control a barometric pressure sensor/altimeter, a motion sensor such as an inertial management unit (IMU) , a gyroscope, accelerometer (s) , a light detection and ranging (LIDAR) device, a radio-assisted detection and ranging (RADAR) device, a sound navigation and ranging (SONAR) device, a magnetometer, an audio device, and/or other technologies used for positioning.
The UE apparatus 1502 may further include a wireless baseband processor 1526, which may be referred to as a modem. The wireless baseband processor 1526 may have on-chip memory 1526'. Along with, and similar to, the application processor 1506, the wireless baseband processor 1526 may also be coupled to the sensor (s) module 1512, the power supply 1514, the additional module of memory 1516, the camera 1518, and/or other related components. The wireless baseband processor 1526 may be additionally coupled to one or more subscriber identity module (SIM) card (s) 1520 and/or one or more transceivers 1530 (e.g., wireless RF transceivers) .
Within the one or more transceivers 1530, the UE apparatus 1502 may include a Bluetooth module 1532, a WLAN module 1534, an SPS module 1536 (e.g., GNSS module) , and/or a cellular module 1538. The Bluetooth module 1532, the WLAN module 1534, the SPS module 1536, and the cellular module 1538 may each include an on-chip transceiver (TRX) , or in some cases, just a transmitter (TX) or just a receiver (RX) . The Bluetooth module 1532, the WLAN module 1534, the SPS module 1536, and the cellular module 1538 may each include dedicated antennas and/or utilize antennas 1540 for communication with one or more other nodes. For example, the UE apparatus 1502 can communicate through the transceiver (s) 1530 via the antennas 1540 with another UE (e.g., sidelink communication) and/or with a network entity 104 (e.g., uplink/downlink communication) , where the network entity 104 may correspond to a base station or a unit of the base station, such as the RU 106, the DU 108, or the CU 110.
The wireless baseband processor 1526 and the application processor 1506 may each include a computer-readable medium /memory 1526', 1506', respectively. The additional module of memory 1516 may also be considered a computer-readable medium /memory. Each computer-readable medium /memory 1526', 1506', 1516 may be non-transitory. The wireless baseband processor 1526 and the application processor 1506 may each be responsible for general processing, including execution of software stored on the computer-readable medium /memory 1526', 1506', 1516. The software, when executed by the wireless baseband processor 1526 /application processor 1506, causes the wireless baseband processor 1526 /application processor 1506 to perform the various functions described herein. The computer-readable medium /memory may also be used for storing data that is manipulated by the wireless baseband processor 1526 /application processor 1506 when executing the software. The wireless baseband processor 1526 /application processor 1506 may be a component of the UE 102. The UE apparatus 1502 may be a processor chip (e.g., modem and/or application) and include just the wireless baseband processor 1526 and/or the application processor 1506. In other examples, the UE apparatus 1502 may be the entire UE 102 and include the additional modules of the apparatus 1502.
As discussed in FIG. 1 and implemented with respect to FIG. 13, the UCI multiplexing component 140 is configured to receive, from a network entity, a first indication that schedules a first PUSCH associated with a first CORESET pool, the first PUSCH overlapping in time with a PUCCH associated with a second CORESET pool different from the first CORESET pool. The UCI multiplexing component 140 is configured to transmit, to the network entity, an uplink communication associated with an uplink control information (UCI) multiplexing scheme based on the first PUSCH overlapping in time with the PUCCH, without obtaining a second indication that schedules a second PUSCH associated with the second CORESET pool, the second PUSCH overlapping in time with the PUCCH.
The UCI multiplexing component 140 may be within the application processor 1506 (e.g., at 140a) , the wireless baseband processor 1526 (e.g., at 140b) , or both the application processor 1506 and the wireless baseband processor 1526. The UCI multiplexing component 140a-140b may be one or more hardware components specifically configured to carry out the stated processes/algorithm, implemented by one or more processors configured to perform the stated processes/algorithm, stored within a computer-readable medium for implementation by the one or more processors, or a combination thereof.
FIG. 16 is a diagram 1600 illustrating an example of a hardware implementation for one or more network entities 104 according to other embodiments. The one or more network entities 104 may be a base station, a component of a base station, or may implement base station functionality. The one or more network entities 104 may include, or may correspond to, at least one of the RU 106, the DU, 108, or the CU 110. The CU 110 may include a CU processor 1646, which may have on-chip memory 1646'. In some aspects, the CU 110 may further include an additional module of memory 1656 and/or a communications interface 1648, both of which may be coupled to the CU processor 1646. The CU 110 can communicate with the DU 108 through a midhaul link 162, such as an F1 interface between the communications interface 1648 of the CU 110 and a communications interface 1628 of the DU 108.
The DU 108 may include a DU processor 1626, which may have on-chip memory 1626'. In some aspects, the DU 108 may further include an additional module of memory 1636 and/or the communications interface 1628, both of which may be coupled to the DU processor 1626. The DU 108 can communicate with the RU 106 through a fronthaul link 160 between the communications interface 1628 of the DU 108 and a communications interface 1608 of the RU 106.
The RU 106 may include an RU processor 1606, which may have on-chip memory 1606'. In some aspects, the RU 106 may further include an additional module of memory 1616, the communications interface 1608, and one or more transceivers 1630, all of which may be coupled to the RU processor 1606. The RU 106 may further include antennas 1640, which may be coupled to the one or more transceivers 1630, such that the RU 106 can communicate through the one or more transceivers 1630 via the antennas 1640 with the UE 102.
The on-chip memory 1606', 1626', 1646' and the additional modules of memory 1616, 1636, 1656 may each be considered a computer-readable medium /memory. Each computer-readable medium /memory may be non-transitory. Each of the processors 1606, 1626, 1646 is responsible for general processing, including execution of software stored on the computer-readable medium /memory. The software, when executed by the corresponding processor (s) 1606, 1626, 1646 causes the processor (s) 1606, 1626, 1646 to perform the various functions described herein. The computer-readable medium /memory may also be used for storing data that is manipulated by the processor (s) 1606, 1626, 1646 when executing the software. In examples, the UCI reception component 150 may sit at any of the one or more network entities 104, such as at the CU 110; both the CU 110 and the DU 108; each of the CU 110, the DU 108, and the RU 106; the DU 108; both the DU 108 and the RU 106; or the RU 106.
As discussed in FIG. 1 and implemented with respect to FIG. 14, the UCI reception component 150 is configured to transmit, to a UE, a first indication that schedules a first PUSCH associated with a first CORESET pool, the first PUSCH overlapping in time with a PUCCH associated with a second CORESET pool different from the first CORESET pool. The UCI reception component 150 is configured to transmit, to the UE, a second indication that schedules a second PUSCH associated with the second CORESET pool, the second PUSCH overlapping in time with the PUCCH. The UCI reception component 150 is configured to receive, from the UE, an uplink communication associated with a UCI multiplexing scheme based on the first PUSCH overlapping in time with the PUCCH.
The UCI reception component 150 may be within one or more processors of the one or more network entities 104, such as the RU processor 1606 (e.g., at 150a) , the DU processor 1626 (e.g., at 150b) , and/or the CU processor 1646 (e.g., at 150c) . The UCI reception component 150a-150c may be one or more hardware components specifically configured to carry out the stated processes/algorithm, implemented by one or more processors 1606, 1626, 1646 configured to perform the stated processes/algorithm, stored within a computer-readable medium for implementation by the one or more processors 1606, 1626, 1646, or a combination thereof.
The specific order or hierarchy of blocks in the processes and flowcharts disclosed herein is an illustration of example approaches. Hence, the specific order or hierarchy of blocks in the processes and flowcharts may be rearranged. Some blocks may also be combined or deleted. Dashed lines may indicate optional elements of the diagrams. The accompanying method claims present elements of the various blocks in an example order and are not limited to the specific order or hierarchy presented in the claims, processes, and flowcharts.
The detailed description set forth herein describes various configurations in connection with the drawings and does not represent the only configurations in which the concepts described herein may be practiced. The detailed description includes specific details for the purpose of providing a thorough explanation of various concepts. However, these concepts may be practiced without these specific details. In some instances, well known structures and components are shown in block diagram form in order to avoid obscuring such concepts.
Aspects of wireless communication systems, such as telecommunication systems, are presented with reference to various apparatuses and methods. These apparatuses and methods are described in the following detailed description and are illustrated in the accompanying drawings by various blocks, components, circuits, processes, call flows, systems, algorithms, etc. (collectively referred to as “elements” ) . These elements may be implemented using electronic hardware, computer software, or combinations thereof. Whether such elements are implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system.
An element, or any portion of an element, or any combination of elements may be implemented as a “processing system” that includes one or more processors. Examples of processors include microprocessors, microcontrollers, graphics processing units (GPUs) , central processing units (CPUs) , application processors, digital signal processors (DSPs) , reduced instruction set computing (RISC) processors, systems-on-chip (SoC) , baseband processors, field programmable gate arrays (FPGAs) , programmable logic devices (PLDs) , state machines, gated logic, discrete hardware circuits, and other similar hardware configured to perform the various functionality described throughout this disclosure. One or more processors in the processing system may execute software, which may be referred to as software, firmware, middleware, microcode, hardware description language, or otherwise. Software shall be construed broadly to mean instructions, instruction sets, code, code segments, program code, programs, subprograms, software components, applications, software applications, software packages, routines, subroutines, objects, executables, threads of execution, procedures, functions, or any combination thereof.
If the functionality described herein is implemented in software, the functions may be stored on, or encoded as, one or more instructions or code on a computer-readable medium, such as a non-transitory computer-readable storage medium. Computer-readable media includes computer storage media and can include a random-access memory (RAM) , a read-only memory (ROM) , an electrically erasable programmable ROM (EEPROM) , optical disk storage, magnetic disk storage, other magnetic storage devices, combinations of these types of computer-readable media, or any other medium that can be used to store computer executable code in the form of instructions or data structures that can be accessed by a computer. Storage media may be any available media that can be accessed by a computer.
Aspects, implementations, and/or use cases described herein may be implemented across many differing platform types, devices, systems, shapes, sizes, and packaging arrangements. For example, the aspects, implementations, and/or use cases may come about via integrated chip implementations and other non-module-component based devices, such as end-user devices, vehicles, communication devices, computing devices, industrial equipment, retail/purchasing devices, medical devices, artificial intelligence (AI) -enabled devices, machine learning (ML) -enabled devices, etc. The aspects, implementations, and/or use cases may range from chip-level or modular components to non-modular or non-chip-level implementations, and further to aggregate, distributed, or original equipment manufacturer (OEM) devices or systems incorporating one or more techniques described herein.
Devices incorporating the aspects and features described herein may also include additional components and features for the implementation and practice of the claimed and described aspects and features. For example, transmission and reception of wireless signals necessarily includes a number of components for analog and digital purposes, such as hardware components, antennas, RF-chains, power amplifiers, modulators, buffers, processor (s) , interleavers, adders/summers, etc. Techniques described herein may be practiced in a wide variety of devices, chip-level components, systems, distributed arrangements, aggregated or disaggregated components, end-user devices, etc., of varying configurations.
The description herein is provided to enable a person skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects. Thus, the claims are not limited to the aspects described herein, but are to be interpreted in view of the full scope of the present disclosure consistent with the language of the claims.
Reference to an element in the singular does not mean “one and only one” unless specifically stated, but rather “one or more. ” Terms such as “if, ” “when, ” and “while” do not imply an immediate temporal relationship or reaction. That is, these phrases, e.g., “when, ” do not imply an immediate action in response to or during the occurrence of an action, but simply imply that if a condition is met then an action will occur, but without requiring a specific or immediate time constraint for the action to occur. The terms “may” , “might” , and “can” , as used in this disclosure, often carry certain connotations. For example, “may” refers to a permissible feature that may or may not occur, “might” refers to a feature that probably occurs, and “can” refers to a capability (e.g., capable of) . The phrase “For example” often carries a similar connotation to “may” and, therefore, “may” is sometimes excluded from sentences that include “for example” or other similar phrases.
Unless specifically stated otherwise, the term “some” refers to one or more. Combinations such as “at least one of A, B, or C” or “one or more of A, B, or C” include any combination of A, B, and/or C, such as A and B, A and C, B and C, or A and B and C, and may include multiples of A, multiples of B, and/or multiples of C, or may include A only, B only, or C only. Sets should be interpreted as a set of elements where the elements number one or more.
Unless otherwise specifically indicated, ordinal terms such as “first” and “second” do not necessarily imply an order in time, sequence, numerical value, etc., but are used to distinguish between different instances of a term or phrase that follows each ordinal term. Reference numbers, as used in the specification and figures, are sometimes cross-referenced among drawings to denote same or similar features. A feature that is exactly the same in multiple drawings may be labeled with the same reference number in the multiple drawings. A feature that is similar among the multiple drawings, but not exactly the same, may be labeled with reference numbers that have different leading numbers, but have one or more of the same trailing numbers (e.g., 206, 306, 406, etc., may refer to similar features in the drawings) .
Structural and functional equivalents to elements of the various aspects described throughout this disclosure that are known or later come to be known to those of ordinary skill in the art are expressly incorporated herein by reference and are encompassed by the claims. The words “module, ” “mechanism, ” “element, ” “device, ” and the like may not be a substitute for the word “means. ” As such, no claim element is to be construed as a means plus function unless the element is expressly recited using the phrase “means for. ” As used herein, the phrase “based on” shall not be construed as a reference to a closed set of information, one or more conditions, one or more factors, or the like. In other words, the phrase “based on A” , where “A” may be information, a condition, a factor, or the like, shall be construed as “based at least on A” unless specifically recited differently.
The following examples are illustrative only and may be combined with other examples or teachings described herein, without limitation.
Example 1 is a method of wireless communication at a user equipment (UE) , comprising receiving, from a network entity, a first indication that schedules a first PUSCH associated with a first CORESET pool, the first PUSCH overlapping in time with a PUCCH associated with a second CORESET pool different from the first CORESET pool and transmitting, to the network entity, an uplink communication associated with a UCI multiplexing scheme based on the first PUSCH overlapping in time with the PUCCH, without obtaining a second indication that schedules a second PUSCH associated with the second CORESET pool, the second PUSCH overlapping in time with the PUCCH.
Example 2 may be combined with Example 1 and includes the uplink communication includes at least one of the PUCCH, the first PUSCH without UCI multiplexing, the first PUSCH with UCI multiplexing, the PUCCH and the first PUSCH without UCI multiplexing or the PUCCH and the first PUSCH with UCI multiplexing.
Example 3 may be combined with any of Examples 1-2 and further includes further includes receiving, from the network entity, a configuration identifying the uplink communication, wherein the configuration is based on at least one of the UE being configured for joint HARQ feedback, the UE being configured for separate HARQ feedback, the UCI comprising CSI, the UCI comprising HARQ feedback, the UE being configured for UCI multiplexing, a priority associated with content of the first PUSCH, or a priority associated with content of the UCI.
Example 4 may be combined with any of Examples 1-3 and further includes the first indication comprises a first downlink control information (DCI) and the second indication comprises a second DCI.
Example 5 may be combined with any of Examples 1-4 and further includes receiving the first indication via a dedicated DCI or a MAC-CE and the first indication indicates a scheduling status for a plurality of slots for the first PUSCH associated with the first CORESET pool and the second PUSCH associated with the second CORESET pool.
Example 6 may be combined with any of Examples 1-4 and further includes the first indication implicitly indicates, based on resources associated with the first indication, a scheduling status for the second PUSCH.
Example 7 may be combined with any of Examples 1-6 and further includes the first CORESET pool is associated with a first transmission/reception point (TRP) and the second CORESET pool is associated with a second TRP different from the first TRP.
Example 8 may be combined with any of Examples 1-7 and further includes transmitting, to the network entity, a UE capability indicator indicating support for at least one of uplink control information (UCI) multiplexing for multiple downlink control information (DCI) based PUSCH transmission, UCI multiplexing for joint hybrid automatic repeat request (HARQ) feedback mode, UCI multiplexing for separate HARQ feedback mode or UCI multiplexing for overlapping scheduled PUCCH and scheduled PUSCH associated with different CORESET pools.
Example 9 may be combined with any of Examples 1-8 and further includes receiving, from the network entity, a configuration associated with the first CORESET pool, the second CORESET pool and a hybrid automatic repeat request (HARQ) feedback mode.
Example 10 may be combined with any of Examples 1-9 and further includes the first indication indicates a scheduling status for the second PUSCH associated with the second CORESET pool or the second indication indicates a scheduling status for the first PUSCH associated with the first CORESET pool.
Example 11 may be combined with any of Examples 1-10 and further includes receiving, from the network entity, a third indication that schedules the PUCCH.
Example 12 may be combined with any of Examples 1-11 and further includes receiving, from the network entity, a configured grant for a third PUSCH associated with the first CORESET pool, wherein the UCI multiplexing scheme is further based on the third PUSCH, wherein the transmitting the uplink communication comprises transmitting the third PUSCH multiplexed with the UCI.
Example 13 is a method of wireless communication at a network entity (104) , comprising transmitting, to a UE, a first indication that schedules a first PUSCH associated with a first CORESET pool, the first PUSCH overlapping in time with a PUCCH associated with a second CORESET pool different from the first CORESET pool and transmitting, to the UE, a second indication that schedules a second PUSCH associated with the second CORESET pool, the second PUSCH overlapping in time with the PUCCH and receiving, from the UE, an uplink communication associated with a UCI multiplexing scheme based on the first PUSCH overlapping in time with the PUCCH.
Example 14 may be combined with Example 13 and further includes the uplink communication includes at least one of the PUCCH, the first PUSCH without UCI multiplexing, the first PUSCH with UCI multiplexing, the PUCCH and the first PUSCH without UCI multiplexing or the PUCCH and the first PUSCH with UCI multiplexing.
Example 15 may be combined with any of Examples 13-14 and further includes further includes transmitting, to the UE, a configuration identifying the uplink communication, wherein the configuration is based on at least one of the UE being configured for joint HARQ feedback, the UE being configured for separate HARQ feedback, the UCI comprising CSI, the UCI comprising HARQ feedback, the UE being configured for UCI multiplexing, a priority associated with content of the first PUSCH, or a priority associated with content of the UCI.
Example 16 may be combined with any of Examples 13-15 and further includes the first indication comprises a first downlink control information (DCI) and the second indication comprises a second DCI.
Example 17 may be combined with any of Examples 13-16 and further includes transmitting the first indication via a dedicated DCI or a MAC-CE and the first indication indicates a scheduling status for a plurality of slots for the first PUSCH associated with the first CORESET pool and the second PUSCH associated with the second CORESET pool.
Example 18 may be combined with any of Examples 13-17 and further includes the first indication implicitly indicates, based on resources associated with the first indication, a scheduling status for the second PUSCH.
Example 19 may be combined with any of Examples 13-18 and further includes the first CORESET pool is associated with a first TRP and the second CORESET pool is associated with a second TRP different from the first TRP.
Example 20 may be combined with any of Examples 13-19 and further includes receiving, from the UE, a UE capability indicator indicating support for at least one of uplink control information (UCI) multiplexing for multiple downlink control information (DCI) based PUSCH transmission, UCI multiplexing for joint hybrid automatic repeat request (HARQ) feedback mode, UCI multiplexing for separate HARQ feedback mode or UCI multiplexing for overlapping scheduled PUCCH and scheduled PUSCH associated with different CORESET pools.
Example 21 may be combined with any of Examples 13-20 and further includes transmitting, to the UE, a configuration associated with the first CORESET pool, the second CORESET pool and a HARQ feedback mode.
Example 22 may be combined with any of Examples 13-21 and further includes the first indication indicates a scheduling status for the second PUSCH associated with the second CORESET pool or the second indication indicates a scheduling status for the first PUSCH associated with the first CORESET pool.
Example 23 may be combined with any of Examples 13-22 and further includes transmitting, to the UE, a third indication that schedules the PUCCH.
Example 24 may be combined with any of Examples 13-23 and further includes transmitting, to the UE, a configured grant for a third PUSCH associated with the first CORESET pool, wherein the UCI multiplexing scheme is further based on the third PUSCH, wherein the receiving the uplink communication comprises receiving the third PUSCH multiplexed with the UCI.
Example 25 may be combined with any of Examples 13-24 and further includes transmitting, to the UE, a third indication that schedules UCI on the PUCCH associated with the second CORESET pool, wherein the receiving the uplink communication associated with the UCI multiplexing scheme is only based on the first PUSCH overlapping in time with the PUCCH.
Example 26 is an apparatus for wireless communication for implementing a method as in any of Examples 1-25.
Example 27 is an apparatus for wireless communication including means for implementing a method as in any of Examples 1-25.
Example 28 is a non-transitory computer-readable medium storing computer executable code, the code when executed by a processor causes the processor to implement a method as in any of Examples 1-25.

Claims

A method of wireless communication at a user equipment (UE) , comprising:

receiving (1215) , from a network entity (104) , a first indication that schedules a first physical uplink shared channel (PUSCH) associated with a first control resource set (CORESET) pool, the first PUSCH overlapping in time with a physical uplink control channel (PUCCH) associated with a second CORESET pool different from the first CORESET pool; and

transmitting (1235) , to the network entity (104) , an uplink communication associated with an uplink control information (UCI) multiplexing scheme based on the first PUSCH overlapping in time with the PUCCH, without obtaining a second indication that schedules a second PUSCH associated with the second CORESET pool, the second PUSCH overlapping in time with the PUCCH.
The method of claim 1, wherein the uplink communication comprises at least one of:

the PUCCH;

the first PUSCH without UCI multiplexing;

the first PUSCH with UCI multiplexing;

the PUCCH and the first PUSCH without UCI multiplexing; or

the PUCCH and the first PUSCH with UCI multiplexing.
The method of any of claims 1 to 2, further comprising:

receiving (1210) , from the network entity (104) , a configuration identifying the uplink communication, wherein the configuration is based on at least one of:

the UE (102) being configured for joint hybrid automatic repeat request (HARQ) feedback;

the UE (102) being configured for separate HARQ feedback;

the UCI comprising channel state information (CSI) ;

the UCI comprising HARQ feedback;

the UE (102) being configured for UCI multiplexing;

a priority associated with content of the first PUSCH; or

a priority associated with content of the UCI.
The method of any of claims 1 to 3, wherein:

the first indication comprises a first downlink control information (DCI) ; and

the second indication comprises a second DCI.
The method of any of claims 1 to 4, wherein:

the receiving (1215) the first indication comprises receiving the first indication via a dedicated downlink control information (DCI) or a medium access control-control element (MAC-CE) ; and

the first indication indicates a scheduling status for a plurality of slots for the first PUSCH associated with the first CORESET pool and the second PUSCH associated with the second CORESET pool.
The method of any of claims 1 to 4, wherein the first indication implicitly indicates, based on resources associated with the first indication, a scheduling status for the second PUSCH.
The method of any of claims 1 to 6, wherein:

the first CORESET pool is associated with a first transmission/reception point (TRP) ; and

the second CORESET pool is associated with a second TRP different from the first TRP.
The method of any of claims 1 to 7, further comprising:

transmitting (1205) , to the network entity (104) , a UE (102) capability indicator indicating support for at least one of:

uplink control information (UCI) multiplexing for multiple downlink control information (DCI) based PUSCH transmission;

UCI multiplexing for joint hybrid automatic repeat request (HARQ) feedback mode;

UCI multiplexing for separate HARQ feedback mode; or

UCI multiplexing for overlapping scheduled PUCCH and scheduled PUSCH associated with different CORESET pools.
The method of any of claims 1 to 8, further comprising:

receiving (1210) , from the network entity (104) , a configuration associated with:

the first CORESET pool;

the second CORESET pool; and

a hybrid automatic repeat request (HARQ) feedback mode.
The method of any of claims 1 to 9, wherein at least one of:

the first indication indicates a scheduling status for the second PUSCH associated with the second CORESET pool; or

the second indication indicates a scheduling status for the first PUSCH associated with the first CORESET pool.
The method of any of claims 1 to 10, further comprising:

receiving (1225) , from the network entity (104) , a third indication that schedules the PUCCH.
The method of any of claims 1 to 11, further comprising:

receiving (1210) , from the network entity (104) , a configured grant for a third PUSCH associated with the first CORESET pool, wherein the UCI multiplexing scheme is further based on the third PUSCH, wherein the transmitting (1235) the uplink communication comprises transmitting the third PUSCH multiplexed with the UCI.
A method of wireless communication at a network entity (104) , comprising:

transmitting (1215) , to a user equipment (UE) (102) , a first indication that schedules a first physical uplink shared channel (PUSCH) associated with a first control resource set (CORESET) pool, the first PUSCH overlapping in time with a physical uplink control channel (PUCCH) associated with a second CORESET pool different from the first CORESET pool;

transmitting (1220) , to the UE (102) , a second indication that schedules a second PUSCH associated with the second CORESET pool, the second PUSCH overlapping in time with the PUCCH; and

receiving (1235) , from the UE (102) , an uplink communication associated with an uplink control information (UCI) multiplexing scheme based on the first PUSCH overlapping in time with the PUCCH.
The method of claim 13, wherein the uplink communication comprises at least one of:

the PUCCH;

the first PUSCH without UCI multiplexing;

the first PUSCH with UCI multiplexing;

the PUCCH and the first PUSCH without UCI multiplexing; or

the PUCCH and the first PUSCH with UCI multiplexing.
The method of any of claims 13 to 14, further comprising:

transmitting (1210) , to the UE (102) , a configuration identifying the uplink communication, wherein the configuration is based on at least one of:

the UE (102) being configured for joint hybrid automatic repeat request (HARQ) feedback;

the UE (102) being configured for separate HARQ feedback;

the UCI comprising channel state information (CSI) ;

the UCI comprising HARQ feedback;

the UE (102) being configured for UCI multiplexing;

a priority associated with content of the first PUSCH; or

a priority associated with the content of the UCI.
The method of any of claims 13 to 15, wherein:

the first CORESET pool is associated with a first transmission/reception point (TRP) ; and

the second CORESET pool is associated with a second TRP different from the first TRP.
The method of any of claims 13 to 16, wherein at least one of:

the first indication indicates a scheduling status for the second PUSCH associated with the second CORESET pool; or

the second indication indicates a scheduling status for the first PUSCH associated with the first CORESET pool.
The method of any of claims 13 to 17, further comprising:

transmitting, to the UE, a third indication that schedules UCI on the PUCCH associated with the second CORESET pool;

wherein the receiving the uplink communication associated with the UCI multiplexing scheme is only based on the first PUSCH overlapping in time with the PUCCH.
An apparatus for wireless communication comprising a transceiver, a memory, and a processor coupled to the transceiver and the memory and configured to implement a method as in any of claims 1-18.