UCI multiplexing on multi-codeword and multi-beam PUSCH

Abstract

The present disclosure provides systems, apparatus, apparatuses, and methods, including computer programs encoded on a storage medium, for multiplexing UCIs (508) for multiple codewords on one or more beams. The UE (102) multiplexes the UCI (508) for the plurality of codewords on the PUSCH resource (202) to generate a multiplexed UCI. The plurality of codewords is associated with the one or more beams. The UE (102) sends (316, 716) the multiplexed UCI (508) to a network entity (104) on the PUSCH resource (202).

Description

Technical Field

[0001] The present disclosure relates generally to wireless communications and, more particularly, to multiplexing uplink control information (UCI) for multiple codewords on one or more beams. Background Art

[0002] The Third Generation Partnership Project (3GPP) has specified a radio interface called Fifth Generation (5G) New Radio (NR) (5G NR). The architecture of a 5G NR wireless communication system includes the 5G Core (5GC) network, the 5G Radio Access Network (5G-RAN), and user equipment (UE). Compared to previous generation cellular communication systems, the 5G NR architecture aims to provide increased data rates, reduced latency, and / or increased capacity.

[0003] Wireless communication systems may generally be configured to provide various telecommunication services (e.g., telephony, video, data, messaging, broadcast, etc.) based on multiple access technologies (such as orthogonal frequency division multiple access (OFDMA) technologies) that support communication with multiple UEs. The advancement of mobile broadband continues the evolution of such wireless communication technologies. For example, a UE may multiplex uplink control information (UCI) on allocated physical uplink shared channel (PUSCH) resources that temporally overlap with physical uplink control channel (PUCCH) resources configured for UCI transmission. However, a UE may be scheduled to transmit using multiple codewords (e.g., with different modulation orders or different coding rates) or on multiple beams, which may result in increased complexity at the UE. Summary of the Invention

[0004] 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 does not identify key or critical elements of all aspects, nor does it delineate 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 will be presented later.

[0005] A network entity, such as a base station or base station unit, can configure a user equipment (UE) to transmit uplink control information (UCI) on a physical uplink control channel (PUCCH) resource. In situations where the PUCCH resource overlaps in time with a physical uplink shared channel (PUSCH) resource allocated to the UE, the UE can transmit UCI to the network entity on the allocated PUSCH resource. The UCI can include information such as a scheduling request, hybrid automatic repeat request-acknowledgement (HARQ-ACK), channel state information (CSI) part 1, and / or CSI part 2.

[0006] Although a UE can send UCI to a network entity on PUSCH resources when the allocated PUSCH resources overlap with PUCCH resources in the time domain, the network entity can also schedule the UE to transmit using multiple codewords (e.g., using different modulation and coding schemes (MCS)) or on multiple beams. Thus, in a multi-codeword scenario, the UE uses codewords that indicate different modulation orders or different target coding rates. In a multi-beam scenario, PUSCH resources can correspond to different UE panels transmitting to different transmit-receive points (TRPs). Therefore, for multi-codeword and / or multi-beam scenarios, sending UCI on allocated PUSCH resources results in increased complexity.

[0007] Various aspects of the present disclosure address the above and other deficiencies by multiplexing UCI for multiple codewords or multiple beams on allocated PUSCH resources, where the allocated PUSCH resources overlap in time with PUCCH resources. In some examples, a network entity can indicate to the UE a multiplexing scheme for multiplexing UCI on PUSCH resources. In other examples, the UE independently determines the multiplexing scheme for UCI associated with multiple codewords or multiple beams.

[0008] According to some aspects, a UE multiplexes UCI for multiple codewords on the UE's allocated PUSCH resources to generate multiplexed UCI, the multiple codewords associated with one or more UEs transmitting the UCI to a network entity on the PUSCH resources based on the multiplexing scheme for the UCI.

[0009] According to some aspects, a network entity sends a configuration for UCI on PUCCH resources to a UE. The network entity receives UCI multiplexed on PUSCH resources from the UE. The UCI is for multiple codewords associated with one or more beams. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Figure 1 A diagram of a wireless communication system including multiple user equipments (UEs) and network entities communicating through one or more cells is shown.

[0011] Figures 2A-2D A diagram showing uplink resources used for sending uplink control information (UCI) is shown.

[0012] Figure 3 A signaling diagram of multi-codeword physical uplink shared channel (PUSCH) transmission based on UCI multiplexing is shown.

[0013] Figures 4A-4C Resource diagrams for codewords with and without UCI are shown.

[0014] Figures 5A-5CA resource diagram showing codewords associated with UCI repetition (or UCI partition) is shown.

[0015] Figures 6A-6C A resource diagram showing codewords associated with hybrid multiplexing of types of UCI is shown.

[0016] Figure 7 A signaling diagram of multi-beam PUSCH transmission based on UCI multiplexing is shown.

[0017] Figures 8A-8C A diagram of resources associated with UCI multiplexing is shown.

[0018] Figures 9A-9C A diagram of resources associated with UCI multiplexing is shown.

[0019] Figure 10 is a flow chart of a method of wireless communication at a UE.

[0020] Figure 11 is a flow chart of a method of wireless communication at a network entity.

[0021] Figure 12 is a diagram illustrating a hardware implementation of an example UE equipment.

[0022] Figure 13 is a diagram illustrating a hardware implementation of one or more example network entities. DETAILED DESCRIPTION

[0023] Figure 1A diagram 100 of a wireless communication system associated with multiple cells 190 is shown. The wireless communication system includes a user equipment (UE) 102 and a base station / network entity 104. Some base stations may include a converged base station architecture, while other base stations may include a disaggregated base station architecture. The converged base station architecture includes a radio unit (RU) 106, a distributed unit (DU) 108, and a centralized unit (CU) 110, which are configured to utilize a radio protocol stack that is physically or logically integrated within a single radio access network (RAN) node. The disaggregated base station architecture utilizes a protocol stack that is physically or logically distributed across two or more units (e.g., RU 106, DU 108, CU 110). For example, CU 110 is implemented within a RAN node, and one or more DUs 108 may be co-located with CU 110, or alternatively, may be geographically or virtually distributed across one or more other RAN nodes. DU 108 may be implemented to communicate with one or more RUs 106. Each of the RU 106, DU 108, and CU 110 may be implemented as a virtual unit, 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., a converged base station or a disaggregated unit of a base station, such as the RU 106, DU 108, or CU 110) may be referred to as a transmission reception point (TRP).

[0024] The operation and / or network design of the base station 104 can be based on the aggregated nature of base station functionality. For example, a disaggregated base station architecture is 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 as a cloud radio access network (C-RAN)). Disaggregation can include distributing functionality between two or more units located at various physical locations, as well as virtually distributing the functionality of at least one unit, which can enable flexibility in network design. Various units of a disaggregated base station architecture or disaggregated RAN architecture can be configured for wired or wireless communication with at least one other unit. For example, the base station 104a / 104e and / or RUs 106a-106d can communicate with UEs 102a-102d and 102s via one or more radio frequency (RF) access links based on a Uu interface. In an example, multiple RUs 106 and / or base stations 104 can simultaneously serve a UE 102, such as via intra-cell and / or inter-cell access links between the UE 102 and the RUs 106 / base stations 104.

[0025] RU 106, DU 108, and CU 110 may include (or may be coupled to) one or more interfaces configured to send or receive information / signals via a wired or wireless transmission medium. Base station 104 or any of the one or more decomposed base station units may be configured to communicate with one or more other base stations 104 or one or more other decomposed base station units via a wired or wireless transmission medium. In an example, a processor, memory, and / or controller associated with executable instructions of the interface may be configured to provide communication between base stations 104 and / or one or more decomposed base station units via a wired or wireless transmission medium. For example, a wired interface may be configured to send or receive information / signals via a wired transmission medium, such as via a fronthaul link 160 between RU 106d and a baseband unit (BBU) 112 of base station 104d associated with cell 190d. The BBU 112 includes the DU 108 and the CU 110, and may also have a wired interface (e.g., a midhaul link) configured between the DU 108 and the CU 110 to transmit or receive information / signals between the DU 108d and the CU 110d. In a further example, a wireless interface, which may include a receiver, a transmitter, or a transceiver (such as an RF transceiver), may be configured to transmit and / or receive information / signals via a wireless transmission medium, such as information transmitted between the RU 106a of the cell 190a and the base station 104e of the cell 190e via the cross-cell communication beams 136-138 of the RU 106a and the base station 104e.

[0026] The RU 106 may be configured to implement lower layer functions. For example, the RU 106 is controlled by the DU 108 and may correspond to a logical node hosting RF processing functions or lower layer PHY functions, such as performing fast Fourier transform (FFT), inverse FFT (iFFT), digital beamforming, physical random access channel (PRACH) extraction and filtering, etc. The functions of the RU 106 may be based on functional partitioning, such as lower layer functional partitioning.

[0027] RU 106 can send or receive over-the-air (OTA) communications with one or more UEs 102. For example, RU 106b of cell 190b communicates with UE 102b of cell 190b via a first communication beam set 132 of RU 106b and a second communication beam set 134b of UE 102b, which may correspond to inter-cell communication beams or, in some examples, cross-cell communication beams. For example, UE 102b of cell 190b can communicate with RU 106a of cell 190a via a third communication beam set 134a of UE 102b and a fourth communication beam set 136 of RU 106a. Both real-time and non-real-time features of control and user plane communications of RU 106 can be controlled by the associated DU 108.

[0028] Any combination of RU 106, DU 108, and CU 110, or any reference to any of them individually, may correspond to base station 104. Thus, base station 104 may include at least one of RU 106, DU 108, or CU 110. Base station 104 provides access to the core network for UE 102. Base station 104 may relay communications between UE 102 and the core network. Base station 104 may be associated with a macro cell of a high-power cellular base station and / or a small cell of a low-power cellular base station. For example, cell 190e may correspond to a macro cell, while cells 190a-190d may correspond to small cells. Small cells include femto cells, pico cells, micro cells, and the like. A cell structure including at least one macro cell and at least one small cell may be referred to as a "heterogeneous network."

[0029] Transmissions from a UE 102 to a base station 104 / RU 106 are referred to as uplink (UL) transmissions, while transmissions from a base station 104 / RU 106 to a 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, RU 106 d utilizes antenna 114 of base station 104 d in cell 190 d to transmit downlink / forward link communications to UE 102 d or receive uplink / reverse link communications from UE 102 d over a Uu interface associated with an access link between UE 102 d and base station 104 d / RU 106 d.

[0030] The communication link between the UE 102 and the base station 104 / RU 106 can be based on multiple-input multiple-output (MIMO) antenna technology, including spatial multiplexing, beamforming, and / or transmit diversity. The communication link can be associated with one or more carriers. The UE 102 and the base station 104 / RU 106 can utilize a spectrum bandwidth of Y MHz (e.g., 5 MHz, 10 MHz, 15 MHz, 20 MHz, 100 MHz, 400 MHz, 800 MHz, 1600 MHz, 2000 MHz, etc.) per carrier, allocated in a carrier aggregation of up to a total of Yx MHz, with x component carriers (CCs) used for communication in each of the uplink and downlink directions. The carriers may or may not be adjacent to each other along the spectrum. In an example, uplink and downlink carriers can be allocated in an asymmetric manner, with more or fewer carriers allocated for the uplink or downlink. The component carriers can include a primary component carrier and one or more secondary component carriers. The primary component carrier may be associated with a primary cell (PCell), and the secondary component carrier may be associated with a secondary cell (SCell).

[0031] Some UEs 102 (such as UEs 102a and 102s) can perform device-to-device (D2D) communication via a sidelink. For example, the sidelink communication / D2D link utilizes the spectrum of a wireless wide area network (WWAN) associated with uplink and downlink communications. The sidelink communication / D2D link can also use one or more sidelink channels, such as a physical sidelink broadcast channel (PSBCH), a physical sidelink discovery channel (PSDCH), a physical sidelink shared channel (PSSCH), and / or a physical sidelink control channel (PSCCH) to transmit information between UEs 102a and 102s. Such sidelink / D2D communication can be performed via various wireless communication systems, such as wireless fidelity (Wi-Fi) systems, Bluetooth systems, long term evolution (LTE) systems, new radio (NR) systems, and the like.

[0032] The electromagnetic spectrum is typically subdivided into different categories, bands, channels, etc. based on the different frequencies / wavelengths associated with the electromagnetic spectrum. Fifth-generation (5G) NR is typically associated with two operating frequency bands (FRs), referred to as Frequency Range 1 (FR1) and Frequency Range 2 (FR2). FR1 ranges from 410 MHz to 7.125 GHz, and FR2 ranges from 24.25 GHz to 71.0 GHz, including FR2-1 (24.25 GHz to 52.6 GHz) and FR2-2 (52.6 GHz to 71.0 GHz). Although a portion of FR1 is actually greater than 6 GHz, FR1 is often referred to as the "sub-6 GHz" band. In contrast, FR2 is often referred to as the "millimeter wave" (mmW) band. FR2 is distinct from the "extremely high frequency" (EHF) band, but is a close subset of it. The EHF band ranges from 30 GHz to 300 GHz and is sometimes also referred to as the "millimeter wave" band. Frequencies between FR1 and FR2 are often referred to as "mid-band" frequencies. The operating band for mid-band frequencies may be referred to as Frequency Range 3 (FR3), which ranges from 7.125 GHz to 24.25 GHz. Frequency bands within FR3 may include characteristics of FR1 and / or FR2. Thus, the features of FR1 and / or FR2 may be extended to mid-band frequencies. Higher operating bands have been identified to extend 5G NR communications above the 52.6 GHz associated with the upper limit of FR2. Three of these higher operating bands include FR2-2 (which ranges from 52.6 GHz to 71.0 GHz), FR4 (which ranges from 71.0 GHz to 114.25 GHz), and FR5 (which ranges from 114.25 GHz to 300 GHz). The upper limit of FR5 corresponds to the upper limit of the EHF band. Therefore, unless otherwise expressly stated herein, the term "sub-6 GHz" may refer to frequencies less than 6 GHz, frequencies within FR1, or frequencies that may include mid-band frequencies. Further, unless otherwise expressly stated herein, the term "millimeter wave" or mmW refers to frequencies that may include mid-band frequencies, frequencies that may be within FR2-1, FR4, FR2-2, and / or FR5, or frequencies that may be within the EHF band.

[0033] UE 102 and base station 104 / RU 106 may each include multiple antennas. The multiple antennas may correspond to antenna elements, antenna panels, and / or antenna arrays that may facilitate beamforming operations. For example, RU 106b may transmit downlink beamformed signals to UE 102b based on a first communication beam set 132 in one or more transmit directions of RU 106b. UE 102b may receive downlink beamformed signals from RU 106b based on a second communication beam set 134b in one or more receive directions of UE 102b. In a further example, UE 102b may also transmit uplink beamformed signals to RU 106b based on a second communication beam set 134b in one or more transmit directions of UE 102b. RU 106b may receive uplink beamformed signals from UE 102b in one or more receive directions of RU 106b.

[0034] UE 102b may perform beam training to determine optimal receive and transmit directions for beamformed signals. The transmit and receive directions of UE 102 and base station 104 / RU 106 may be the same or different. In a further example, beamformed signals may be transmitted between a first base station / RU 106a and a second base station 104e. For example, base station 104e of cell 190e may transmit beamformed signals to RU 106a based on communication beam 138 in one or more transmit directions of base station 104e. RU 106a may receive beamformed signals from base station 104e of cell 190e based on RU communication beam 136 in one or more receive directions of RU 106a. In a further example, base station 104e transmits downlink beamformed signals to UE 102e based on communication beam 138 in one or more transmit directions of base station 104e. The UE 102e receives downlink beamformed signals from the base station 104e in one or more receive directions of the UE 102e based on the UE communication beam 130. The UE 102e may also transmit uplink beamformed signals to the base station 104e in one or more transmit directions of the UE 102e based on the UE communication beam 130, so that the base station 104e can receive the uplink beamformed signals from the UE 102e in one or more receive directions of the base station 104e.

[0035] The base station 104 may include and / or be referred to as a network entity. That is, a “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 first-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, a network device, or other related terms. The base station 104 or an entity at the base station 104 may be implemented as an IAB node, a relay node, a sidelink node, a converged (monolithic) base station having the RU 106 and the BBU 112 including the DU 108 and the CU 110, or as a decomposed base station including one or more RUs 106, DUs 108, and / or CUs 110. A converged or disaggregated set of base stations may be referred to as a next generation radio access network (NG-RAN). In some examples, UE 102a operates in dual connectivity (DC) with base station 104e and base station / RU 106a. In such a case, base station 104e may be a primary node and base station / RU 160a may be a secondary node.

[0036] Uplink / downlink signaling may also be communicated via a satellite positioning system (SPS) 114. In an example, the SPS 114 of cell 190c may communicate with one or more UEs 102, such as UE 102c, and one or more base stations 104 / RUs 106, such as RU 106c. The SPS 114 may correspond to one or more of a global navigation satellite system (GNSS), a global positioning system (GPS), a non-terrestrial network (NTN), or other satellite positioning / location systems. The SPS 114 may be associated with LTE signals, NR signals (e.g., based on round-trip time (RTT) and / or multiple RTTs), wireless local area network (WLAN) signals, a terrestrial beacon system (TBS), sensor-based information, NR enhanced cell ID (NR E-CID) technology, downlink angle of departure (DL-AoD), downlink time difference of arrival (DL-TDOA), uplink time difference of arrival (UL-TDOA), uplink angle of arrival (UL-AoA), and / or other systems, signals, or sensors.

[0037] Still refer to Figure 1In certain aspects, any of the UEs 102 may include an uplink control information (UCI) multiplexing component 140 configured to multiplex UCI for a plurality of codewords on a physical uplink shared channel (PUSCH) resource to generate multiplexed UCI, the plurality of codewords being associated with one or more beams; and to transmit the multiplexed UCI to a network entity on the PUSCH resource.

[0038] In certain aspects, any of the base stations 104 or a network entity of the base station 104 may include a UCI receiving component 150 configured to send a configuration for UCI on a physical uplink control channel (PUCCH) resource to the UE; and receive UCI multiplexed on the PUSCH resources from the UE, the UCI for multiple codewords associated with one or more beams.

[0039] therefore, Figure 1 A wireless communication system is described that can incorporate aspects of one or more of the other figures described herein (such as Figures 2A-9C Further, although the following description may focus on 5G NR, the concepts described herein may be applicable to other similar areas, such as 5G-Advanced and future versions, LTE, LTE-Advanced (LTE-A), and other wireless technologies such as 6G.

[0040] Figures 2A-2D Figures 200-260 illustrate uplink resources for transmitting UCI. A network entity may configure a UE to transmit UCI on a PUCCH 204a (such as in Figure 200) or on a PUSCH 202c (such as in Figure 220) based on UCI multiplexing. UCI may include a scheduling request, a hybrid automatic repeat request-acknowledgement (HARQ-ACK), and channel state information (CSI). Thus, UCI may have seven permutations corresponding 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 a scheduling request on the PUSCH. CSI may also include CSI part 1 and CSI part 2, where CSI part 2 supports variable lengths, such as CSI part 2 only, and may be punctured into two segments using symbols having demodulation reference signal (DMRS) resource elements and data resource elements. If the network entity configures the UE to send UCI on PUCCH 204 and data on PUSCH 202a and / or 202b in overlapping symbols (such as in diagrams 200, 240, 260), the UE may send UCI on PUSCH 202c (such as in diagram 220).

[0041] For single-codeword PUSCH transmission and single-beam PUSCH transmission, the UE sends UCI on the first resource element (RE) of a resource block (RB) and sends data on the remaining REs of the RB in multiple layers based on the same modulation and coding scheme (MCS). The network entity may offset the UCI based on the first beta. , second beta offset and third beta offset To configure the number of REs used for HARQ-ACK, CSI Part 1 and CSI Part 2. To determine the HARQ-ACK coding rate, based on To determine the coding rate of CSI part 1, and based on To determine the coding rate for CSI part 2. The coding rate R and beta offset for the data correspond to the following: In this way, the number of bits of HARQ-ACK with cyclic redundancy check (CRC) can be , Number of bits of CSI part 1 with CRC , Number of bits of CSI part 2 with CRC As well as the coding rate and modulation order To obtain the number of REs for HARQ-ACK , RE number of CSI part 1 and the number of REs in CSI part 2 ,as follows: in, Corresponding to the scaling factor configured by Radio Resource Control (RRC) signaling from the network entity, Corresponds to the number of REs excluding DMRS for PUSCH transmission.

[0042] The network entity may schedule the UE to transmit PUSCH 202 on two codewords, where each codeword may be configured with a different MCS. and the target coding rate R may be different. For a UE capable of transmitting PUSCH 202 from multiple beams simultaneously, the network entity may schedule the UE to transmit the first PUSCH 202a and the second PUSCH 202b from different beams and transmit the PUCCH 204 in overlapping symbols, as shown in Figures 240-260. The network entity may indicate the beam for the PUSCH by indicating a transmission configuration indication or spatial relationship information. The network entity may schedule the UE to transmit the first PUSCH 202a and the second PUSCH 202b according to different transmission configuration indications or spatial relationship information. The first PUSCH 202a and the second PUSCH 202b may come from two different UE panels pointing to two different TRPs. That is, two different PUSCHs 202a-202b may be associated with different TRPs (e.g., based on different CORESETPoolIndex configured by the network entity through RRC signaling).

[0043] refer to Figure 2D , the network entity may also schedule the UE to transmit the first PUSCH 202a and the second PUSCH 202b from different beams, and to transmit the first PUCCH 204a and the second PUCCH 204b in overlapping symbols, as shown in diagram 260. The first PUSCH 202a and the first PUCCH 204a may come from different UE panels than the second PUSCH 202b and the second PUCCH 204b, where different UE panels may point to different TRPs. That is, two different PUSCHs 202a-202b and two different PUCCHs 204a-204b may be associated with different TRPs (e.g., based on different CORESETPoolIndex configured by the network entity through RRC signaling). The PUCCHs 204a-204b may carry the same UCI payload or different UCI payloads corresponding to overlapping or non-overlapping time-frequency resources.

[0044] Thus, UCI multiplexing on multi-codeword PUSCH and multi-beam PUSCH can allow the UE to send UCI on multiple codewords and / or multiple beams. For example, when the first PUCCH 204a and / or the second PUCCH 204b has a resource conflict with the first PUSCH 202a and the second PUSCH 202b from different beams, the UE sends UCI based on the multi-beam PUSCH, as shown in Figures 240-260. Resource conflict refers to communications with overlapping resources (for example, time domain resource conflict can refer to different transmissions with overlapping symbols). UCI multiplexing on multiple codewords and / or multiple beams can reduce latency and overhead for UCI reporting because the UE does not have to send UCI in PUCCH 204 in addition to sending data on PUSCH 202. Thus, Figures 2A-2D Shown with Figure 3 PUSCH resources associated with the signaling process for UCI multiplexing further described in.

[0045] Figure 3 A signaling diagram 300 for multi-codeword PUSCH transmission based on UCI multiplexing is shown. A UE 102 may report 306 to a network entity 104 its UE capabilities for UCI multiplexing on a multi-codeword PUSCH. In other implementations, the network entity 104 may receive an indication of the UE capabilities from a core network, such as from an access and mobility management function (AMF). In still other implementations, the network entity 104 may receive an indication of the UE capabilities from another base station / network entity (e.g., a gNB or eNB). The UE 102 may send 306 a UE capability report (e.g., for UCI multiplexing on a multi-codeword PUSCH) to indicate at least one of the following: whether the UE 102 supports transmitting UCI on a multi-codeword PUSCH; whether the UE 102 supports transmitting UCI on one codeword and / or all codewords of a multi-codeword PUSCH; or, for one-codeword-based UCI multiplexing, whether the UE 102 supports transmitting data in the same REs used for UCI in one codeword in other codewords; and so forth. The UE 102 may report 306 UE capabilities per feature set, per band, per band combination, or per UE.

[0046] The network entity 104 (e.g., based on UE capabilities) indicates 308 the configuration of PUCCH resources for UCI feedback to the UE 102. The network entity 104 may send 308 the configuration of PUCCH resources for UCI feedback via control signaling. The network entity 104 may indicate an RRCReconfiguration message to the UE 102 using RRC signaling or using a system information block (SIB), where the SIB may be a legacy type of SIB (e.g., SIB1) or a different SIB (e.g., SIB J, where J corresponds to an integer greater than 21) sent by the network entity 104.

[0047] For multi-codeword PUSCH transmissions, the network entity 104 may also optionally send 308 a parameter indication to the UE 102, indicating a UCI multiplexing scheme for the multi-codeword PUSCH transmission. For example, the UCI multiplexing scheme may include multiplexing UCI on one codeword of the multi-codeword PUSCH transmission. As another example, the UCI multiplexing scheme may include multiplexing UCI on all codewords of the multi-codeword PUSCH transmission. The network entity 104 may configure the UE 102 based on the parameter indication for the UCI multiplexing scheme via the same or different control signaling than that sent 308 for the configuration of PUCCH resources. For example, the network entity 104 may send 310 a trigger indication for the multi-codeword PUSCH to the UE 102, which may optionally include a parameter indication for multiplexing UCI on the multi-codeword PUSCH. Thus, the network entity 104 may send 310 the parameter indication with the trigger indication, rather than sending 308 the parameter indication with the configuration.

[0048] The network entity 104 may additionally send 312 a second trigger indication to the UE 102 via additional control signaling for triggering UCI feedback from the UE 102. The second trigger indication triggers the PUSCH and PUCCH having overlapping resources in the time domain. In some examples, both the PUSCH and PUCCH resources are configured in the first control signaling sent 308 to the UE 102. The network entity 104 may trigger 310 the PUSCH for the UE 102 to report UCI feedback (e.g., aperiodic CSI or semi-persistent CSI) with or without data. The network entity 104 may send 310-312 the trigger indication based on a medium access control-control element (MAC-CE) or downlink control information (DCI).

[0049] The UE 102 determines whether to multiplex the UCI on the PUSCH based on one or more control signals received 308, 310, 312 by the UE 102 from the network entity 104. Figures 4A-6CFurther details are described regarding a UE determining a UCI multiplexing scheme for a multi-codeword PUSCH. The UE 102 may determine 314 a UCI multiplexing scheme for the multi-codeword PUSCH based on a parameter indication. That is, the UE 102 may determine 314 whether to send 316 UCI on one codeword, multiple codewords, or all codewords of the multi-codeword PUSCH transmission. For example, the UE 102 may send 316 UCI on the PUSCH based on the multi-codeword PUSCH transmission with the determined UCI multiplexing scheme. The network entity 104 may also determine the multiplexing scheme based on a technique configured / indicated to the UE 102 for receiving 318 the multi-codeword PUSCH with multiplexed UCI from the UE 102. Figure 3 shows the signaling process of multi-codeword PUSCH, and Figures 4A-4C The time-frequency resources used for multi-codeword PUSCH are shown.

[0050] Figures 4A-4C Resource diagrams 400-440 are shown for codewords with and without UCI. Figure 4A Can be used with Figure 4B or Figure 4C Pairing. In a first example, the UE can send UCI based on a predefined / fixed codeword. The UCI includes HARQ-ACK 406, CSI part 1 408a, and CSI part 2 408b, as shown in diagram 400. The HARQ-ACK 406 can be associated with a smaller payload size (e.g., less than or equal to 11 bits) or a larger payload size (e.g., greater than 11 bits). The codeword can also include data 402 and DMRS 410. The channel coding used for the UCI is based on the modulation order and coding rate used for the codeword.

[0051] The network entity avoids scheduling multi-codeword PUSCHs with UCI. For example, the network entity schedules UCI with codeword 1 as shown in diagram 400, but avoids scheduling UCI with codeword 2 as shown in diagrams 420-440 (e.g., avoids scheduling two codewords / multiple codewords with UCI in both codewords 1 and 2). Conversely, as shown in diagram 420, REs 430b-430c of codeword 2 corresponding to the same RE 430a used for UCI in codeword 1 may be unavailable REs 430b (e.g., empty / unused REs) for PUSCH rate matching in codeword 2. Alternatively, as shown in diagram 440, REs 430b-430c of codeword 2 corresponding to the same RE 430a used for UCI in codeword 1 may be available REs 430c for data 402 used for PUSCH rate matching in codeword 2.

[0052] For codewords without UCI (e.g., codeword 2), the network entity may configure, through control signaling such as RRC signaling, MAC-CE, or DCI, whether REs 430b-430c corresponding to the same RE 430a used for UCI in a codeword with UCI (e.g., codeword 1) are available REs 430c or unavailable REs 430b for PUSCH rate matching. The UE may report to the network entity its capability to determine whether the same RE 430a used in a codeword with UCI or certain types of UCI (e.g., HARQ-ACK 406, CSI part 1 408a, and / or CSI part 2 408b) is available RE 430c or unavailable RE 430b for PUSCH rate matching. The UE can determine whether the same RE 430a used in a codeword with UCI or some types of UCI is an available RE 430c or an unavailable RE 430b for PUSCH rate matching based on the indicated precoder for PUSCH transmission. If the precoder indicates non-coherent transmission or partially coherent transmission, the UE determines that the REs in other codewords are available REs 430c. Otherwise, the UE determines that the REs in other codewords are unavailable REs 430b. Non-coherent transmission or partially coherent transmission indicates that at least one PUSCH antenna port includes zero-power (ZP) transmission for at least one layer.

[0053] In a second example, the UE may transmit UCI in a codeword determined by the UE, where the channel coding for the UCI is based on the modulation order and coding rate for the codeword determined by the UE. The network entity avoids scheduling a multi-codeword PUSCH with UCI in multiple codewords. That is, the network entity may schedule UCI with codeword 1 as shown in diagram 400, but avoid scheduling multiple codewords with UCI as shown via diagrams 420-440 (e.g., avoid scheduling both codeword 1 and codeword 2 with UCI). The UE selects a codeword based on the MCS used for each codeword. For example, the UE selects the codeword with the highest MCS to transmit UCI. If the MCS used for two codewords is the same, the UE may select the first or last codeword in the codewords.

[0054] In some implementations, the UE selects a codeword based on the number of coded bits per layer or across layers for UCI or some types of UCI (e.g., HARQ-ACK 406, CSI part 1 408a, and / or CSI part 2 408b) in each codeword. If the number of coded bits for multiple codewords is the same, the UE may select the first or last codeword of the multiple codewords. The UE may select the first or last codeword based on the modulation order Qm used for the codeword, the number of layers L used for the codeword, the number of REs used for the HARQ-ACK 406, and the number of coded bits per layer or across layers. , the number of REs used for CSI part 1 408a and the number of REs used for CSI part 2 408b To determine the cross-layer and The corresponding number of coded bits for HARQ-ACK 406 and The corresponding number of coded bits for CSI part 1 408a and The corresponding number of coded bits for CSI part 2 408b is as follows:

[0055] The UE may select a codeword for UCI multiplexing based on measured downlink channel quality, scheduling information, and / or previous transmission status to predict which codeword may have higher channel quality. For example, if a network entity schedules one codeword for initial transmission and another codeword for retransmission, the UE may send UCI on the codeword used for initial transmission, which may indicate that the network entity has successfully received the previous transmission of the codeword. The UE may report the index used for the selected codeword to the network entity via the PUSCH. The network entity may configure N scrambling identifiers (IDs) for the DMRS 410 or data 402 on the PUSCH through RRC signaling. If the UE sends UCI on the Nth codeword, the UE sends the DMRS 410 based on the Nth configured ID. The UE may also semi-statically select a codeword for UCI multiplexing. For example, the UE may indicate the preferred codeword to the network entity through a UE capability report, an RRC message, UE assistance information, or a MAC-CE.

[0056] In a third example, the network entity indicates to the UE the codeword for transmitting UCI. The channel coding used for the UCI is based on the modulation order and coding rate of the indicated codeword. The network entity may indicate the codeword index to be used via RRC signaling (e.g., PUSCH-Config, which provides the configuration for PUSCH transmission in a bandwidth portion, UCI-OnPUSCH, which provides the configuration for UCI multiplexing for dynamically granted PUSCH (i.e., PUSCH scheduled by DCI), and / or CG-UCI-OnPUSCH, which provides the configuration for UCI multiplexing for configured granted PUSCH (i.e., PUSCH with an uplink grant configured by RRC parameters)). The network entity may also optionally configure the codeword index for the UE. If the codeword index is not configured, the UE may transmit UCI on the first codeword. Alternatively, if the codeword index is not configured, this may indicate that UCI transmission on multi-codeword PUSCH is disabled, and the UE may drop PUCCH or PUSCH when PUCCH and PUSCH have overlapping resources in the time domain.

[0057] The network entity may also indicate the codeword index through MAC-CE. The network entity may indicate the serving cell index, the bandwidth part (BWP) index, the codeword index for Type 1 configured grant (CG) PUSCH / Type 2 CG-PUSCH / dynamically granted PUSCH. The network entity may use a single codeword index for common indication to indicate the codeword index for Type 1 CG-PUSCH, Type 2 CG-PUSCH or dynamically granted PUSCH. Alternatively, the network entity may indicate the codeword index for Type 1 CG-PUSCH, Type 2 CG-PUSCH or dynamically granted PUSCH based on a separate codeword index for separate indication. If the codeword index is not configured, the UE may send UCI on the first codeword. Alternatively, if the codeword index is not configured, this may indicate that UCI transmission on multi-codeword PUSCH is disabled, and the UE may drop PUCCH or PUSCH when PUCCH and PUSCH have overlapping resources in the time domain.

[0058] The network entity may further indicate the codeword index through DCI. The DCI may be the same DCI used to schedule the PUSCH. The network entity may use the DCI field to explicitly indicate the codeword index (e.g., the codeword index used for UCI). Alternatively, the network entity may implicitly indicate the codeword index based on the position of the PDCCH (e.g., the starting control channel element (CCE) index). An odd starting CCE index may indicate the first codeword, while an even starting CCE index may indicate the second codeword. Figures 4A-4C shows the UCI of one codeword for a multi-codeword PUSCH transmission, and Figures 5A-5C The UCI of multiple codewords for a multi-codeword PUSCH transmission is shown.

[0059] Figures 5A-5C Resource diagrams 500-540 are shown for codewords associated with UCI repetitions (or UCI partitions) 508a-508b. Figure 5A Can be used with Figure 5B or Figure 5C Pairing. The UE may transmit UCI 508 over multiple codewords (e.g., codeword 1 and codeword 2) based on a first UCI repetition 508a as shown in diagram 500 and a second UCI repetition 508b as shown in diagrams 520-540. The channel coding used for the UCI 508 is based on the modulation order and coding rate used for the multiple codewords. The network entity may configure a common set of beta offsets and scaling factors for the UCI 508 in the multiple codewords, or a separate set of beta offsets and scaling factors for the UCI 508 in each codeword.

[0060] Diagram 500 shows an example for codeword 1, while diagrams 520-540 show different examples for codeword 2. The UE may transmit UCI repetitions 508 via multiple codewords. For UCI 508 associated with an N-codeword PUSCH, the UE transmits N UCI repetitions 508. The UE may transmit a second UCI repetition 508b, as shown in diagram 520, in the same REs as used for the first UCI repetition 508a, as shown in diagram 500, or in different REs, as shown in diagram 540. The codeword may also include data 402 and DMRS 410.

[0061] The UE may calculate the number of REs per layer or across layers for UCI 508 based on the number of REs per layer or across layers for the codeword. The UE may also determine the index for the codeword. In other examples, the UE calculates the number of REs per layer or across layers for UCI 508 based on the maximum, minimum, or average number of REs per layer or across layers for the codeword according to the MCS for the codeword. The number of REs per layer for UCI 508 is indicated as , where the number of REs for UCI 508 in each layer is Can be calculated based on: or or Where J indicates the number of codewords.

[0062] The network entity may configure the number of REs used for UCI repetition 508 (or UCI partitioning) in each codeword via RRC signaling, MAC-CE, or DCI. The network entity may also configure whether the number of REs used for UCI 508 is the same for all codewords, or whether the UE determines the number of REs individually for each codeword based on the configuration. The UE may report the requested or supported number of REs for UCI repetition 508 (or UCI partitioning) in each codeword to the network entity via UE capabilities or UE assistance information. The UE may also report whether the UE supports the number of REs used for UCI repetition 508 (or UCI partitioning) being the same for all codewords, or whether the UE determines the number of REs individually for each codeword based on the configuration.

[0063] In some implementations, the UE transmits portions of UCI 508 (e.g., UCI partitions) within a codeword. For example, in diagram 500, the UE may transmit UCI part 1 508a for codeword 1, and in diagrams 520-540, the UE may transmit UCI part 2 508b for codeword 2. For UCI 508 on a PUSCH with N codewords, the UE may partition the UCI 508 into N parts and transmit each part within a corresponding codeword. If the UCI 508 includes HARQ-ACK, CSI part 1, and CSI part 2, the UE may similarly partition the HARQ-ACK into N parts, CSI part 1 into N parts, and CSI part 2 into N parts, transmitting each part within a corresponding codeword. In other implementations, the UE transmits each part of UCI 508 within each codeword. If the UCI includes HARQ-ACK, CSI part 1, and CSI part 2, the UE divides the HARQ-ACK into N parts, divides the CSI part 1 into N parts, and divides the CSI part 2 into N parts, and sends each of the N parts in each of the N codewords.

[0064] The network entity may configure / indicate to the UE whether to transmit UCI 508 based on a UCI repetition technique or a UCI partitioning technique via RRC signaling, MAC-CE, or DCI. In an example, the network entity may configure the UCI transmission scheme (e.g., repetition or partitioning based on spatial domain multiplexing (SDM)) via PUSCH-Config, UCI-OnPUSCH, or CG-UCI-OnPUSCH. In other examples, the network entity may use a DCI field to indicate the UCI transmission scheme. The UE may report supported UCI transmission schemes via a UE capability report and / or UE assistance information.

[0065] Figures 6A-6C Resource diagrams 600-640 of codewords associated with hybrid multiplexing of types of UCI are shown. Figure 6A Can be used with Figure 6B or Figure 6C Pairing. In addition, Figure 6A Can be used with Figure 5A The UCI 630 for codeword 1 corresponds to HARQ-ACK 406, CSI part 1 408a, and CSI part 2 408b, as shown in diagram 600, while the CSI part 408 for codeword 2 corresponds to CSI part 1 408a and CSI part 2 408b, as shown in diagrams 620-640, without HARQ-ACK 406. Resource diagrams 600-640 also include data 402 and DMRS 410.

[0066] The UE may transmit some types of UCI 630 in one codeword of a multi-codeword PUSCH transmission, such as a first HARQ-ACK 406 with a smaller payload size (e.g., less than or equal to 11 bits), a second HARQ-ACK 406 with a larger payload size (e.g., greater than 11 bits), CSI-part 1 408a, and / or CSI-part 2 408b, and other combinations of UCI types 408 in multiple codewords of a multi-codeword PUSCH transmission. In some examples, UCI transmission based on a single codeword or multiple codewords is predefined. In other examples, the network entity configures the UE to transmit UCI 630 based on a single codeword or multiple codewords via RRC signaling. The UE may report its capabilities for single-codeword and multi-codeword UCI transmission to the network entity.

[0067] The UE can determine the resource mapping mode for single-codeword transmission and multi-codeword transmission. For UCI 630 in single-codeword transmission, if the RE used for HARQ-ACK 406 in diagram 600 is an available RE for PUSCH rate matching in other codewords, the UE can send data 402 at an available RE in the other codeword, as shown in diagram 620. Alternatively, the UE can send CSI 408 (e.g., CSI part 2 408b) at an available RE in the other codeword, as shown in diagram 640. Figure 3-6C For multi-codeword PUSCH transmission, Figure 7-9C For multi-beam PUSCH transmission.

[0068] Figure 7 A signaling diagram 700 is shown for multi-beam PUSCH transmission based on UCI multiplexing. Figure 7 and Figure 3 Similarly, because multi-beam PUSCH transmission can use the same number of codewords as the number of beams (i.e., multiple codewords). In other examples, UCI multiplexing is based on a multiplexing scheme in which the number of codewords is not the same as the number of beams. The UE 102 may report 706 to the network entity 104 its UE capabilities for UCI multiplexing on multi-beam PUSCH. In other implementations, the network entity 104 may receive an indication of UE capabilities from the core network, such as from the AMF. In still other implementations, the network entity 104 may receive an indication of UE capabilities from another base station / network entity (e.g., a gNB or eNB). The UE capability report may indicate whether the UE 102 supports transmitting UCI on a multi-beam based PUSCH and / or whether the UE 102 supports transmitting UCI on a single PUSCH or multiple PUSCHs with different beams. The UE 102 may report 706 the UE capabilities per feature set, per frequency band, per frequency band combination, or per UE.

[0069] The network entity 104 (e.g., based on UE capabilities) indicates 708 the configuration of PUCCH resources for UCI feedback to the UE 102. The network entity 104 may send 708 the configuration of PUCCH resources for UCI feedback via control signaling. The network entity 104 may use RRC signaling to indicate an RRCReconfiguration message to the UE 102 or use a SIB, where the SIB may be a legacy type SIB (e.g., SIB1) or a different SIB (e.g., SIB J, where J corresponds to an integer greater than 21) sent by the network entity 104.

[0070] For multi-beam PUSCH transmission, the network entity 104 may also optionally send 708 a parameter indication to the UE 102, the parameter indication indicating a UCI multiplexing scheme for the multi-beam PUSCH transmission. The network entity 104 may configure the UE 102 based on the parameter indication for the UCI multiplexing scheme via the same or different control signaling than that sent 708 for the configuration of the PUCCH resources. For example, the network entity 104 may send 710a-710b a first trigger indication for a first PUSCH on a first beam of the multi-beam PUSCH and / or a second trigger indication for a second PUSCH on a second beam of the multi-beam PUSCH to the UE 102. The transmissions 710a-710b may also optionally include a parameter indication for UCI multiplexing on the multi-beam PUSCH. Thus, the network entity 104 may send 710a-710b parameter indications with one or more of the trigger indications, rather than sending 708 the parameter indications with the configuration.

[0071] The network entity 104 may additionally send 712 a third trigger indication to the UE 102 via additional control signaling for triggering UCI feedback from the UE 102. The third trigger indication triggers at least one PUCCH transmission having overlapping resources with the PUSCH transmission in the time domain. In some examples, both the PUSCH and PUCCH resources are configured in the first control signaling sent 708 to the UE 102. The network entity 104 may trigger 710a-710b the PUSCH for the UE 102 to report UCI feedback with or without data (e.g., aperiodic CSI or semi-persistent CSI). The network entity 104 may send 710a, 710b, 712 trigger indications based on MAC-CE or DCI.

[0072] The UE 102 determines 714 how to multiplex UCI associated with the PUCCH resources on the PUSCH based on one or more control signals received 708, 710a-710b, 712 by the UE 102 from the network entity 104. Figures 8A-9CFurther details are described regarding a UE determining a UCI multiplexing scheme for a multi-beam PUSCH. UE 102 may transmit UCI on one or more PUSCHs. In an example, UE 102 determines 714 a UCI multiplexing scheme for the multi-beam PUSCH based on a parameter indication. UE 102 may transmit 716 a multi-beam PUSCH transmission with UCI multiplexing to network entity 104. Network entity 104 may also determine the multiplexing scheme based on a technique configured / indicated to UE 102 for receiving 718 the multi-beam PUSCH with multiplexed UCI from UE 102. Figure 7 shows the signaling process of multi-beam PUSCH, and Figures 8A-8C PUSCH resources for multi-beam PUSCH are shown.

[0073] Figures 8A-8C Resource diagrams 800 - 820 associated with UCI multiplexing are shown. Figure 8A Can be used with Figure 8B or Figure 8C Pairing. As shown in diagram 800, the UE can transmit UCI associated with the PUCCH 204 via one of the PUSCHs 202a-202b with data according to predefined rules. The channel coding used for the UCI is based on the modulation order and coding rate used for the selected PUSCHs 205a-205b with data and UCI. For example, the UE selects the first PUSCH 202a with data from diagram 800 as the first PUSCH 205a with data and UCI in diagram 820, and the UE selects the second PUSCH 202b with data from diagram 800 as the second PUSCH 205b with data and UCI in diagram 840.

[0074] The UE may select a PUSCH 205 for UCI multiplexing based on the time domain resources used for the PUSCH 202. For example, the UE may select the PUSCH 205a that starts or ends first in time to reduce UCI reporting latency, as shown in diagram 820. In other examples, the UE selects a PUSCH 205b that starts or ends later in time to reduce UE complexity for UCI preparation, as shown in diagram 840. If two PUSCHs 205 start or end at the same time, the UE may select the PUSCH 205 based on a beam index (e.g., the PUSCH 205 associated with the first or last transmission configuration indicator (TCI) or a TCI with a lower or higher ID among the TCIs indicated for the two PUSCHs 205).

[0075] The UE may select a PUSCH 205 for UCI multiplexing based on the indicated TCI IDs for the PUSCH 202 and the PUCCH 204. In an example, the first PUSCH 202a may have a TCI ID of 2, the second PUSCH 202b may have a TCI ID of 1, and the PUCCH 204 may have a TCI ID of 2. The UE may select the first PUSCH 202a having the same TCI ID as the PUCCH 204 or having a TCI that shares the same quasi-co-located (QCL) source reference signal as the PUCCH 204. The network entity may avoid scheduling the PUCCH 204 and the PUSCH 202 with different beams. In other examples, the UE selects one of the PUSCHs 202 based on whether the particular PUSCH has the first or last TCI, or the lowest or highest TCI ID among the TCI IDs indicated for the two PUSCHs 202.

[0076] The UE may also select a PUSCH 205 for UCI multiplexing based on the TRP IDs (e.g., CORESETPoolIndex) for the PUSCH 202 and the PUCCH 204. In an example, the first PUSCH 202a may have a TRP ID of 2, the second PUSCH 202b may have a TRP ID of 1, and the PUCCH 204 may have a TRP ID of 2. The network entity may configure the TRP IDs for the first PUSCH 202a, the second PUSCH 202b, and the PUCCH 204 through RRC signaling or MAC-CE. In other examples, the UE determines the TRP IDs for the PUSCH 202 and the PUCCH 204 based on the TRP ID used to schedule the physical downlink control channel (PDCCH). In yet other examples, the UE may determine the TRP ID based on the content of the PUCCH 204. For example, the UE may determine the TRP ID based on the TRP ID of the measured downlink signal for HARQ-ACK or CSI. The UE may select the PUSCH 202 having the same TRP ID as the PUCCH 204 .

[0077] The UE may also select a PUSCH 205 for UCI multiplexing based on the MCS used for each PUSCH 202. That is, the UE may select a PUSCH 202 with a higher MCS to transmit the PUSCH 205 with UCI. If two PUSCHs 202 are scheduled with the same MCS, the UE may select the PUSCH 202 based on the beam index. The UE may also select a PUSCH 205 for UCI multiplexing based on the target coding rate or the number of coded bits for UCI on each PUSCH 202. The UE may select a PUSCH 202 with a lower target coding rate or a higher number of coded bits to transmit UCI. The UE determines the number of coded bits and coding rate based on the beta offset, MCS, scheduled time-frequency resources, and number of layers. If the target coding rate or the number of coded bits for UCI on two PUSCHs 202 are the same, the UE may select the PUSCH 202 based on the beam index.

[0078] The network entity may configure or indicate the PUSCH 205 for UCI multiplexing through control signaling. The UE transmits UCI associated with the PUCCH 204 on one of the PUSCHs 202 based on the received control signaling. The channel coding for the UCI is based on the modulation order and coding rate for the selected PUSCH 205.

[0079] The network entity may configure the PUSCH 205 for UCI multiplexing by indicating a TRP ID for UCI multiplexing (e.g., via RRC signaling, PUSCH-Config, CORESETPoolIndex of UCI-OnPUSCH, or CG-UCI-OnPUSCH). The UE may transmit UCI on the PUSCH associated with the TRP ID. In some examples, the network entity configures a TRP ID for a PUCCH resource, and the UE transmits UCI associated with the PUCCH 204 resource on the PUSCH 202 associated with the same TRP ID. The network entity may also configure the TRP ID in or associated with a TCI state so that the UE may transmit multiplexed UCI on the PUSCH with the indicated TCI associated with the same TRP ID. Control signaling (e.g., RRC signaling) may be applied to the CG-PUSCH. For each CG-PUSCH, the network entity may configure an indicator indicating whether the UE may multiplex UCI on the scheduled PUSCH 202. The RRC parameter may correspond to a 1-bit indicator, where a first state of the bit indicates that the UE may not multiplex UCI on the scheduled PUSCH 202 , and a second state of the bit may indicate that the UE may multiplex UCI on the scheduled PUSCH 205 .

[0080] The network entity may also configure the PUSCH 205 for UCI multiplexing by indicating the TRP ID (e.g., CORESETPoolIndex) for UCI multiplexing via the MAC-CE. The MAC-CE may indicate the serving cell index, BWP index, PUCCH resource index, and / or TRP ID. The UE transmits UCI associated with the PUCCH 204 on the PUSCH 202a associated with the same TRP ID.

[0081] In some implementations, the network entity indicates to the UE whether to multiplex UCI on the scheduled PUSCH 202 via a DCI field. The DCI field may include a UCI multiplexing flag. In an example, the DCI field / UCI multiplexing flag may be a 1-bit indicator, where a first state of the bit / UCI flag indicates that the UE may not multiplex UCI on the scheduled PUSCH 202, and a second state of the bit / UCI flag indicates that the UE may multiplex UCI on the scheduled PUSCH 202. In diagram 800, a first PUSCH 202a is associated with a UCI flag = 1, and a second PUSCH 202b is associated with a UCI flag = 0, where a value of 1 may indicate UCI multiplexing and a value of 0 may indicate no UCI multiplexing, or vice versa.

[0082] Figures 9A-9C Resource diagrams 900 - 920 associated with UCI multiplexing are shown. Figure 9A Can be used with Figure 9B or Figure 9C Pairing. The UE may select one of the PUSCHs 202 to transmit UCI. The UE may select the PUSCH 202 based on beam quality. The UE transmits UCI associated with the PUCCH 204 on the selected PUSCH 205 / 207. The channel coding used for the UCI is based on the modulation order and coding rate used for the selected PUSCH 205 / 207.

[0083] The UE may explicitly or implicitly report the index for the selected PUSCH to the network entity. For explicit indication, the UE reports the selected PUSCH index in a beam report. The UE may report at least one set of beam indices for simultaneous uplink transmission and may indicate the ID of the beam used for UCI reporting among the set of beams. The UE sends UCI on the PUSCH 205 / 207 with the indicated beam. For implicit indication, the UE reports the selected PUSCH index based on the DMRS or PUSCH scrambling sequence selection. The network entity may configure two scrambling IDs for the DMRS or PUSCH, where the first scrambling ID corresponds to the PUSCH 202a-202b without UCI and the second scrambling ID corresponds to the PUSCH 205a-205b / 207a-207b with UCI.

[0084] Illustrations 920-940 illustrate UCI multiplexing across two PUSCHs 205 / 207. In illustration 920, the UE transmits UCI repetitions on both PUSCHs 205 / 207. That is, the UE transmits on a first PUSCH 207a with data and UCI repetition 1, and on a second PUSCH 207b with data and UCI repetition 2. In illustration 940, the UE transmits UCI on both PUSCHs 205 / 207 based on UCI partitioning. That is, the UE transmits the first portion of UCI (e.g., UCI part 1) on a first PUSCH 205a with data and UCI part 1, and transmits the second / remaining portion of UCI (e.g., UCI part 2) on a second PUSCH 205b with data and UCI part 2.

[0085] In diagram 940, the UE may send UCI on a PUSCH 205 associated with the same TRP as the PUSCH in diagram 900. For example, a first PUSCH 202a / 205a corresponds to TRP 1, and a second PUSCH 202b / 205b corresponds to TRP 2. The UE may report HARQ-ACK for PDSCHs received from both TRPs, such that the UE may send HARQ-ACK for the PDSCH from the first TRP on a first PUSCH 205a associated with the first TRP, and send HARQ-ACK for the PDSCH from the second TRP on a second PUSCH 205b associated with the second TRP.

[0086] The UE may similarly report CSI for the CSI-RS received from both TRPs, such that the UE may transmit CSI for the CSI-RS from the first TRP on a first PUSCH 205a associated with the first TRP and transmit CSI for the CSI-RS from the second TRP on a second PUSCH 205b associated with the second TRP. The UE may perform independent channel coding for UCI in each PUSCH 205 based on the configuration used for the PUSCH 205 (e.g., based on MCS, beta offset, time-frequency resources, or scaling factor).

[0087] The UCI partitioning in diagram 940 may be based on single channel coding. The UE may calculate the total number of coded bits across two PUSCHs 205. The UE may transmit a first portion of the coded bits on a first PUSCH 205a with data and UCI based on the number of REs, number of layers, and modulation order used for the first PUSCH 205a. The UE may transmit a second portion / remaining portion of the coded bits on a second PUSCH 205b with data and UCI. The network entity may configure the UCI multiplexing scheme (e.g., single PUSCH UCI multiplexing, UCI repetition on two PUSCHs 207, or UCI partitioning on two PUSCHs 205) via RRC signaling, MAC-CE, or DCI. The UE may report its capabilities and / or preferences for the UCI multiplexing scheme to the network entity using UE capability signaling or UE assistance information messages. Figure 3-9C UCI multiplexing for multi-codeword and multi-beam PUSCH is described. Figure 10-11 Shown for implementation Figure 3-9C Specifically, Figure 10 UE 102 is shown Figure 3-9C Implementation of one or more aspects. Figure 11 The network entity 104 is shown Figure 3-9C Implementation of one or more aspects.

[0088] Figure 10 A flow chart 1000 of a method of wireless communication at a UE is shown. Figure 1-9C and Figure 12 , the method can be performed by UE 102, UE equipment 1202, etc., which may include memory 1226', 1206', 1216 and may correspond to the entire UE 102 or the entire UE equipment 1202, or components of the UE 102 or UE equipment 1202 (such as wireless baseband processor 1226 and / or application processor 1206).

[0089] UE 102 sends 1006 a UE capability report to the network entity indicating the UE's capability to multiplex multiple codewords associated with one or more beams on PUSCH resources. Figure 3 , the UE 102 sends 306 to the network entity 104 the UE capability for UCI multiplexing on multi-codeword PUSCH. Figure 7 , the UE 102 sends 706 the UE capability for UCI multiplexing on multi-beam PUSCH to the network entity 104. In a further example, the UE capability report indicates the UE capability for UCI multiplexing on both multi-codeword and multi-beam PUSCH.

[0090] UE 102 receives 1008 a configuration for UCI on PUCCH resources from a network entity. Figure 3 and Figure 7 , the UE 102 receives 308 , 708 a configuration of PUCCH resources for UCI feedback from the network entity 104 .

[0091] UE 102 receives 1010a a first trigger indication from a network entity for transmitting multiplexed UCI on PUSCH resources. Figure 3 , UE 102 receives 310 a trigger indication for a multi-codeword PUSCH from network entity 104. Figure 7 , the UE 102 receives 710a a trigger indication for the first PUSCH on the first beam from the network entity 104.

[0092] UE 102 receives 1010b from the network entity a second trigger indication for transmitting multiplexed UCI on PUSCH resources—the first and second trigger indications being for the first and second PUSCH transmissions on the first and second beams. Figure 7 After receiving 710a a trigger indication for a first PUSCH on a first beam, UE 102 receives 710b a trigger indication for a second PUSCH on a second beam from the network entity 104.

[0093] UE 102 receives 1012 a UCI trigger from a network entity for transmitting multiplexed UCI to the network entity on PUSCH resources. Figure 3 and Figure 7 , the UE 102 receives 312 , 712 from the network entity 104 a trigger indication for UCI feedback from the UE 102 to the network entity 104 .

[0094] The UE 102 determines 1014 to send the UCI on the PUSCH resources instead of the PUCCH resources based on multiplexing the UCI for multiple codewords on the PUSCH resources. Figure 3 , the UE 102 determines 314 a UCI multiplexing scheme for the multi-codeword PUSCH. Figure 7 , the UE 102 determines 714 a UCI multiplexing scheme on the multi-beam PUSCH.

[0095] The UE 102 multiplexes 1015 the UCI for multiple codewords on the PUSCH resources to generate multiplexed UCI - the multiple codewords are associated with one or more beams. Figures 5A-6C , UE 102 multiplexes UCI 508 on codeword 1 and codeword 2. Figures 8A-8C , UCI 508 is multiplexed on one beam. Figures 9A-9C , UCI 508 is multiplexed on multiple beams. Multiplexing UCI for multiple codewords may include multiplexing UCI for one codeword of a multi-codeword PUSCH and / or multiplexing UCI for all codewords of a multi-codeword PUSCH.

[0096] The UE 102 transmits 1016 the multiplexed UCI to the network entity on the PUSCH resource. Figure 3-6C , UE 102 sends 316 a multi-codeword PUSCH transmission with UCI multiplexing to network entity 104. Figure 7-9C , the UE 102 sends 716 a multi-beam PUSCH transmission with UCI multiplexing to the network entity 104. Figure 10 A method is described from the UE side of a wireless communication link, and Figure 11 A method is described from the network side of a wireless communication link.

[0097] Figure 11 1100 is a flow chart of a method of wireless communication at a network entity. Figure 1-9C and Figure 13 The method may be performed by one or more network entities 104, which may correspond to a base station or a unit of a base station (such as RU 106, DU 108, CU 110, RU processor 1306, DU processor 1326, CU processor 1346, etc.). One or more network entities 104 may include a memory 1306' / 1326' / 1346', which may correspond to the entirety of one or more network entities 104, or a component of one or more network entities 104 (such as RU processor 1306, DU processor 1326, or CU processor 1346).

[0098] The network entity 104 receives 1106 a UE capability report from the UE indicating the UE's capability to multiplex multiple codewords associated with one or more beams on PUSCH resources. Figure 3, the network entity 104 receives 306 from the UE 102 the UE capability for UCI multiplexing on multi-codeword PUSCH. Figure 7 , the network entity 104 receives 706 UE capabilities for UCI multiplexing on multi-beam PUSCH from the UE 102. In a further example, the UE capability report indicates UE capabilities for both multi-codeword and UCI multiplexing on multi-beam PUSCH.

[0099] The network entity 104 sends 1108 to the UE the configuration for UCI on the PUCCH resources. Figure 3 and Figure 7 , the network entity 104 sends 308, 708 to the UE 102 a configuration of PUCCH resources for UCI feedback.

[0100] The network entity 104 sends 1110a to the UE a first trigger indication for receiving multiplexed UCI on the PUSCH resource. Figure 3 , the network entity 104 sends 310 a trigger indication for the multi-codeword PUSCH to the UE 102. Figure 7 , the network entity 104 sends 710a to the UE 102 a trigger indication for the first PUSCH on the first beam.

[0101] The network entity 104 sends 1110b to the UE a second trigger indication for receiving multiplexed UCI on a PUSCH resource—the first and second trigger indications are for the first and second PUSCH transmissions on the first and second beams. Figure 7 After sending 710a a trigger indication for the first PUSCH on the first beam, the network entity 104 sends 710b a trigger indication for the second PUSCH on the second beam to the UE 102.

[0102] The network entity 104 sends 1112 to the UE a UCI trigger for receiving UCI multiplexed from the UE on PUSCH resources. Figure 3 and Figure 7 , the network entity 104 sends 312 , 712 to the UE 102 a trigger indication for UCI feedback from the UE 102 to the network entity 104 .

[0103] The network entity 104 receives 1116 from the UE UCI multiplexed on PUSCH resources—the UCI being for multiple codewords associated with one or more beams. Figure 3-6C , the network entity 104 receives 316 a multi-codeword PUSCH transmission with UCI multiplexing from the UE 102. Figure 7-9C, the network entity 104 receives 716 a multi-beam PUSCH transmission with UCI multiplexing from the UE 102. Figure 12 The described UE equipment 1202 can perform the method of flowchart 1000. Figure 13 As described in , one or more network entities 104 may perform the method of flowchart 1100 .

[0104] Figure 12 12 is a diagram 1200 illustrating an example of a hardware implementation of a UE device 1202. The UE device 1202 may be the UE 102, a component of the UE 102, or may implement UE functionality. The UE device 1202 may include an application processor 1206, which may have on-chip memory 1206′. In an example, the application processor 1206 may be coupled to a secure digital (SD) card 1208 and / or a display 1210. The application processor 1206 may also be coupled to a sensor module 1212, a power supply 1214, an additional memory module 1216, a camera 1218, and / or other related components. For example, the sensor module 1212 may control a barometric pressure sensor / altimeter, a motion sensor (such as an inertial management unit (IMU), a gyroscope, an accelerometer), a light detection and ranging (LIDAR) device, a radio-aided detection and ranging (RADAR) device, a sound navigation and ranging (SONAR) device, a magnetometer, an audio device, and / or other technologies for positioning.

[0105] UE equipment 1202 may further include a wireless baseband processor 1226, which may be referred to as a modem. Wireless baseband processor 1226 may have on-chip memory 1226′. Like and similar to application processor 1206, wireless baseband processor 1226 may also be coupled to sensor module 1212, power supply 1214, additional memory module 1216, camera 1218, and / or other related components. Wireless baseband processor 1226 may also be coupled to one or more subscriber identity module (SIM) cards 1220 and / or one or more transceivers 1230 (e.g., wireless RF transceivers).

[0106] Within one or more transceivers 1230, the UE equipment 1202 may include a Bluetooth module 1232, a WLAN module 1234, an SPS module 1236 (e.g., a GNSS module), and / or a cellular module 1238. The Bluetooth module 1232, the WLAN module 1234, the SPS module 1236, and the cellular module 1238 may each include an on-chip transceiver (TRX), or in some cases, only a transmitter (TX) or only a receiver (RX). The Bluetooth module 1232, the WLAN module 1234, the SPS module 1236, and the cellular module 1238 may each include a dedicated antenna and / or utilize an antenna 1240 to communicate with one or more other nodes. For example, the UE equipment 1202 can communicate with another UE 102 (e.g., sidelink communication) and / or communicate with a network entity 104 (e.g., uplink / downlink communication) via the antenna 1240 via the transceiver 1230, where the network entity 104 can correspond to a base station or a unit of the base station such as the RU 106, DU 108, or CU 110.

[0107] The wireless baseband processor 1226 and the application processor 1206 may each include a computer-readable medium / memory 1226′, 1206′, respectively. The additional memory module 1216 may also be considered a computer-readable medium / memory. Each computer-readable medium / memory 1226′, 1206′, 1216 may be non-transitory. The wireless baseband processor 1226 and the application processor 1206 may each be responsible for general processing, including executing software stored on the computer-readable medium / memory 1226′, 1206′, 1216. This software, when executed by the wireless baseband processor 1226 / application processor 1206, causes the wireless baseband processor 1226 / application processor 1206 to perform the various functions described herein. The computer-readable medium / memory may also be used to store data manipulated by the wireless baseband processor 1226 / application processor 1206 when executing the software. The wireless baseband processor 1226 / application processor 1206 may be a component of the UE 102. UE equipment 1202 may be a processor chip (e.g., modem and / or applications) and include only the radio baseband processor 1226 and / or the application processor 1206. In other examples, UE equipment 1202 may be the entire UE 102 and include additional modules of the equipment 1202.

[0108] like Figure 1As discussed in

[0014] , the UCI multiplexing component 140 is configured to multiplex UCI for multiple codewords on PUSCH resources to generate multiplexed UCI, the multiple codewords being associated with one or more beams; and transmit the multiplexed UCI to a network entity on the PUSCH resources. The UCI multiplexing component 140 may be located within the application processor 1206 (e.g., at 140a), within the radio baseband processor 1226 (e.g., at 140b), or within both the application processor 1206 and the radio baseband processor 1226. The UCI multiplexing components 140a-140b may be one or more hardware components specifically configured to perform the recited processes / algorithms, implemented by one or more processors configured to perform the recited processes / algorithms, stored on a computer-readable medium for implementation by one or more processors, or a combination thereof.

[0109] Figure 13 13 is a diagram 1300 illustrating an example of a hardware implementation of one or more network entities 104. 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 1346, which may have on-chip memory 1346'. In some aspects, the CU 110 may further include an additional memory module 1356 and / or a communication interface 1348, both of which may be coupled to the CU processor 1346. The CU 110 may communicate with the DU 108 via a midhaul link 162, such as an F1 interface between the communication interface 1348 of the CU 110 and the communication interface 1328 of the DU 108.

[0110] The DU 108 may include a DU processor 1326, which may have on-chip memory 1326'. In some aspects, the DU 108 may further include an additional memory module 1336 and / or a communication interface 1328, both of which may be coupled to the DU processor 1326. The DU 108 may communicate with the RU 106 via a fronthaul link 160 between the communication interface 1328 of the DU 108 and the communication interface 1308 of the RU 106.

[0111] The RU 106 may include a RU processor 1306, which may have on-chip memory 1306'. In some aspects, the RU 106 may further include an additional memory module 1316, a communication interface 1308, and one or more transceivers 1330, all of which may be coupled to the RU processor 1306. The RU 106 may further include an antenna 1340, which may be coupled to the one or more transceivers 1330, such that the RU 106 may communicate with the UE 102 via the antenna 1340 through the one or more transceivers 1330.

[0112] On-chip memory 1306', 1326', 1346' and additional memory modules 1316, 1336, 1356 can each be considered a computer-readable medium / memory. Each computer-readable medium / memory can be non-transitory. Each of processors 1306, 1326, 1346 is responsible for general processing, including executing software stored on the computer-readable medium / memory. The software, when executed by the corresponding processor 1306, 1326, 1346, causes the processor 1306, 1326, 1346 to perform the various functions described herein. The computer-readable medium / memory can also be used to store data manipulated by the processor 1306, 1326, 1346 when executing the software. In an example, the UCI receiving component 150 can be located at any of the one or more network entities 104, such as at the CU 110; at both the CU 110 and the DU 108; at each of the CU 110, DU 108, and RU 106; at the DU 108; at both the DU 108 and the RU 106; or at the RU 106.

[0113] like Figure 1 As discussed in

[0015] , the UCI receiving component 150 is configured to send a configuration for UCI on PUCCH resources to a UE; and receive UCI multiplexed on PUSCH resources from the UE for multiple codewords associated with one or more beams. The UCI receiving component 150 can be within one or more processors of one or more network entities 104, such as the RU processor 1306 (e.g., at 150a), the DU processor 1326 (e.g., at 150b), and / or the CU processor 1346 (e.g., at 150c). The UCI receiving components 150a-150c can be one or more hardware components specifically configured to perform the stated processes / algorithms, implemented by one or more processors 1306, 1326, 1346 configured to perform the stated processes / algorithms, stored on a computer-readable medium for implementation by one or more processors 1306, 1326, 1346, or a combination thereof.

[0114] The specific order or hierarchy of blocks in the processes and flowcharts disclosed herein is illustrative of example methods. Therefore, the specific order or hierarchy of blocks in the processes and flowcharts may be rearranged. Some blocks may also be merged or deleted. Dashed lines may indicate optional elements of the diagram. The accompanying method claims present elements of each block in an example order and are not limited to the specific order or hierarchy presented in the claims, processes, and flowcharts.

[0115] The detailed description set forth herein, in conjunction with the accompanying drawings, describes various configurations and does not represent the only configuration in which the concepts described herein may be practiced. The detailed description includes specific details to provide a comprehensive explanation of the various concepts. However, these concepts may be practiced without using these specific details. In some cases, well-known structures and components are shown in block diagram form to avoid obscuring such concepts.

[0116] Various aspects of wireless communication systems (such as telecommunication systems) are presented with reference to various apparatus and methods. These apparatus and methods are described in the detailed description that follows and are illustrated in the accompanying drawings by various blocks, components, circuits, processes, call flows, systems, algorithms, etc. (collectively, "elements"). These elements can be implemented using electronic hardware, computer software, or a combination thereof. Whether such elements are implemented as hardware or software depends on the specific application and design constraints imposed on the overall system.

[0117] Element, or any part of an element or any combination of elements can be implemented as a "processing system" including 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 (SoCs), baseband processors, field programmable gate arrays (FPGAs), programmable logic devices (PLDs), state machines, gating logic, discrete hardware circuits, and other similar hardware configured to perform the various functions described throughout this disclosure. One or more processors in a processing system can execute software, which can be referred to as software, firmware, middleware, microcode, hardware description language, or other. Software should be broadly interpreted as meaning instructions, instruction sets, codes, code segments, program codes, programs, subroutines, software components, applications, software applications, software packages, routines, subroutines, objects, executables, execution threads, processes, functions, or any combination thereof.

[0118] If the functions described herein are implemented in software, these functions may be stored on a computer-readable medium (such as a non-transitory computer-readable storage medium) or encoded as one or more instructions or codes on the computer-readable medium. Computer-readable media include computer storage media and may include random access memory (RAM), read-only memory (ROM), 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 computer-accessible instructions or data structures. The storage medium can be any available medium that is accessible to the computer.

[0119] The various aspects, implementations, and / or use cases described herein can be implemented across many different platform types, devices, systems, shapes, sizes, and packaging arrangements. For example, the various aspects, implementations, and / or use cases can be generated via integrated chip implementations and other non-module component-based devices such as end-user devices, vehicles, communication devices, computing devices, industrial equipment, retail / procurement devices, medical devices, artificial intelligence (AI)-enabled devices, machine learning (ML)-enabled devices, and the like. The various aspects, implementations, and / or use cases can range from chip-level or modular components to non-modular or non-chip-level implementations, and further to aggregated, distributed, or original equipment manufacturer (OEM) devices or systems incorporating one or more of the techniques described herein.

[0120] Devices incorporating aspects and features described herein may also include additional components and features for implementing and practicing the aspects and features claimed and described. For example, the transmission and reception of wireless signals necessarily include many components for analog and digital purposes, such as hardware components, antennas, RF chains, power amplifiers, modulators, buffers, processors, interleavers, adders / summers, etc. The techniques described herein can be practiced in a wide variety of devices, chip-level components, systems, distributed arrangements, aggregated or disaggregated components, end-user devices, etc., in various configurations.

[0121] The description herein is provided to enable those skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects. Therefore, the claims are not limited to the various aspects described herein, but should be interpreted in view of the full scope of the disclosure consistent with the language of the claims.

[0122] Unless expressly stated, references to singular elements do not mean "one and only one", but rather "one or more". Terms such as "if", "when" and "at" do not imply an immediate temporal relationship or reaction. That is, these phrases (e.g., "when") do not imply immediate action in response to the occurrence of an action or during the occurrence of an action, but simply mean that if a certain condition is met, a certain action will occur, but no specific or immediate time constraint is required for the occurrence of the action. The terms "may", "might" and "can" as used in this disclosure generally carry certain meanings. For example, "may" refers to a permissible feature that may or may not occur, "might" refers to a feature that is likely to occur, and "can" refers to an ability (e.g., to be able to). The phrase "for example" generally carries a similar meaning to "may", and therefore, "may" is sometimes excluded from sentences that include "for example" or other similar phrases.

[0123] Unless expressly 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, B, and C, and may include multiple A's, multiple B's, and / or multiple C's, or may include only A's, only B's, or only C's. A set should be interpreted as a set of elements where the number of elements is one or more.

[0124] Unless otherwise expressly indicated, ordinal terms such as "first" and "second" do not necessarily imply an order in time, sequence, value, etc., but are used to distinguish different instances of the term or phrase following each ordinal term. Figure numerals as used in the specification and drawings are sometimes cross-referenced between the drawings to indicate identical or similar features. Features that are identical in multiple drawings may be labeled with the same figure numerals in the multiple drawings. Features that are similar but not identical across multiple drawings may be labeled with figure numerals having different leading digits but one or more of the same trailing digits (e.g., 206, 306, 406, etc. may refer to similar features in the drawings). Sometimes, "X" is used to generally indicate multiple variations of a feature. For example, "X06" may generally refer to all reference numbers ending in "06" (e.g., 206, 306, 406, etc.).

[0125] Structural equivalents and functional equivalents of the elements of various aspects described in the entire present disclosure that are known or later learned by those of ordinary skill in the art are expressly incorporated herein by reference and are covered by the claims. The words "module", "mechanism", "element", "device" and the like may not be substitutes for the word "component". Therefore, unless the phrase "component for ..." is used to clearly state the claim elements, any claim element shall not be interpreted as a means plus function. As used herein, the phrase "based on" should not be interpreted as a reference to a closed information set, one or more conditions, one or more factors, etc. In other words, unless clearly stated differently, the phrase "based on A" (wherein "A" can be information, conditions, factors, etc.) should be interpreted as "at least based on A".

[0126] The following examples are illustrative only and may be combined with other examples or teachings described herein without limitation.

[0127] Example 1 is a method of wireless communication at a UE, comprising: multiplexing UCI for multiple codewords on a PUSCH resource to generate multiplexed UCI, the multiple codewords being associated with one or more beams, such as one or more TCI states; and sending the multiplexed UCI to a network entity on the PUSCH resource.

[0128] Example 2 may be combined with Example 1 and further include: receiving a configuration for UCI on PUCCH resources from a network entity; and determining to send UCI on PUSCH resources instead of PUCCH resources based on multiplexing UCI for multiple codewords on PUSCH resources.

[0129] Example 3 can be combined with Example 2 and include receiving a configuration for UCI further including: receiving an indication of a multiplexing scheme, wherein multiplexing UCI for multiple codewords associated with one or more beams on PUSCH resources is based on the indication of the multiplexing scheme.

[0130] Example 4 can be combined with Example 3, and include: the indication of the multiplexing scheme includes a first parameter for performing multiplexing for a multi-codeword PUSCH.

[0131] Example 5 can be combined with Example 4, and include: the indication of the multiplexing scheme includes a second parameter for performing multiplexing for a multi-beam PUSCH.

[0132] Example 6 can be combined with any one of Examples 1-5 and further include: sending a UE capability report to a network entity, the report indicating the UE's ability to multiplex multiple codewords associated with one or more beams on PUSCH resources.

[0133] Example 7 can be combined with Example 6 and includes: the UE's capability corresponds to at least one of the following: a first UCI multiplexing capability for multiple codewords, a second UCI multiplexing capability on one or more beams, or a data transmission capability on the same resource elements allocated for UCI in a first codeword among the multiple codewords and in a second codeword among the multiple codewords.

[0134] Example 8 may be combined with any of Examples 1-7, and include: the multiplexed UCI on the PUSCH resources corresponding to repetition of the UCI on the same resource elements for multiple codewords or partitioning of the UCI.

[0135] Example 9 may be combined with any of Examples 1-7, and include: the multiplexed UCI on the PUSCH resources corresponding to repetition of the UCI on different resource elements for multiple codewords or partitioning of the UCI.

[0136] Example 10 can be combined with any one of Examples 1-7, and include that the plurality of codewords include a first codeword having UCI and a second codeword not having UCI.

[0137] Example 11 can be combined with any one of Examples 1-7, and include: the multiple codewords include a first codeword with CSI and HARQ-ACK and a second codeword with CSI and without HARQ-ACK.

[0138] Example 12 may be combined with any of Examples 1-11, and further include receiving a first trigger indication from a network entity to transmit the multiplexed UCI on PUSCH resources.

[0139] Example 13 can be combined with Example 12 and further include: receiving a second trigger indication from the network entity for sending multiplexed UCI on PUSCH resources, the first trigger indication for the first PUSCH transmission on the first beam, and the second trigger indication for the second PUSCH transmission on the second beam.

[0140] Example 14 can be combined with any one of Examples 12-13 and include: at least one of the first trigger indication or the second trigger indication indicates a multiplexing scheme for multiplexed UCI, which multiplexing scheme corresponds to at least one of multi-codeword PUSCH transmission or multi-beam PUSCH transmission.

[0141] Example 15 may be combined with any of Examples 1-14, and further include receiving a UCI trigger from a network entity to transmit the multiplexed UCI on PUSCH resources to the network entity.

[0142] Example 16 can be combined with any one of Examples 1-15, and include transmitting multiplexed UCI for multiple codewords on a single beam.

[0143] Example 17 can be combined with any one of Examples 1-15, and include transmitting multiplexed UCI for multiple codewords on multiple beams.

[0144] Example 18 is a method of wireless communication at a network entity, comprising: sending a configuration for UCI on PUCCH resources to a UE; and receiving UCI multiplexed on PUSCH resources from the UE, the UCI being used for multiple codewords associated with one or more beams.

[0145] Example 19 can be combined with Example 18 and include sending a configuration for UCI further comprising: sending an indication of a multiplexing scheme, wherein multiplexing of UCI for multiple codewords associated with one or more beams on PUSCH resources is based on the indication of the multiplexing scheme.

[0146] Example 20 can be combined with Example 19, and include: the indication of the multiplexing scheme includes a first parameter for performing multiplexing for a multi-codeword PUSCH.

[0147] Example 21 can be combined with Example 20, and include: the indication of the multiplexing scheme includes a second parameter for performing multiplexing for a multi-beam PUSCH.

[0148] Example 22 can be combined with any one of Examples 18-21, and further includes: receiving a UE capability report from the UE, the report indicating the UE's ability to multiplex multiple codewords associated with one or more beams on PUSCH resources.

[0149] Example 23 can be combined with Example 22 and include: the UE's capability corresponds to at least one of the following: a first UCI multiplexing capability for multiple codewords, a second UCI multiplexing capability on one or more beams, or a data transmission capability on the same resource elements allocated for UCI in a first codeword among the multiple codewords and in a second codeword among the multiple codewords.

[0150] Example 24 may be combined with any of Examples 18-23, and include: the multiplexed UCI on the PUSCH resources corresponding to repetition of the UCI on the same resource elements for multiple codewords or partitioning of the UCI.

[0151] Example 25 may be combined with any of Examples 18-23, and include: the multiplexed UCI on the PUSCH resources corresponding to repetition of the UCI on different resource elements for multiple codewords or partitioning of the UCI.

[0152] Example 26 can be combined with any one of Examples 18-23, and include: the plurality of codewords including a first codeword having UCI and a second codeword not having UCI.

[0153] Example 27 can be combined with any of Examples 18-23, and include: the multiple codewords include a first codeword with CSI and HARQ-ACK and a second codeword with CSI and without HARQ-ACK.

[0154] Example 28 may be combined with any of Examples 18-27, and further include sending a first trigger indication to the UE for receiving multiplexed UCI on PUSCH resources.

[0155] Example 29 can be combined with Example 28 and further include: sending a second trigger indication to the UE for receiving multiplexed UCI on PUSCH resources, the first trigger indication for the first PUSCH transmission on the first beam, and the second trigger indication for the second PUSCH transmission on the second beam.

[0156] Example 30 can be combined with any one of Examples 28-29 and include: at least one of the first trigger indication or the second trigger indication indicates a multiplexing scheme for multiplexed UCI, which multiplexing scheme corresponds to at least one of multi-codeword PUSCH transmission or multi-beam PUSCH transmission.

[0157] Example 31 may be combined with any of Examples 18-30, and further include sending a UCI trigger to the UE for receiving multiplexed UCI from the UE on PUSCH resources.

[0158] Example 32 can be combined with any of Examples 18-31, and include receiving multiplexed UCI for multiple codewords on a single beam.

[0159] Example 33 may be combined with any of Examples 18-31, and include receiving multiplexed UCI for a plurality of codewords on a plurality of beams.

[0160] Example 34 is an apparatus for wireless communication implementing the method of any one of Examples 1-33.

[0161] Example 35 is an apparatus for wireless communication including components for implementing the method as described in any of Examples 1-33.

[0162] Example 36 is a non-transitory computer-readable medium storing computer-executable code that, when executed by a processor, causes the processor to implement the method of any one of Examples 1-33.

Claims

1. A method of wireless communication at a user equipment (UE) (102), comprising: multiplexing uplink control information UCI (508) for a plurality of codewords associated with one or more beams on a physical uplink shared channel (PUSCH) resource (202) to generate a multiplexed UCI; and The multiplexed UCI (508) is sent (316, 716) to a network entity (104) on the PUSCH resources (202).

2. The method of claim 1, further comprising: receiving (308, 708) a configuration for UCI on a physical uplink control channel, PUCCH, resource (204), from the network entity (104); as well as Based on multiplexing the UCI (508) for the plurality of codewords on the PUSCH resources (202), it is determined (314, 714) to transmit the UCI (508) on the PUSCH resources (202) instead of the PUCCH resources (204).

3. The method of claim 2, wherein the receiving (308, 708) the configuration for the UCI further comprises: An indication of a multiplexing scheme is received (308, 708), wherein multiplexing the UCI (508) for the plurality of codewords associated with the one or more beams on the PUSCH resources (202) is based on the indication of the multiplexing scheme.

4. The method of claim 3, wherein the indication of the multiplexing scheme comprises a first parameter for performing the multiplexing for a multi-codeword PUSCH. 5 . The method of claim 4 , wherein the indication of the multiplexing scheme comprises a second parameter for performing the multiplexing for a multi-beam PUSCH.

6. The method of any one of claims 1 to 5, further comprising: A UE capability report is sent (306, 706) to the network entity (104), the UE capability report indicating a capability of the UE (102) to multiplex the plurality of codewords associated with the one or more beams on the PUSCH resources (202).

7. The method of claim 6, wherein the capability of the UE (102) corresponds to at least one of: a first UCI multiplexing capability for the plurality of codewords, a second UCI multiplexing capability on the one or more beams, or Data transmission capability on the same resource elements allocated for the UCI (508) in a first codeword of the plurality of codewords and in a second codeword of the plurality of codewords.

8. The method of any one of claims 1 to 7, wherein the multiplexed UCI (508) on the PUSCH resources (202) corresponds to a repetition of the UCI (508) or a partition of the UCI (508) on the same resource elements for the multiple codewords.

9. The method of any one of claims 1-7, wherein the multiplexed UCI (508) on the PUSCH resources (202) corresponds to a repetition of the UCI (508) or a partition of the UCI (508) on different resource elements for the plurality of codewords.

10. The method of any of claims 1-7, wherein the plurality of codewords comprises a first codeword having the UCI (508) and a second codeword not having the UCI (508).

11. The method of any one of claims 1 to 7, wherein the plurality of codewords comprises a first codeword having channel state information (CSI) and a hybrid automatic repeat request-acknowledgement (HARQ-ACK) (406), and a second codeword having the CSI (408) but not the HARQ-ACK (406).

12. The method of any one of claims 1 to 11, further comprising: A first trigger indication is received (310, 710a) from the network entity (104) to transmit (316, 716) the multiplexed UCI (508) on the PUSCH resource (202).

13. The method of claim 12, further comprising: A second trigger indication is received (710b) from the network entity (104) for sending (716) the multiplexed UCI (508) on the PUSCH resource (202), the first trigger indication being for a first PUSCH transmission on a first beam and the second trigger indication being for a second PUSCH transmission on a second beam.

14. The method of any one of claims 12-13, wherein at least one of the first trigger indication or the second trigger indication indicates a multiplexing scheme for the multiplexed UCI (508), the multiplexing scheme corresponding to at least one of a multi-codeword PUSCH transmission (316) or a multi-beam PUSCH transmission (716).

15. The method of any one of claims 1 to 14, further comprising: A UCI trigger is received (312, 712) from the network entity (104) for transmitting (316, 716) the multiplexed UCI (508) to the network entity (104) on the PUSCH resources (202).

16. The method of any of claims 1-15, wherein transmitting (316, 716) the multiplexed UCI (508) for the plurality of codewords is on a single beam.

17. The method of any of claims 1-15, wherein transmitting (316, 716) the multiplexed UCI (508) for the plurality of codewords is on multiple beams.

18. A method of wireless communication at a network entity (104), comprising: sending (308, 708) a configuration for uplink control information UCI on physical uplink control channel PUCCH resources (204) to a user equipment UE (102); and The UCI is received (316, 716) from the UE (102) multiplexed on a physical uplink shared channel (PUSCH) resource (202), the UCI being for a plurality of codewords associated with one or more beams.

19. An apparatus for wireless communication, comprising a memory, a transceiver, and a processor, the processor being coupled to the memory and the transceiver, the apparatus being configured to implement the method according to any one of claims 1 to 18.

Images