UCI multiplexing with multicodeword and multibeam PUSCH

Abstract

This disclosure provides a system, device, apparatus, and method comprising a computer program encoded on a storage medium for multiplexing UCI(508) for multiple codewords on one or more beams. UE(102) multiplexes UCI(508) for multiple codewords on a PUSCH resource(202) to generate a multiplexed UCI. The multiple codewords are associated with one or more beams. UE(102) transmits (316, 716) the multiplexed UCI(508) on the PUSCH resource(202) to a network entity(104).

Description

[Technical Field]

[0001] This disclosure relates in general to wireless communications, and more specifically to multiplexing uplink control information (UCI) for multiple codewords on one or more beams. [Background technology]

[0002] The Third Generation Partnership Project (3GPP®) defines a radio interface called Fifth Generation (5G) New Radio (NR) (5GNR). The architecture for 5GNR wireless communication systems includes the 5G Core (5GC) network, the 5G Radio Access Network (5G-RAN), and user equipment (UE). The 5GNR architecture aims to increase data rates, reduce latency, and / or increase capacity compared to previous generation cellular communication systems.

[0003] Wireless communication systems can generally be configured to provide a variety of telecommunications services (e.g., telephone, video, data, messaging, broadcast, etc.) based on multiplexing technologies such as orthogonal frequency division multiplexing (OFDMA) technology, which supports communication with multiple UEs. Advances in such wireless communication technologies continue with improvements in mobile broadband. For example, an UE can multiplex uplink control information (UCI) over an allocated physical uplink shared channel (PUSCH) resource that temporally overlaps with a physical uplink control channel (PUCCH) resource configured for UCI transmission. However, UEs may be scheduled to transmit using multiple codewords (e.g., with different modulation orders or coding rates) or on multiple beams, which can increase complexity at the UE. [Overview of the project]

[0004] The following provides a simplified overview of one or more embodiments to offer a basic understanding of such embodiments. This overview is not a comprehensive overview of all embodiments intended. This overview does not identify any important or definitive elements of all embodiments, nor does it specify the scope of any or all embodiments. Its sole purpose is to present some of the concepts of one or more embodiments in a simplified form as a prelude to the more detailed explanations that will follow.

[0005] A network entity, such as a base station or a base station unit, may configure user equipment (UE) to transmit uplink control information (UCI) over a physical uplink control channel (PUCCH) resource. In situations where the PUCCH resource temporally overlaps with a physical uplink shared channel (PUSCH) resource allocated to the UE, the UE may transmit UCI to the network entity over the allocated PUSCH resource. UCI may include information such as scheduling requests, hybrid automatic retransmission request acknowledgments (HARQ-ACKs), channel status information (CSI) part 1, and / or CSI part 2.

[0006] If an allocated PUSCH resource overlaps with a PUCCH resource in the time domain, the UE may transmit UCI to a network entity using the PUSCH resource, but the network entity may also schedule its UE to transmit using multiple codewords (e.g., using different modulation coding schemes (MCS)) or on multiple beams. Thus, in a multi-codeword scenario, the UE uses codewords that instruct different modulation orders or different target coding rates. In a multi-beam scenario, the PUSCH resource may correspond to different UE panels transmitting to different transmit / receive points (TRPs). Therefore, in multi-codeword and / or multi-beam scenarios, transmitting UCI using an allocated PUSCH resource results in increased complexity.

[0007] Aspects of this disclosure address the above-mentioned and other deficiencies by multiplexing the UCI for multiple codewords or multiple beams on an allocated PUSCH resource, in which case the allocated PUSCH resource will temporally overlap with the PUSCH resource. In some examples, a network entity may provide the UE with a multiplexing scheme for multiplexing the UCI on the PUSCH resource. In other examples, the UE independently determines the multiplexing scheme for the UCI associated with multiple codewords or multiple beams.

[0008] In some embodiments, the UE multiplexes UCIs for multiple codewords on the UE's assigned PUSCH resource to generate multiplexed UCIs, with the multiple codewords associated with one or more. The UE then transmits the UCIs to the network entity on the PUSCH resource based on the UCI multiplexing scheme.

[0009] In some embodiments, a network entity transmits a UCI configuration on a PUCCH resource to the UE. The network entity receives a multiplexed UCI on the PUCCH resource from the UE. The UCI is for multiple codewords associated with one or more beams. [Brief explanation of the drawing]

[0010] [Figure 1] This diagram shows a wireless communication system including multiple user devices (UEs) and network entities communicating via one or more cells. [Figure 2] Figures A through D show the uplink resources for transmitting uplink control information (UCI). [Figure 3] This diagram shows the signaling for multicodeword physical uplink shared channel (PUSCH) transmission based on UCI multiplexing. [Figure 4] A-C show resource diagrams for codewords with and without UCI. [Figure 5] A to C show a resource diagram of codewords associated with UCI repetition (or UCI partitioning). [Figure 6] A to C show a resource diagram of codewords associated with hybrid multiplexing of UCI types. [Figure 7] Show a signaling diagram for multi-beam PUSCH transmission based on UCI multiplexing. [Figure 8] A to C show a resource diagram related to UCI multiplexing. [Figure 9] A to C show a resource diagram related to UCI multiplexing. [Figure 10] It is a flowchart of a wireless communication method in a UE. [Figure 11] It is a flowchart of a wireless communication method in a network entity. [Figure 12] It is a diagram showing a hardware implementation of an exemplary UE device.​​​​​​​​​​Figure 1 shows FIG. 100 of a wireless communication system associated with a plurality of cells 190. The wireless communication system includes a user equipment (UE) 102 and a base station / network entity 104. There are base stations including an integrated base station architecture and those including a distributed base station architecture. The integrated base station architecture is configured to utilize a radio protocol stack physically or logically integrated within a single radio access network (RAN) node, and includes a radio unit (RU) 106, a distributed unit (DU) 108, and a central unit (CU) 110. The distributed base station architecture utilizes a protocol stack physically or logically distributed across two or more units (e.g., RU 106, DU 108, CU 110). For example, CU 110 can be implemented within a RAN node, and one or more DUs 108 can be co-located with CU 110 or alternatively geographically or virtually distributed across one or more other RAN nodes. DU 108 can be implemented to communicate with one or more RUs 106. Each of RU 106, DU 108, and CU 110 can 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., an integrated base station or a distributed unit of a base station such as RU 106, DU 108, or CU 110) can be referred to as a transmit receive point (TRP).

[0012] The operation and / or network design of base station 104 can be based on the aggregation characteristics of the base station functions. For example, isolated base station architectures are used in integrated access backhaul (IAB) networks, open radio access network (O-RAN) networks, or virtual radio access networks (vRAN), which may also be called cloud radio access networks (C-RAN). Isolation may include distributing functions across two or more units at various physical locations, and virtually distributing the functions of at least one unit, thereby enabling flexibility in network design. Various units of an isolated base station architecture, or isolated RAN architecture, can be configured for wired or wireless communication with at least one other unit. For example, base stations 104d / 104e and / or RU106a-106d may communicate with UE102a-102d and 102s via one or more radio frequency (RF) access links based on Uu interfaces. In this example, multiple RU106 and / or base stations 104 can simultaneously provide services to UE102 via intracell and / or intercell access links between UE102 and RU106 / base stations 104.

[0013] RU106, DU108, and CU110 may include (or be coupled to) one or more interfaces configured to transmit or receive information / signals over a wired or wireless transmission medium. Base station 104 or one or more isolated base station units may be configured to communicate with one or more other base stations 104 or one or more other isolated base station units over a wired or wireless transmission medium. For example, a processor, memory, and / or controller associated with executable instructions for an interface may be configured to provide communication between base stations 104 and / or one or more isolated base station units over a wired or wireless transmission medium. For example, a wired interface may be configured to transmit or receive information / signals over a wired transmission medium, such as via a fronthaul link 160 between RU106d and the baseband unit (BBU) 112 of base station 104d associated with cell 190d. BBU112 includes DU108 and CU110, which may also have a wired interface (e.g., a midhall link) configured between DU108 and CU110 to transmit or receive information / signals between DU108d and CU110d. In a further example, the wireless interface may include a receiver, transmitter, or transceiver such as an RF transceiver, and is configured to transmit and / or receive information / signals over a wireless transmission medium, such as information communicated between RU106a in cell 190a and base station 104e in cell 190e via cross-cell communication beams 136-138 between RU106a and base station 104e.

[0014] RU106 may be configured to implement lower-layer functions. For example, RU106 may correspond to a logical node controlled by DU108 that hosts RF processing functions or lower-layer PHY functions such as performing fast Fourier transform (FFT), inverse FFT (iFFT), digital beamforming, and physical random access channel (PRACH) extraction and filtering. The functions of RU106 may be based on a functional partition, such as a lower-layer functional partition.

[0015] RU106 can transmit or receive over-the-air (OTA) communications with one or more UE102s. For example, RU106b in cell 190b communicates with UE102b in cell 190b via a first set of communication beams 132 of RU106b and a second set of communication beams 134b of UE102b, these communication beams may correspond to intra-cell communication beams, or in some examples, cross-cell communication beams. For example, UE102b in cell 190b can communicate with RU106a in cell 190a via a third set of communication beams 134a of UE102b and a fourth set of communication beams 136 of RU106a. Both real-time and non-real-time functions of RU106's control plane communications and user plane communications can be controlled by the associated DU108.

[0016] Any combination of RU106, DU108, and CU110, or any reference to them individually, may correspond to base station 104. Thus, base station 104 may include at least one of RU106, DU108, or CU110. Base station 104 provides UE102 with access to the core network. Base station 104 may relay communications between UE102 and the core network. Base station 104 may be associated with macrocells for high-power cellular base stations and / or small cells for low-power cellular base stations. For example, cell 190e may correspond to a macrocell, while cells 190a-190d may correspond to small cells. Small cells include femtocells, picocells, microcells, etc., and a cell structure containing at least one macrocell and at least one small cell is sometimes called a "heterogeneous network".

[0017] Transmission from UE102 to base station 104 / RU106 is called uplink (UL) transmission. Conversely, transmission from base station 104 / RU106 to UE102 is called downlink (DL) transmission. Uplink transmission is sometimes called reverselink transmission, and downlink transmission is sometimes called forwardlink transmission. For example, RU106d uses antenna 114 of base station 104d in cell 190d to transmit downlink / forwardlink communication to UE102d, or to receive uplink / reverselink communication from UE102, based on the Uu interface associated with the access link between UE102d and base station 104d / RU106d.

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

[0019] Some UE102 units, such as UE102a and UE102s, may perform device-to-device (D2D) communication via sidelinks. For example, sidelink communication / D2D links utilize the spectrum of a wireless wide area network (WWAN) associated with uplink and downlink communication. Sidelink communication / D2D links may also communicate information between UE102a and UE102s using one or more sidelink channels, such as the Physical Sidelink Broadcast Channel (PSBCH), Physical Sidelink Discovery Channel (PSDCH), Physical Sidelink Sharing Channel (PSSCH), and / or Physical Sidelink Control Channel (PSCCH). Such sidelink / D2D communication may be performed via various wireless communication systems, such as Wireless Fidelity (Wi-Fi) systems, Bluetooth® systems, Long-Term Evolution (LTE) systems, and New Radio (NR) systems.

[0020] The electromagnetic spectrum is often subdivided into different classes, bands, channels, etc., based on the different frequencies / wavelengths associated with the electromagnetic spectrum. Fifth-generation (5G) NR is generally associated with two operating frequency ranges (FRs), referred to as Frequency Range 1 (FR1) and Frequency Range 2 (FR2). The FR1 range is 410 MHz to 7.125 GHz, and the FR2 range is 24.25 GHz to 71.0 GHz, which includes FR2-1 (24.25 GHz to 52.6 GHz) and FR2-2 (52.6 GHz to 71.0 GHz). Part of FR1 actually exceeds 6 GHz, but 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 a subset that is not distinct from, but close to, the “ultra-high frequency” (EHF) band, also called the “millimeter wave” band, which is in the 30 GHz to 300 GHz range. The frequencies between FR1 and FR2 are often referred to as “mid-band” frequencies. The operating band for mid-band frequencies is sometimes called Frequency Range 3 (FR3), ranging from 7.125 GHz to 24.25 GHz. The frequency bands within FR3 may include the characteristics of FR1 and / or FR2. Therefore, the functionality of FR1 and / or FR2 can be extended to mid-band frequencies. Higher operating frequency bands have been identified to extend 5G NR communications beyond 52.6 GHz, which is associated with the upper limit of FR2. Three of these higher operating frequency bands include FR2-2 in the range of 52.6 GHz to 71.0 GHz, FR4 in the range of 71.0 GHz to 114.25 GHz, and FR5 in the range of 114.25 GHz to 300 GHz. The upper limit of FR5 corresponds to the upper limit of the EHF band. Therefore, unless otherwise specified herein, the term “sub-6 GHz” may refer to frequencies below 6 GHz within FR1, or it may include mid-band frequencies. Furthermore, unless otherwise specified herein, the term “millimeter wave” or mmW refers to frequencies that may include midband frequencies and may be within FR2-1, FR4, FR2-2, and / or FR5, or within the EHF band.

[0021] UE102 and base station 104 / RU106 may each include multiple antennas. These multiple antennas may correspond to antenna elements, antenna panels, and / or antenna arrays that can facilitate beamforming. For example, RU106b transmits a downlink beamforming signal to UE102b in one or more transmit directions of RU106b based on a first set of communication beams 132. UE102b may receive the downlink beamforming signal from RU106b in one or more receive directions of UE102b based on a second set of communication beams 134b. In a further example, UE102b may also transmit an uplink beamforming signal to RU106b in one or more transmit directions of UE102b based on a second set of communication beams 134b. RU106b may receive the uplink beamforming signal from UE102b in one or more receive directions of RU106b.

[0022] UE102b may perform beam training to determine the optimal receiving and transmitting directions for beamforming signals. The transmitting and receiving directions of UE102 and base station 104 / RU106 may or may not be the same. In a further example, beamforming signals may be communicated between a first base station / RU106a and a second base station 104e. For example, base station 104e in cell 190e may transmit beamforming signals to RU106a based on one or more transmitting communication beams 138 of base station 104e. RU106a may receive beamforming signals from base station 104e in cell 190e based on one or more receiving RU communication beams 136 of RU106a. In a further example, base station 104e transmits downlink beamforming signals to UE102e based on one or more transmitting communication beams 138 of base station 104e. UE102e receives a downlink beamforming signal from base station 104e based on one or more UE communication beams 130 in the receiving direction of UE102e. UE102e may also transmit an uplink beamforming signal to base station 104e based on one or more UE communication beams 130 in the transmitting direction of UE102e, thereby enabling base station 104e to receive the uplink beamforming signal from UE102e in one or more receiving directions of base station 104e.

[0023] Base station 104 may include and / or be referred to as a network entity. That is, “network entity” may refer to base station 104, or at least one unit of base station 104 such as RU106, DU108, and / or CU110. Base station 104 may also include and / or be referred to as next-generation evolutionary node B (ng-eNB), generation NB (gNB), evolutionary NB (eNB), access point, base transceiver station, radio base station, radio transceiver, transceiver function, basic service set (BSS), extended service set (ESS), TRP, network node, network equipment, or other related terms. Base station 104 or entities in base station 104 may be implemented as an aggregated (monolithic) base station with IAB nodes, relay nodes, sidelink nodes, and a BBU 112 including RU106, DU108, and CU110, or as a separate base station including one or more RU106, DU108, and / or CU110. A set of aggregated or separate base stations may be called a Next Generation Radio Access Network (NG-RAN). In some examples, UE102a operates with dual connectivity (DC) with base stations 104e and RU106a. In such cases, base station 104e may be the master node and base station RU160a may be the secondary node.

[0024] Uplink / downlink signaling may also be communicated via a satellite positioning system (SPS) 114. In one example, the SPS 114 of cell 190c may communicate with one or more UE102s, such as UE102c, and one or more base stations 104 / RU106, such as RU106c. The SPS 114 may correspond to one or more of the Global Navigation Satellite System (GNSS), Global Positioning System (GPS), Non-Terrestrial Network (NTN), or other satellite positioning / location systems. SPS114 may be associated with LTE signals, NR signals (e.g., those based on round-trip time (RTT) and / or multi-RTT), wireless local area network (WLAN) signals, terrestrial beacon systems (TBS), sensor-based information, NR extended cell ID (NR E-CID) technology, downlink departure angle (DL-AoD), downlink arrival time difference (DL-TDOA), uplink arrival time difference (UL-TDOA), uplink arrival angle (UL-AoA), and / or other systems, signals, or sensors.

[0025] Referring further to Figure 1, in a particular embodiment, one of the UE102 may include an uplink control information (UCI) multiplexing component 140 configured to multiplex UCIs for multiple codewords on a physical uplink shared channel (PUSCH) resource in order to generate multiplexed UCIs, where the multiple codewords are associated with one or more beams, and the component is configured to transmit the multiplexed UCIs on the PUSCH resource to network entities.

[0026] In a particular embodiment, either base station 104 or a network entity of base station 104 may include a UCI receiving component 150 configured to transmit a configuration for UCI over a physical uplink control channel (PUCCH) resource to the UE, and to receive a multiplexed UCI over the PUCCH resource from the UE, the UCI being for multiple codewords associated with one or more beams.

[0027] Accordingly, Figure 1 illustrates a wireless communication system that may be implemented in relation to one or more other embodiments of the figures described herein, such as the embodiments shown in Figures 2A to 9C. Furthermore, 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.

[0028] Figures 2A to 2D show the uplink resources for transmitting UCIs, Figures 200 to 260. Network entities can configure a UE to transmit UCIs on PUCCH204a, as in Figure 200, or on PUSCH202c, as in Figure 220, based on UCI multiplexing. A UCI may include a scheduling request, a hybrid automatic retransmission request acknowledgment (HARQ-ACK), and channel status information (CSI). Thus, a UCI can 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, a UE does not transmit scheduling requests on a PUSCH. A CSI may also include CSI part 1 and CSI part 2, and CSI part 2 may be punctured into two sections by symbols having decoded reference signal (DMRS) resource elements and data resource elements, such as CSI part 2 only, supporting variable length. If a network entity configures the UE to transmit UCIs on PUCCH204 with duplicate symbols and data on PUSCH202a and / or 202b, as shown in Figures 200, 240, and 260, the UE may transmit UCIs on PUSCH202c, as shown in Figure 220.

[0029] In the case of single codeword push transmission and single beam push transmission, the UE transmits the UCI on the first resource element (RE) of the resource block (RB) and transmits data on the remaining REs of the RB in multiple layers based on the same modulation coding scheme (MCS). The network entity is

[0030]

number

[0031] The first beta offset,

[0032]

number

[0033] The second beta offset, and

[0034]

number

[0035] Based on the third beta offset, the number of REs for HARQ-ACK, CSI Part 1, and CSI Part 2 can be determined. UE is R HARQ-ACK Based on this, the coding rate of HARQ-ACK is determined, and R CSI-part1 Based on this, the coding rate for CSI Part 1 is determined, R CSI-part2 The coding rate for CSI Part 2 is determined based on the following. The coding rate R and beta offset of the data correspond to the following:

[0036]

number

[0037] The number of REs in HARQ-ACK is Q HARQ-ACK , CSI Part 1 RE's number Q CSI-part1 , and several Qs of RE in CSI Part 2 CSI-part2is the number of bits of HARQ-ACK having cyclic redundancy check (CRC) O HARQ-ACK so that it can be obtained based on the number of bits of CSI part 1 having CRC O CSI-part1 the number of bits of CSI part 2 having CRC O CSI-part2 as well as the coding rate and modulation order Q m is as follows.

[0038]

Number

[0039] Here, α corresponds to a scaling factor configured by radio resource control (RRC) signaling from a network entity, and N RE corresponds to the number of REs for PUSCH transmission excluding DMRS.

[0040] The network entity may schedule the UE to transmit PUSCH202 with two codewords, and different MCSs may be configured for each codeword. Therefore, Q mThe modulation order and the target coding rate R of each codeword may differ. For a UE that can transmit PUSCH202 simultaneously from multiple beams, the network entity may schedule the UE to transmit a first PUSCH202a and a second PUSCH202b from different beams and to transmit PUSCH204 with overlapping symbols, as shown in Figures 240-260. The network entity may indicate beams for PUSCH by indicating transmit configuration instructions or spatial relation information. The network entity may schedule the UE to transmit a first PUSCH202a and a second PUSCH202b from different transmit configuration instructions or spatial relation information. The first PUSCH202a and the second PUSCH202b may be from two different UE panels directed to two different TRPs. That is, two different PUSCH202a-202b may be associated with different TRPs (for example, based on different CORESETPoolIndexes configured by the network entity through RRC signaling).

[0041] Referring to Figure 2D, the network entity may also schedule UEs to transmit a first PUSCH202a and a second PUSCH202b from different beams and a first PUCCH204a and a second PUCCH204b with overlapping symbols, as shown in Figure 260. The first PUSCH202a and the first PUCCH204a may be from different UE panels than the second PUSCH202b and the second PUCCH204b, and the different UE panels may be directed to different TRPs. That is, two different PUSCH202a-202b and two different PUCCH204a-204b may be associated with different TRPs (for example, based on different CORESETPoolIndex configured by the network entity through RRC signaling). PUCCH204a-204b may carry the same or different UCI payloads corresponding to overlapping or non-overlapping time-frequency resources.

[0042] Therefore, UCI multiplexing of multicodeword PUSCH and multibeam PUSCH can enable a UE to transmit UCI on multiple codewords and / or multiple beams. For example, a UE transmits UCI based on multibeam PUSCH when a first PUSCH204a and / or a second PUSCH204b have a resource collision with a first PUSCH202a and a second PUSCH202b from different beams, as shown in Figures 240–260. A resource collision refers to communications with overlapping resources (for example, a time-domain resource collision may refer to different transmissions with overlapping symbols). UCI multiplexing with multiple codewords and / or multibeams can reduce latency and overhead for UCI reporting because the UE does not need to transmit UCI on PUSCH204 in addition to the data on PUSCH202. Accordingly, Figures 2A–2D show PUSCH resources associated with the signaling procedure for UCI multiplexing, which is further explained in Figure 3.

[0043] Figure 3 shows signaling diagram 300 for multicodeword PUSCH transmission based on UCI multiplexing. UE 102 may report 306 the UE capability for UCI multiplexing over multicodeword PUSCH to network entity 104. In other embodiments, network entity 104 may receive UE capability instructions from a core network such as an Access and Mobility Management Function (AMF). In yet another embodiment, network entity 104 may receive UE capability instructions from another base station / network entity (e.g., gNB or eNB). UE102 may send a UE capability report 306 (for example, for UCI multiplexing on multicodeword PUSCH) indicating at least one of the following: whether UE102 supports UCI transmission over multicodeword PUSCH, whether UE102 supports UCI transmission over one codeword and / or all codewords of multicodeword PUSCH, or whether UE102 supports transmitting data in other codewords with the same RE used for UCI in one codeword for one-codeword-based UCI multiplexing. UE102 reports 306 the UE capability per feature set, per band, per combination of bands, or per UE.

[0044] Network entity 104 indicates to UE 102 the configuration of PUCCH resources for UCI feedback (e.g., based on UE capabilities). Network entity 104 may transmit the configuration of PUCCH resources for UCI feedback through control signaling. Network entity 104 may use RRC signaling to indicate an RRCReconfiguration message to UE 102 or a System Information Block (SIB). The SIB may be a conventional type SIB (e.g., SIB1) or a different SIB transmitted by network entity 104 (e.g., SIB J, where J corresponds to an integer greater than 21).

[0045] In the case of a multicodeword PUSCH transmission, the network entity 104 may also optionally transmit a parameter instruction to the UE 102 308 indicating a UCI multiplexing scheme for the multicodeword PUSCH transmission. For example, the UCI multiplexing scheme may include multiplexing the UCI on one codeword of the multicodeword PUSCH transmission. As another example, the UCI multiplexing scheme may include multiplexing the UCI on all codewords of the multicodeword PUSCH transmission. The network entity 104 may configure the UE 102 based on the parameter instruction of the UCI multiplexing scheme transmitted 308 for the configuration of the PUSCH resource, through the same or different control signaling. For example, the network entity 104 transmits a trigger instruction to the UE 102 310 for the multicodeword PUSCH, which may optionally include a parameter instruction for UCI multiplexing on the multicodeword PUSCH. Thus, the network entity 104 may transmit the parameter instruction with the trigger instruction 310 rather than transmitting the parameter instruction with the configuration 308.

[0046] Network entity 104 may additionally send a second trigger instruction 312 to UE 102 through additional control signaling to trigger UCI feedback from UE 102. The second trigger instruction triggers PUSCH and PUCCH, which have overlapping resources in the time domain. In some examples, both PUSCH and PUCCH resources are configured in the first control signaling sent 308 to UE 102. Network entity 104 may trigger PUSCH 310 to UE 102 to report UCI feedback, whether or not it has data (e.g., aperiodic CSI or semi-persistent CSI). Network entity 104 may send trigger instructions 310-312 based on media access control-control element (MAC-CE) or downlink control information (DCI).

[0047] UE102 determines whether to multiplex the UCI over PUSCH based on one or more control signals that UE102 receives 308, 310, 312 from network entity 104. Further details regarding the UE's determination of the UCI multiplexing scheme for multicodeword PUSCH are described with reference to Figures 4A to 6C. UE102 may determine the UCI multiplexing scheme for multicodeword PUSCH 314 based on parameter instructions. That is, UE102 may determine whether to transmit the UCI 316 in one or more codewords of the multicodeword PUSCH transmission, or to transmit the UCI 316 in all codewords of the multicodeword PUSCH transmission. For example, UE102 transmits the UCI 316 on PUSCH based on the multicodeword PUSCH transmission using the determined UCI multiplexing scheme. Network entity 104 also determines a multiplexing scheme based on the configured / shown techniques for UE 102 in order to receive the multicodeword PUSCH with multiplexed UCI from UE 102 318. Figure 3 shows the signaling procedure for the multicodeword PUSCH, and Figures 4A–4C show the time-frequency resources used for the multicodeword PUSCH.

[0048] Figures 4A–4C show resource figures 400–440 for codewords with and without a UCI. Figure 4A can be paired with either Figure 4B or Figure 4C. In the first example, the UE may transmit a UCI based on a predefined / fixed codeword. The UCI includes a HARQ-ACK 406, CSI Part 1 408a, and CSI Part 2 408b, as shown in Figure 400. The HARQ-ACK 406 can be associated with a smaller payload size (e.g., 11 bits or less) or a larger payload size (e.g., greater than 11 bits). The codeword may also include data 402 and DMRS 410. Channel coding of the UCI is based on the modulation order and coding rate of the codeword.

[0049] Network entities should not schedule multicodewords PUSCH that have UCI. For example, a network entity might schedule UCI with codeword 1, as shown in Figure 400, but not with codeword 2, as shown in Figures 420-440 (e.g., not schedule both codewords / multicodewords that have UCI in both codeword 1 and 2). Instead, the RE430b-430c in codeword 2 corresponding to the same RE430a used for UCI in codeword 1 might be the RE430b in codeword 2 (e.g., empty / unused RE) that is not available for PUSCH rate matching, as shown in Figure 420. Alternatively, the RE430b-430c in codeword 2 corresponding to the same RE430a used for UCI in codeword 1 might be the RE430c for codeword 2 data 402 that is available for PUSCH rate matching, as shown in Figure 440.

[0050] For codewords without a UCI (e.g., codeword 2), a network entity may configure whether the RE430b-430c corresponding to the same RE430a used for UCI in a codeword with a UCI (e.g., codeword 1) are either RE430c available for PUSCH rate matching through control signaling such as RRC signaling, MAC-CE, or DCI, or RE430b not available. The UE may report to the network entity the UE's ability to determine whether the same RE430a used in a codeword with a UCI, or certain types of UCI (e.g., HARQ-ACK406, CSI Part 1 408a, and / or CSI Part 2 408b), are either RE430c available for PUSCH rate matching or RE430b not available. The UE may determine, based on the precoder indicated for PUSCH transmission, whether the same RE430a used in a UCI or a codeword with certain types of UCIs is an available RE430c or an unavailable RE430b for PUSCH rate matching. If the precoder indicates a non-coherent or partially coherent transmission, the UE determines that the RE for the other codeword is an available RE430c. Otherwise, the UE determines that the RE for the other codeword is an unavailable RE430b. A non-coherent or partially coherent transmission indicates that, for at least one layer, at least one PUSCH antenna port includes zero-power (ZP) transmission.

[0051] In the second example, the UE may transmit the UCI with a UE-decision codeword, and the channel coding for the UCI is based on the modulation order and coding rate of the UE-decision codeword. Network entities avoid scheduling multicodeword PUSCH which has a UCI with multiple codewords. That is, a network entity may schedule a UCI with codeword 1, as shown in Figure 400, but avoid scheduling multiple codewords with UCIs, as shown in Figures 420-440 (for example, not scheduling both codewords 1 and 2 which have UCIs). The UE selects a codeword based on the MCS for each codeword. For example, the UE selects the codeword with the highest MCS to transmit the UCI. If the MCS is the same for both codewords, the UE may select either the first or last codeword of the codewords.

[0052] In some embodiments, the UE selects a codeword based on the UCI of each codeword, or the number of encoded bits per layer or across layers of several types of UCI (e.g., HARQ-ACK406, CSI Part 1 408a, and / or CSI Part 2 408b). If multiple codewords have the same number of encoded bits, the UE may select the first or last codeword among the multiple codewords. The UE selects a codeword across all layers of the codeword. HARQ-ACK The corresponding number of encoding bits for HARQ-ACK406, W CSI-part1 The corresponding number of CSI Part 1 408a encoding bits, and W CSI-part2 The corresponding CSI Part 2 408b encoding bit count is expressed as the codeword modulation order Qm, the codeword layer count L, and the HARQ-ACK406 RE count Q. HARQ-ACK CSI Part 1 408a RE number Q CSI-part1 CSI Part 2 408b RE number Q CSI-part2 Based on this, the following can be decided: W HARQ-ACK =Q mLQ HARQ-ACK , W CSI-part1 =Q m LQ CSI-part1 , W CSI-part2 =Q m LQ CSI-part2 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 of the codewords for initial transmission and another for retransmission, the UE may transmit the UCI with the codeword for initial transmission, which may indicate that the network entity has successfully received a previous transmission of the codeword. The UE may report the index of the selected codeword to the network entity via PUSCH. The network entity may configure N scrambling identifiers (IDs) on PUSCH for DMRS410 or data 402 through RRC signaling. If the UE transmits the UCI with the Nth codeword, the UE transmits DMRS410 based on the Nth configuration ID. The UE may also semi-statically select a codeword for UCI multiplexing. For example, the UE may indicate a preferred codeword to the network entity through a UE capability report, RRC message, UE auxiliary information, or MAC-CE.

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

[0054] Network entities may also indicate codeword indices through MAC-CE. Network entities may indicate serving cell indices, bandwidth portion (BWP) indices, and codeword indices for Type 1 configured grant (CG) PUSCH / Type 2 CG-PUSCH / Dynamic Grant PUSCH. Network entities may indicate codeword indices for Type 1 CG-PUSCH, Type 2 CG-PUSCH, or Dynamic Grant PUSCH using a single codeword indice for common instructions. Alternatively, network entities may indicate codeword indices for Type 1 CG-PUSCH, Type 2 CG-PUSCH, or Dynamic Grant PUSCH based on separate codeword indices for separate instructions. If no codeword indices are configured, the UE may transmit UCI with a first codeword. Alternatively, if no codeword indices are configured, this may indicate that UCI transmission with a multi-codeword PUSCH is invalid, and the UE may drop a PUCCH or PUSCH when the PUCCH and PUSCH have overlapping resources in the time domain.

[0055] Network entities may also further indicate codeword indices through DCI. The DCI may be the same DCI used to schedule the PUSCH. Network entities may explicitly indicate codeword indices (e.g., codeword indices relative to UCI) using the DCI field. Alternatively, network entities may implicitly indicate codeword indices (e.g., initiated control channel element (CCE) indices) based on the PDCCH location. Odd initiated CCE indices may indicate the first codeword, and even initiated CCE indices may indicate the second codeword. Figures 4A–4C show the UCI for one codeword in a multicodeword PUSCH transmission. Figures 5A–5C show the UCI for multiple codewords in a multicodeword PUSCH transmission.

[0056] Figures 5A to 5C show resource diagrams 500 to 540 of codewords associated with UCI iterations (or UCI partitions) 508a to 508b. Figure 5A may be paired with either Figure 5B or Figure 5C. A UE may transmit UCI 508 over multiple codewords (e.g., codeword 1 and codeword 2) based on a first UCI iteration 508a, as shown in Figure 500, and based on a second UCI iteration 508b, as shown in Figures 520 to 540. Channel coding for UCI 508 is based on the modulation order and coding rate for multiple codewords. A network entity may configure a common set of beta offsets and scaling factors for UCI 508 across multiple codewords, or it may configure separate sets of beta offsets and scaling factors for UCI 508 within each codeword.

[0057] Figure 500 shows an example of codeword 1, and Figures 520-540 show different examples of codeword 2. The UE may transmit UCI iteration 508 through multiple codewords. For UCI 508 associated with the N codeword PUSCH, the UE transmits N UCI iterations 508. The UE may transmit a second UCI iteration 508b as shown in Figure 520, using the same RE used for the first UCI iteration 508a as shown in Figure 500, or with a different RE as shown in Figure 540. The codeword may also include data 402 and DMRS 410.

[0058] The UE may calculate the number of REs per layer or across layers for UCI508 based on the number of REs per layer or across layers for the codeword. The UE may also determine the index of the codeword. In another example, the UE calculates the number of REs per layer or across layers for UCI508 based on the maximum, minimum, or average number of REs per layer or across layers for the codeword by the MCS for the codeword. The number of REs per layer for UCI508 is based on the MCS for codeword j.

[0059]

number

[0060] This is shown as follows: Here, the number of REs Q for UCI508 per layer. UCI This can be calculated based on the following:

[0061]

number

[0062] or

[0063]

number

[0064] or

[0065]

number

[0066] Here, J indicates the number of codewords. A network entity may configure the number of REs for UCI iteration 508 (or UCI partition) in each codeword through RRC signaling, MAC-CE, or DCI. The network entity may also configure whether the number of REs for UCI 508 is the same across all codewords, or whether the UE determines the number of REs separately for each codeword based on its configuration. The UE may report to the network entity, via UE capability or UE auxiliary information, the requested or supported number of REs for UCI iteration 508 (or UCI partition) in each codeword. The UE may also report whether it supports the number of REs for UCI iteration 508 (or UCI partition) being the same across all codewords, or whether the UE determines the number of REs separately for each codeword based on its configuration.

[0067] In some embodiments, the UE transmits a portion of the UCI 508 (e.g., a UCI partition) in a codeword. For example, in Figure 500, the UE may transmit UCI Part 1 508a for codeword 1, and in Figures 520-540, the UE may transmit UCI Part 2 508b for codeword 2. For a UCI 508 on the N codeword PUSCH, the UE may divide the UCI 508 into N parts and transmit each part in its respective codeword. If the UCI 508 includes a HARQ-ACK, CSI Part 1, and CSI Part 2, the UE may similarly divide the HARQ-ACK into N parts, CSI Part 1 into N parts, and CSI Part 2 into N parts and transmit each part in its respective codeword. In other embodiments, the UE transmits each part of the UCI 508 in its respective codeword. If the UCI includes a HARQ-ACK, CSI Part 1, and CSI Part 2, the UE divides the HARQ-ACK into N parts, CSI Part 1 into N parts, and CSI Part 2 into N parts, and transmits each of the N parts with each of the N codewords.

[0068] A network entity may configure / indicate to the UE whether to transmit UCI508 based on UCI iteration or UCI partitioning techniques via RRC signaling, MAC-CE, or DCI. In an example, the network entity may configure a UCI transmission scheme (e.g., iteration or partitioning based on spatial domain multiplexing (SDM)) via PUSCH-Config, UCI-OnPUSCH, or CG-UCI-OnPUSCH. In another example, the network entity may indicate a UCI transmission scheme using the DCI field. The UE may report supported UCI transmission schemes via UE capability reports and / or UE auxiliary information.

[0069] Figures 6A–6C show resource diagrams 600–640 for codewords associated with hybrid multiplexing of UCI types. Figure 6A may be paired with either Figure 6B or Figure 6C. Furthermore, Figure 6A may correspond to the detailed example in Figure 5A. UCI630 for codeword 1 corresponds to HARQ-ACK406, CSI Part 1 408a, and CSI Part 2 408b, as shown in Figure 600, while CSI Part 408 for codeword 2 lacks HARQ-ACK406 and corresponds to CSI Part 1 408a and CSI Part 2 408b, as shown in Figures 620–640. Resource diagrams 600–640 also include data 402 and DMRS410.

[0070] The UE may transmit several types of UCI630, such as a first HARQ-ACK406 with a smaller payload size (e.g., 11 bits or less), a second HARQ-ACK406 with a larger payload size (e.g., greater than 11 bits), CSI Part 1 408a, and / or CSI Part 2 408b, with one codeword in a multicodeword push transmission, and other combinations of UCI type 408 with multiple codewords in a multicodeword push transmission. In some examples, it is predefined that the UCI transmission is based on a single codeword or multiple codewords. In other examples, the network entity configures the UE to transmit UCI630 based on a single codeword or multiple codewords through RRC signaling. The UE may report to the network entity its capabilities for single-codeword and multicodeword UCI transmissions.

[0071] The UE may determine resource mapping patterns for single-codeword transmissions and multiple-codeword transmissions. In the case of UCI630 in a single-codeword transmission, if the RE used for HARQ-ACK406 in Figure 600 is an RE available for PUSCH rate matching in another codeword, the UE may transmit data 402 in an RE available in another codeword, as shown in Figure 620. Alternatively, the UE may transmit CSI408 (e.g., CSI Part 2 408b) in an RE available in another codeword, as shown in Figure 640. Figures 3 to 6C cover multi-codeword PUSCH transmissions, while Figures 7 to 9C cover multi-beam PUSCH transmissions.

[0072] Figure 7 shows signaling diagram 700 for multibeam PUSCH transmission based on UCI multiplexing. Figure 7 is similar to Figure 3 because multibeam 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. UE 102 may report 706 to network entity 104 its UE capability for UCI multiplexing over a multibeam PUSCH. In other embodiments, network entity 104 may receive UE capability instructions from a core network such as an AMF. In yet another embodiment, network entity 104 may receive UE capability instructions from other base stations / network entities (e.g., gNB or eNB). The UE capability report may indicate whether UE 102 supports transmitting UCI over a multibeam-based PUSCH and / or whether UE 102 supports transmitting UCI over a single PUSCH or multiple PUSCHs with different beams. UE102 can report UE capabilities for each feature set, each band, each combination of bands, or each UE.

[0073] Network entity 104 indicates to UE 102 the configuration of PUCCH resources for UCI feedback (e.g., based on UE capabilities). Network entity 104 may transmit the configuration of PUCCH resources for UCI feedback through control signaling. Network entity 104 may use RRC signaling to indicate an RRCReconfiguration message to UE 102 or SIB. SIB may be a conventional type SIB (e.g., SIB1) or a different SIB transmitted by network entity 104 (e.g., SIB J, where J corresponds to an integer greater than 21).

[0074] In the case of multibeam PUSCH transmission, the network entity 104 may also optionally transmit to the UE 102 parameter instructions 708 that indicate the UCI multiplexing scheme for the multibeam PUSCH transmission. The network entity 104 may configure the UE 102 based on the parameter instructions for the UCI multiplexing scheme via the same or different control signaling as those transmitted 708 for configuring the PUSCH resource. For example, the network entity 104 transmits to the UE 102 a first trigger instruction for the first PUSCH on the first beam of the multibeam PUSCH and a second trigger instruction for the second PUSCH on the second beam 710a-710b. Transmissions 710a-710b may also optionally include parameter instructions for UCI multiplexing on the multibeam PUSCH. Thus, the network entity 104 may transmit the parameter instructions 710a-710b with one or more trigger instructions rather than transmitting the parameter instructions 708 with the configuration.

[0075] Network entity 104 may additionally send a third trigger instruction 712 to UE 102 through additional control signaling to trigger UCI feedback from UE 102. The third trigger instruction triggers at least one PUCCH transmission that has resources that overlap in the time domain with the PUCCH transmission(s). In some examples, both the PUCCH(s) and PUCCH resources are configured in the first control signaling sent 708 to UE 102. Network entity 104 may trigger PUCCH(s) 710a-710b to report UCI feedback in which UE 102 has or does not have data (e.g., aperiodic CSI or semi-persistent CSI). Network entity 104 may send trigger instructions 710a, 710b, 712 based on MAC-CE or DCI.

[0076] UE102 determines how to multiplex the UCI associated with the PUCCH resource on the PUCCH(s) based on one or more control signals that UE102 receives 708, 710a-710b, 712 from network entity 104 714. Further details regarding UE's determination of the UCI multiplexing scheme for multibeam PUSCH are described with reference to Figures 8A-9C. UE102 may transmit UCI on one or more PUSCHs. In an example, UE102 may determine the UCI multiplexing scheme for a multibeam PUSCH based on parameter indications 714. UE102 may transmit a multibeam PUSCH transmission using UCI multiplexing to network entity 104 716. Network entity 104 also determines the multiplexing scheme based on the techniques configured / indicated for UE102 in order to receive a multibeam PUSCH with multiplexed UCI from UE102 718. Figure 7 shows the signaling procedure for multibeam PUSCH, and Figures 8A to 8C show the PUSCH resources for multibeam PUSCH.

[0077] Figures 8A to 8C show resource figures 800 to 820 associated with UCI multiplexing. Figure 8A can be paired with either Figure 8B or Figure 8C. The UE may transmit the UCI associated with PUCCH204 along with the data via one of PUSCH202a to 202b according to predefined rules, as shown in Figure 800. Channel coding of the UCI is based on the modulation order and coding rate for the selected PUSCH205a to 205b having the data and UCI. For example, the UE selects a first PUSCH202a having data from Figure 800 as the first PUSCH205a having data and UCI in Figure 820, while the UE selects a second PUSCH202b having data from Figure 800 as the second PUSCH205b having data and UCI in Figure 840.

[0078] The UE may select a PUSCH205 for UCI multiplexing based on the time-domain resources of the PUSCH202. For example, the UE may select a PUSCH205a that starts or ends earlier in time to reduce the latency of the UCI report, as shown in Figure 820. In another example, the UE may select a PUSCH205b that starts or ends later in time to reduce the complexity of the UE for UCI preparation, as shown in Figure 840. If both PUSCH205s start or end simultaneously, the UE may select a PUSCH205 based on the beam index (e.g., the PUSCH205 associated with the first or last Transmit Configuration Indicator (TCI) or the TCI with a lower or higher ID among the Transmit Configuration Indicators (TCIs) shown for both PUSCH205s).

[0079] The UE may select PUSCH205 for UCI multiplexing based on the TCI IDs indicated for PUSCH202 and PUCCH204. In one example, a first PUSCH202a may have TCI ID=2, a second 202b may have TCI ID=1, and PUCCH204 may have TCI ID=2. The UE may select a first PUSCH202a that has the same TCI ID as PUCCH204, or a TCI that shares the same quasi-identical-location (QCL) source reference signal as PUCCH204. The network entity may choose not to schedule PUCCH204 and PUSCH202 using different beams. In another example, the UE selects one of the PUSCH202s based on a particular PUSCH having either the first or last TCI, or the lowest or highest TCI ID among the TCI IDs indicated for both PUSCH202s.

[0080] The UE may also select PUSCH205 for UCI multiplexing based on the TRP ID (e.g., CORESETPoolIndex) for PUSCH202 and PUCCH204. In the example, the first PUSCH202a may have TRP ID=2, the second 202b may have TRP ID=1, and PUCCH204 may have TRP ID=2. The network entity may configure the TRP IDs for the first PUSCH202a, the second PUSCH202b, and PUCCH204 through RRC signaling or MAC-CE. In another example, the UE determines the TRP IDs for PUSCH202 and PUCCH204 based on the TRP ID of the scheduling physical downlink control channel (PDCCH). In yet another example, the UE may determine the TRP ID based on the content of PUCCH204. For example, the UE may determine the TRP ID based on the TRP ID of the downlink signal measured for HARQ-ACK or CSI. The UE may select PUSCH202, which has the same TRP ID as PUCCH204.

[0081] The UE may select a PUSCH205 for UCI multiplexing based on the MCS of each PUSCH202. That is, the UE may select a PUSCH202 with a higher MCS to transmit the UCI on the PUSCH205. If both PUSCH202s are scheduled with the same MCS, the UE may select a PUSCH202 based on the beam index. The UE may also select a PUSCH205 for UCI multiplexing based on the target coding rate or number of coding bits for the UCI on each PUSCH202. The UE may select a PUSCH202 with a lower target coding rate or more coding bits to transmit the UCI. The UE determines the number of coding bits and coding rate based on the beta offset, MCS, scheduled time-frequency resources, and number of layers. If the target coding rate or number of coding bits for the UCI on both PUSCH202s is the same, the UE may select a PUSCH202 based on the beam index.

[0082] Network entities may configure or indicate a PUSCH205 for UCI multiplexing through control signaling. Based on the received control signaling, the UE transmits the UCI associated with PUSCH204 on one of the PUSCH202s. Channel coding of the UCI is based on the modulation order and coding rate for the selected PUSCH205.

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

[0084] A network entity may configure PUSCH205 for UCI multiplexing by indicating a TRP ID (e.g., CORESETPoolIndex) for UCI multiplexing via MAC-CE. MAC-CE may indicate a serving cell index, BWP index, PUCCH resource index, and / or TRP ID. The UE transmits the UCI associated with PUCCH204 on PUSCH202a associated with the same TRP ID.

[0085] In some embodiments, a network entity indicates whether the UE multiplexes the UCI on the scheduled PUSCH202 by a DCI field. The DCI field may include a UCI multiplexing flag. In the 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 cannot multiplex the UCI on the scheduled PUSCH202, and a second state of the bit / UCI flag indicates that the UE can multiplex the UCI on the scheduled PUSCH202. In Figure 800, the first PUSCH202a is associated with UCI flag=1 and the second PUSCH202b is associated with UCI flag=0, where a value of 1 can indicate UCI multiplexing, a value of 0 can indicate no UCI multiplexing, and vice versa.

[0086] Figures 9A–9C show resource figures 900–920 associated with UCI multiplexing. Figure 9A can be paired with either Figure 9B or Figure 9C. The UE may select one of the PUSCH202s to transmit the UCI. The UE may select a PUSCH202 based on beam quality. The UE transmits the UCI associated with PUSCH204 on the selected PUSCH205 / 207. Channel coding of the UCI is based on the modulation order and coding rate for the selected PUSCH205 / 207.

[0087] The UE may report the selected PUSCH index to the network entity explicitly or implicitly. If explicitly indicated, the UE reports the selected PUSCH index in the beam report. The UE may report at least one group of beam indices for simultaneous uplink transmission, and may indicate an ID within a group of beams indicating a beam for UCI reporting. The UE transmits the UCI on PUSCH205 / 207 using the indicated beam. If implicitly indicated, the UE reports the selected PUSCH index based on the DMRS or PUSCH scrambling sequence selection. The network entity may configure two scrambling IDs in the DMRS or PUSCH, the first scrambling ID corresponding to PUSCH202a-202b without UCI, and the second scrambling ID corresponding to PUSCH205a-205b / 207a-207b with UCI.

[0088] Figures 920-940 show UCI multiplexing on both PUSCH205 / 207. In Figure 920, the UE transmits UCI iterations on both PUSCH205 / 207. That is, the UE transmits data and UCI iteration 1 on the first PUSCH207a and data and UCI iteration 2 on the second PUSCH207b. In Figure 940, the UE transmits the UCI on both PUSCH205 / 207 based on the UCI partition. That is, the UE transmits the first part of the UCI (e.g., UCI part 1) on the first PUSCH205a along with the data and UCI part 1, and transmits the second part / remaining part of the UCI (e.g., UCI part 2) on the second PUSCH205b along with the data and UCI part 2.

[0089] In Figure 940, the UE may transmit a UCI on PUSCH205 associated with the same TRP as PUSCH in Figure 900. For example, the first PUSCH202a / 205a corresponds to TRP1, and the second PUSCH202b / 205b corresponds to TRP2. The UE may report the HARQ-ACKs received for the PDSCH from both TRPs, and as a result, the UE may transmit a HARQ-ACK from the first TRP to the PDSCH on the first PUSCH205a associated with the first TRP, and a HARQ-ACK from the second TRP to the PDSCH on the second PUSCH205b associated with the second TRP.

[0090] The UE may similarly report the CSI-RS CSI received from both TRPs, and as a result, the UE can transmit the CSI-RS CSI from the first TRP on the first PUSCH205a associated with the first TRP, and the CSI-RS CSI from the second TRP on the second PUSCH205b associated with the second TRP. The UE may perform independent channel coding of the UCI on each PUSCH205 based on the configuration of the PUSCH205 (e.g., based on MCS, beta offset, time-frequency resources, or scaling factor).

[0091] In Figure 940, a UCI partition may be based on single-channel coding. The UE may calculate the total number of coded bits across both PUSCH205s. Based on the number of REs, the number of layers, and the modulation order of the first PUSCH205a, the UE may transmit a first portion of the coded bits on the first PUSCH205a along with the data and UCI. The UE may transmit a second portion / remaining portion of the coded bits on the second PUSCH205b along with the data and UCI. Network entities may configure UCI multiplexing schemes (e.g., UCI multiplexing on a single PUSCH, UCI iteration on both PUSCH207s, or UCI partitions on both PUSCH205s) through RRC signaling, MAC-CE, or DCI. The UE may report its UE capability and / or preference for UCI multiplexing schemes to network entities using UE capability signaling or UE auxiliary information messages. Figures 3 to 9C illustrate UCI multiplexing for multicodeword and multibeam PUSCH. Figures 10 to 11 show methods for implementing one or more embodiments of Figures 3 to 9C. Specifically, Figure 10 shows an embodiment of one or more embodiments of Figures 3 to 9C by UE 102. Figure 11 shows an embodiment of one or more embodiments of Figures 3 to 9C by network entity 104.

[0092] Figure 10 shows a flowchart 1000 of a method of wireless communication at the UE. Referring to Figures 1 to 9C and Figure 12, the method may be performed by UE 102, UE device 1202, etc., which may include memory 1226', 1206', 1216, and UE 102, UE device 1202 may correspond to the entire UE 102 or the entire UE device 1202, or components of UE 102 or UE device 1202 such as wireless baseband processor 1226 and / or application processor 1206.

[0093] UE102 sends a UE capability report 1006 to the network entity showing the UE's ability to multiplex multiple codewords associated with one or more beams on a PUSCH resource. For example, referring to Figure 3, UE102 sends 306 a UE capability report 306 to the network entity 104 regarding UCI multiplexing on a multicodeword PUSCH. Referring to Figure 7, UE102 sends 706 a UE capability report 706 to the network entity 104 regarding UCI multiplexing on a multibeam PUSCH. In further examples, the UE capability report shows the UE capability for UCI multiplexing on both multicodeword and multibeam PUSCH.

[0094] UE102 receives the configuration of the UCI on the PUCCH resource from the network entity.1008 See, for example, Figures 3 and 7, UE102 receives the configuration of the PUCCH resource for UCI feedback from the network entity 104.308,708

[0095] UE102 receives a first trigger instruction from the network entity for the transmission of a multiplexed UCI on the PUSCH resource 1010a. For example, referring to Figure 3, UE102 receives a trigger instruction from the network entity 104 for the multicodeword PUSCH 310a. Referring to Figure 7, UE102 receives a trigger instruction from the network entity 104 for the first PUSCH on the first beam 710a.

[0096] UE102 receives a second trigger instruction 1010b from the network entity for the transmission of a multiplexed UCI on the PUSCH resource. The first and second trigger instructions are for the first and second PUSCH transmissions on the first and second beams. For example, referring to Figure 7, after receiving a trigger instruction 710a for the first PUSCH on the first beam, UE102 receives a trigger instruction 710b from the network entity 104 for the second PUSCH on the second beam.

[0097] UE102 receives a UCI trigger from the network entity for sending a multiplexed UCI on the PUSCH resource to the network entity.1012 For example, referring to Figures 3 and 7, UE102 receives a trigger instruction from the network entity 104 for UCI feedback from UE102 to the network entity 104.312,712

[0098] UE102 decides to transmit UCI on the PUSCH resource instead of the PUSCH resource, based on multiplexing UCI for multiple codewords on the PUSCH resource.1014 Referring to Figure 3, UE102 determines a UCI multiplexing scheme for a multicodeword PUSCH.314 Referring to Figure 7, UE102 determines a UCI multiplexing scheme on a multibeam PUSCH.714

[0099] UE102 generates a multiplexed UCI by multiplexing UCIs for multiple codewords on the PUSCH resource, and the multiple codewords are associated with one or more beams. For example, referring to Figures 5A to 6C, UE102 multiplexes UCI508 on codeword 1 and codeword 2. Referring to Figures 8A to 8C, UCI508 is multiplexed on one beam. Referring to Figures 9A to 9C, UCI508 is multiplexed on multiple beams. Multiplexing UCIs for multiple codewords may include UCI multiplexing for one codeword in a multicodeword PUSCH and / or UCI multiplexing for all codewords in a multicodeword PUSCH.

[0100] UE102 transmits a multiplexed UCI over the PUSCH resource to the network entity.1016 For example, referring to Figures 3 to 6C, UE102 transmits a multicodeword PUSCH transmission using UCI multiplexing to the network entity 104.316 Referring to Figures 7 to 9C, UE102 transmits a multibeam PUSCH transmission using UCI multiplexing to the network entity 104.716 Figure 10 illustrates the method from the UE side of the wireless communication link, and Figure 11 illustrates the method from the network side of the wireless communication link.

[0101] Figure 11 is a flowchart 1100 of a method of wireless communication in a network entity. Referring to Figures 1 to 9C and Figure 13, the method may be performed by one or more network entities 104, where the network entities 104 may correspond to a base station or a base station unit such as RU106, DU108, CU110, RU processor 1306, DU processor 1326, or CU processor 1346. One or more network entities 104 may include memory 1306' / 1326' / 1346', where memory 1306' / 1326' / 1346' may correspond to one or more network entities 104 as a whole or to a component of one or more network entities 104 such as RU processor 1306, DU processor 1326, or CU processor 1346.

[0102] Network entity 104 receives a UE capability report from the UE 1106, which shows the UE's ability to multiplex multiple codewords associated with one or more beams on a PUSCH resource. For example, referring to Figure 3, network entity 104 receives a UE capability report from UE 102 regarding UCI multiplexing on a multicodeword PUSCH. Referring to Figure 7, network entity 104 receives a UE capability report from UE 102 regarding UCI multiplexing on a multibeam PUSCH. In further examples, the UE capability report shows the UE capability for UCI multiplexing on both multicodeword and multibeam PUSCH.

[0103] Network entity 104 sends the UCI configuration on the PUCCH resource to the UE 1108. For example, referring to Figures 3 and 7, network entity 104 sends the PUCCH resource configuration for UCI feedback to UE 102 308, 708.

[0104] Network entity 104 sends a first trigger instruction 1110a to the UE for receiving a multiplexed UCI on the PUSCH resource. Referring to Figure 3, for example, network entity 104 sends a trigger instruction 310a to UE 102 for the multicodeword PUSCH. Referring to Figure 7, network entity 104 sends a trigger instruction 710a to UE 102 for the first PUSCH on the first beam.

[0105] Network entity 104 transmits a second trigger instruction 1110b to the UE for the reception of a multiplexed UCI on the PUSCH resource. The first and second trigger instructions are for the first and second PUSCH transmissions on the first and second beams. For example, referring to Figure 7, after transmitting a trigger instruction 710a for the first PUSCH on the first beam, network entity 104 transmits a trigger instruction 710b to the UE 102 for the second PUSCH on the second beam.

[0106] Network entity 104 sends a UCI trigger 1112 to the UE for receiving multiplexed UCI from the UE on the PUSCH resource. For example, referring to Figures 3 and 7, network entity 104 sends a trigger instruction 312, 712 to the UE 102 for UCI feedback from the UE 102 to network entity 104.

[0107] Network entity 104 receives a UCI multiplexed on a PUSCH resource from the UE. The UCI is for multiple codewords associated with one or more beams. For example, referring to Figures 3 to 6C, network entity 104 receives a multicodeword PUSCH transmission with UCI multiplexing from UE 102. Referring to Figures 7 to 9C, network entity 104 receives a multibeam PUSCH transmission with UCI multiplexing from UE 102. The UE device 1202 may perform the method of flowchart 1000 as shown in Figure 12. One or more network entities 104 may perform the method of flowchart 1100 as shown in Figure 13.

[0108] Figure 12 is a Figure 1200 showing an example of a hardware embodiment for UE device 1202. UE device 1202 may be UE 102, a component of UE 102, or capable of performing UE functions. UE device 1202 may include an application processor 1206, which may have on-chip memory 1206'. In this 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 can control a barometric pressure sensor / altimeter, motion sensors such as an inertial management unit (IMU), a gyroscope, an accelerometer, a light detection and ranging (LIDAR) device, a radio-assisted sensing and ranging (RADAR) device, an acoustic navigation and ranging (SONAR) device, a magnetometer, an audio device, and / or other technologies used for positioning.

[0109] The UE device 1202 may further include a wireless baseband processor 1226, which may be referred to as a modem. The wireless baseband processor 1226 may have on-chip memory 1226'. Together with and similar to the application processor 1206, the wireless baseband processor 1226 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. The wireless baseband processor 1226 may further be coupled to one or more subscriber identification module (SIM) cards 1220, and / or one or more transceivers 1230 (e.g., wireless RF transceivers).

[0110] Within one or more transceivers 1230, the UE device 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. Each of the Bluetooth module 1232, WLAN module 1234, SPS module 1236, and cellular module 1238 may include an on-chip transceiver (TRX), or, in some cases, only a transmitter (TX) or only a receiver (RX). Each of the Bluetooth module 1232, WLAN module 1234, SPS module 1236, and cellular module 1238 may include a dedicated antenna for communication with one or more other nodes, and / or utilize antenna 1240. For example, UE device 1202 can communicate with other UEs 102 (e.g., sidelink communication) and / or network entities 104 (uplink / downlink communication) via antenna 1240 through transceiver(s) 1230, where network entities 104 may correspond to base stations or base station units such as RU106, DU108, or CU110.

[0111] The wireless baseband processor 1226 and the application processor 1206 may each include computer-readable media / memories 1226' and 1206', respectively. An additional memory module 1216 may also be considered computer-readable media / memories. The computer-readable media / memories 1226', 1206', and 1216 may be non-temporary. The wireless baseband processor 1226 and the application processor 1206 may each be responsible for general processing, including the execution of software stored in the computer-readable media / memories 1226', 1206', and 1216. When the software is executed by the wireless baseband processor 1226 / application processor 1206, it causes the wireless baseband processor 1226 / application processor 1206 to perform various functions described herein. The computer-readable media / memories may also be used to store data that is manipulated by the wireless baseband processor 1226 / application processor 1206 when the software is executed. The wireless baseband processor 1226 / application processor 1206 may be components of UE 102. UE device 1202 may be a processor chip (e.g., a modem and / or application), or it may include only the wireless baseband processor 1226 and / or the application processor 1206. In other examples, UE device 1202 may be the entire UE 102, or it may include additional modules of device 1202.

[0112] As shown in Figure 1, the UCI multiplexing component 140 is configured to generate a multiplexed UCI by multiplexing UCIs for multiple codewords on a PUSCH resource, the multiple codewords are associated with one or more beams, and the multiplexed UCI is transmitted on the PUSCH resource to network entities. The UCI multiplexing component 140 may be located in the application processor 1206 (e.g., in 140a), in the wireless baseband processor 1226 (e.g., in 140b), or in both the application processor 1206 and the wireless baseband processor 1226. The UCI multiplexing components 140a-140b may be one or more hardware components specifically configured to perform the described process / algorithm, may be implemented by one or more processors configured to perform the described process / algorithm, may be stored in a computer-readable medium for implementation by one or more processors, or a combination thereof.

[0113] Figure 13 is a figure 1300 showing an example of a hardware embodiment of one or more network entities 104. One or more network entities 104 may be a base station, a component of a base station, or may perform the functions of a base station. One or more network entities 104 may include or correspond to at least one of RU106, DU, 108, or CU110. CU110 may include a CU processor 1346, which may have on-chip memory 1346'. In some embodiments, CU110 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. CU110 may communicate with DU108 through a midhall link 162, such as an F1 interface, between the communication interface 1348 of CU110 and the communication interface 1328 of DU108.

[0114] DU108 may include a DU processor 1326, which may have on-chip memory 1326'. In some embodiments, DU108 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. DU108 may communicate with RU106 through a fronthaul link 160 between the communication interface 1328 of DU108 and the communication interface 1308 of RU106.

[0115] RU106 may include an RU processor 1306, which may have on-chip memory 1306'. In some embodiments, RU106 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. RU106 may further include an antenna 1340, which may be coupled to one or more transceivers 1330, thereby enabling RU106 to communicate with UE102 via the antenna 1340 through one or more transceivers 1330.

[0116] The on-chip memories 1306', 1326', 1346', and the additional memory modules 1316, 1336, 1356 may each be considered computer-readable media / memory. Each computer-readable media / memory may be non-temporary. Each of the processors 1306, 1326, and 1346 is responsible for general processing, including the execution of software stored in the computer-readable media / memory. When the software is executed by the corresponding processor(s) 1306, 1326, and 1346, it causes the processor(s) 1306, 1326, and 1346 to perform various functions described herein. The computer-readable media / memory may also be used to store data that is manipulated by the processor(s) 1306, 1326, and 1346 when the software is executed. In the example, the UCI receiving component 150 may be located in one or more network entities 104, such as in CU110, in both CU110 and DU108, in each of CU110, DU108, and RU106, in DU108, in both DU108 and RU106, or in RU106.

[0117] As described in Figure 1, the UCI receiving component 150 is configured to transmit a configuration for the UCI on the PUSCH resource to the UE and to receive a multiplexed UCI on the PUSCH resource from the UE, the UCI being for multiple codewords associated with one or more beams. The UCI receiving component 150 may be located in one or more processors of one or more network entities 104, such as the RU processor 1306 (e.g., in 150a), the DU processor 1326 (e.g., in 150b), and / or the CU processor 1346 (e.g., in 150c). The UCI receiving components 150a-150c may be one or more hardware components specifically configured to perform the described process / algorithm, or may be performed by one or more processors 1306, 1326, 1346 configured to perform the described process / algorithm, or may be stored in a computer-readable medium for performance by one or more processors 1306, 1326, 1346, or a combination thereof.

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

[0119] The detailed descriptions provided herein illustrate various configurations related to the drawings and do not represent the only configurations in which the concepts described herein may be implemented. The detailed descriptions include specific details for the purpose of providing a complete explanation of the various concepts. However, these concepts may be implemented without these specific details. In some cases, well-known structures and components are shown in block diagrams to avoid obscuring those concepts.

[0120] Embodiments of wireless communication systems, such as telecommunications systems, are presented with reference to various devices and methods. These devices and methods are described in the following detailed description and are illustrated in the accompanying drawings by various blocks, components, circuits, processes, call flows, systems, algorithms, etc. (collectively referred to as “elements”). These elements 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 the design constraints imposed on the overall system.

[0121] An element, or any part of an element, or any combination of elements, may be implemented as a “processing system” comprising one or more processors. Examples of processors include, but are not limited to, microprocessors, microcontrollers, graphics processing units (GPUs), central processing units (CPUs), application processors, digital signal processors (DSPs), reduced instruction set computing (RISC) processors, system-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 various functions described throughout this disclosure. One or more processors in a processing system may be referred to as software, firmware, middleware, microcode, hardware description language, or otherwise, and may run software. Software is broadly interpreted to mean instructions, instruction sets, code, code segments, program code, programs, subprograms, software components, applications, software applications, software packages, routines, subroutines, objects, executable files, execution threads, procedures, functions, or combinations thereof.

[0122] If the functions described herein are implemented in software, the functions may be stored or encoded as one or more instructions or codes on a computer-readable medium, such as a non-temporary computer-readable storage 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, and other magnetic storage devices, combinations of these types of computer-readable media, or any other media that can be used to store computer executable code in the form of instructions or data structures accessible by a computer. Storage media may be any available media accessible by a computer.

[0123] The embodiments, examples, and / or uses described herein can be implemented across many different platform types, devices, systems, shapes, sizes, and packaging arrangements. For example, the embodiments, examples, and / or uses can be implemented through integrated chip implementations and other non-modular component-based devices such as end-user devices, vehicles, communication devices, computing devices, industrial equipment, retail / purchase devices, medical devices, artificial intelligence (AI)-enabled devices, and machine learning (ML)-enabled devices. The embodiments, examples, and / or uses may range from chip-level or modular components to non-modular components or non-chip-level implementations, and further to aggregated, distributed, or original equipment manufacturer (OEM) devices or systems incorporating one or more of the technologies described herein.

[0124] Devices incorporating the embodiments and features described herein may also include additional components and functions for carrying out and practicing the claimed embodiments and features. For example, the transmission and reception of radio signals necessarily involve several components for analog and digital purposes, such as hardware components, antennas, RF chains, power amplifiers, modulators, buffers, processors, interleavers, adders / adders, etc. The techniques described herein can be implemented in a wide variety of devices, chip-level components, systems, distributed, centralized or distributed components, end-user devices, etc., in various configurations.

[0125] The description is provided to enable those skilled in the art to carry out the various embodiments described herein. Various modifications of these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein can be applied to other embodiments. Accordingly, the claims are not limited to the embodiments described herein and should be interpreted in light of the entire scope of this disclosure, consistent with the language of the claims.

[0126] References to elements in the singular form mean "one or more" and not "only one" unless otherwise specified. Terms such as "when," "when," and "while" do not imply an immediate temporal relationship or response. That is, these phrases, for example, "when," do not imply an immediate action in response to or during the occurrence of an action, but simply imply that an action occurs if the conditions are met, without requiring any specific or immediate time constraints for the action to occur. The terms "may," "might," and "can" as used in this disclosure often have specific meanings. For example, "may" refers to an acceptable 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., "can do"). The phrase "for example" often has a similar meaning to "may," and therefore "may" may be excluded from sentences containing "for example" or other similar phrases.

[0127] Unless otherwise specified, the term "several" 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 in which one or more elements are numbered.

[0128] Unless otherwise specified, ordinal terms such as "1st" and "2nd" do not necessarily signify order in time, sequence, or numerical terms, but are used to distinguish different instances of the terms or phrases that follow each ordinal number. Reference numbers used in specifications and drawings may be cross-referenced between drawings to indicate identical or similar features. Features that are exactly the same in multiple drawings may be labeled with the same reference number in multiple drawings. Features that are similar but not strictly identical across multiple drawings may be labeled with reference numbers that have different preceding numbers but one or more of the same ending numbers (e.g., 206, 306, 406, etc. may refer to similar features in drawings). "X" may be used to universally indicate multiple variations of a single feature. For example, "X06" can universally refer to all reference numbers ending in "06" (e.g., 206, 306, 406, etc.).

[0129] All elements and structural and functional equivalents of various aspects described throughout this disclosure, whether known or subsequently known to those skilled in the art, are expressly incorporated herein by reference and are included in the claims. Words such as “module,” “mechanism,” “element,” and “device” may not be substitutes for the word “means.” Accordingly, claim elements should not be construed as means plus functions unless the elements are expressly enumerated using the phrase “means to do.” Where used herein, the phrase “based on” shall not be construed as a reference to a closed set of information, one or more conditions, one or more factors, etc. In other words, the phrase “based on A” shall be construed as “at least based on A” unless specifically stated otherwise, where “A” may be information, conditions, factors, etc.

[0130] The following examples are illustrative and may be combined with other examples or teachings described herein without limitation. Embodiment 1 is a method for wireless communication in a UE, comprising multiplexing UCIs for a plurality of codewords on a PUSCH resource to generate a multiplexed UCI, wherein the plurality of codewords are associated with one or more beams, e.g., one or more TCI states, and transmitting the multiplexed UCIs on the PUSCH resource to a network entity.

[0131] Embodiment 2 may be combined with Embodiment 1 and further includes receiving a configuration for UCI on a PUCCH resource from the network entity and deciding to transmit the UCI on the PUCCH resource instead of the PUCCH resource based on multiplexing the UCI for the plurality of codewords on the PUCCH resource.

[0132] Embodiment 3 may be combined with Embodiment 2, wherein receiving the configuration for the UCI is receiving instructions for a multiplexing scheme, and multiplexing the UCI for the plurality of codewords associated with the one or more beams on the PUSCH resource is further comprising receiving instructions for the multiplexing scheme.

[0133] Example 4 may be combined with Example 3 and includes the fact that the instruction for the multiplexing scheme includes a first parameter for performing the multiplexing for the multicodeword PUSCH.

[0134] Example 5 may be combined with Example 4 and includes the fact that the instruction for the multiplexing scheme includes a second parameter for performing the multiplexing for the multibeam PUSCH.

[0135] Embodiment 6 may be combined with any of Embodiments 1 to 5 and further includes sending the network entity a UE capability report indicating the UE's ability to multiplex the multiple codewords associated with the one or more beams on the PUSCH resource.

[0136] Embodiment 7 may be combined with Embodiment 6 and includes the capability of the UE corresponding to at least one of the following: a first UCI multiplexing capability for the plurality of codewords, a second UCI multiplexing capability on one or more beams, or a data transmission capability of the first codeword among the plurality of codewords on the same resource element as that assigned to the UCI of the second codeword among the plurality of codewords.

[0137] Embodiment 8 may be combined with any of Embodiments 1 to 7, and the multiplexed UCI on the PUSCH resource corresponds to an iteration of the UCI on the same resource element for the multiple codewords or a partition of the UCI.

[0138] Example 9 may be combined with any of Examples 1 to 7, and the multiplexed UCI on the PUSCH resource corresponds to iterations of the UCI on different resource elements for the plurality of codewords or partitions of the UCI.

[0139] Example 10 may be combined with any of Examples 1 to 7, and the plurality of codewords includes a first codeword having the UCI and a second codeword not having the UCI.

[0140] Example 11 may be combined with any of Examples 1 to 7, and the plurality of codewords include a first codeword having CSI and HARQ-ACK, and a second codeword having CSI but not HARQ-ACK.

[0141] Embodiment 12 may be combined with any of Embodiments 1 to 11 and further includes receiving a first trigger instruction from the network entity for transmitting the multiplexed UCI on the PUSCH resource.

[0142] Embodiment 13, which may be combined with Embodiment 12, further includes receiving a second trigger instruction from the network entity for transmitting the multiplexed UCI on the PUSCH resource, wherein the first trigger instruction is for a first PUSCH transmission on a first beam and the second trigger instruction is for a second PUSCH transmission on a second beam.

[0143] Example 14 may be combined with any of Examples 12 to 13, wherein at least one of the first trigger instruction or the second trigger instruction indicates a multiplexing scheme for the multiplexed UCI, the multiplexing scheme includes corresponding to at least one of multicodeword PUSCH transmission or multibeam PUSCH transmission.

[0144] Example 15 may be combined with any of Examples 1 to 14 and further includes receiving a UCI trigger from the network entity for transmitting the multiplexed UCI to the network entity on the PUSCH resource.

[0145] Example 16 may be combined with any of Examples 1 to 15, and the transmission of the multiplexed UCI for the plurality of codewords is on a single beam.

[0146] Example 17 may be combined with any of Examples 1 to 15, and the transmission of the multiplexed UCI for the multiple codewords includes being on multiple beams.

[0147] Embodiment 18 is a method for wireless communication in a network entity, comprising: transmitting a configuration for a UCI on a PUCCH resource to a UE; and receiving the UCI from the UE, which is multiplexed on the PUCCH resource, wherein the UCI is for a plurality of codewords associated with one or more beams.

[0148] Example 19 may be combined with Example 18 and further includes transmitting the configuration for the UCI as instructions for a multiplexing scheme, and multiplexing the UCI for the plurality of codewords associated with the one or more beams on the PUSCH resource as instructions for a multiplexing scheme.

[0149] Example 20 may be combined with Example 19 and includes the fact that the instruction for the multiplexing scheme includes a first parameter for performing the multiplexing for the multicodeword PUSCH.

[0150] Example 21 may be combined with Example 20 and includes the fact that the instruction for the multiplexing scheme includes a second parameter for performing the multiplexing for the multibeam PUSCH.

[0151] Example 22 may be combined with any of Examples 18 to 21 and further includes receiving a UE capability report from the UE indicating the UE's ability to multiplex the plurality of codewords associated with the one or more beams on the PUSCH resource.

[0152] Embodiment 23 may be combined with Embodiment 22 and includes the capability of the UE corresponding to at least one of the following: a first UCI multiplexing capability for the plurality of codewords, a second UCI multiplexing capability on one or more beams, or a data transmission capability of the first codeword among the plurality of codewords on the same resource element as that assigned to the UCI of the second codeword among the plurality of codewords.

[0153] Example 24 may be combined with any of Examples 18 to 23, and the multiplexed UCI on the PUSCH resource corresponds to an iteration of the UCI on the same resource element for the multiple codewords or a partition of the UCI.

[0154] Example 25 may be combined with any of Examples 18 to 23, and the multiplexed UCI on the PUSCH resource corresponds to iterations of the UCI on different resource elements for the plurality of codewords or partitions of the UCI.

[0155] Example 26 may be combined with any of Examples 18 to 23, and the plurality of codewords includes a first codeword having the UCI and a second codeword not having the UCI.

[0156] Example 27 may be combined with any of Examples 18 to 23, and the plurality of codewords include a first codeword having CSI and HARQ-ACK, and a second codeword having CSI but not HARQ-ACK.

[0157] Example 28 may be combined with any of Examples 18 to 27 and further includes sending a first trigger instruction to the UE for receiving the multiplexed UCI on the PUSCH resource.

[0158] Embodiment 29, which may be combined with Embodiment 28, further includes transmitting to the UE a second trigger instruction for receiving the multiplexed UCI on the PUSCH resource, wherein the first trigger instruction is for a first PUSCH transmission on a first beam and the second trigger instruction is for a second PUSCH transmission on a second beam.

[0159] Example 30 may be combined with any of Examples 28 to 29, wherein at least one of the first trigger instruction or the second trigger instruction indicates a multiplexing scheme for the multiplexed UCI, the multiplexing scheme includes corresponding to at least one of multicodeword push transmission or multibeam push transmission.

[0160] Example 31 may be combined with any of Examples 18 to 30 and further includes sending a UCI trigger to the UE for receiving the multiplexed UCI from the UE on the PUSCH resource.

[0161] Example 32 may be combined with any of Examples 18 to 31, and the receiving of the multiplexed UCI for the plurality of codewords is on a single beam.

[0162] Example 33 may be combined with any of Examples 18 to 31, and the receiving of the multiplexed UCI for the plurality of codewords includes being on a plurality of beams.

[0163] Example 34 is a wireless communication device for carrying out the method described in any of Examples 1 to 33. Example 35 is a wireless communication device that includes means for carrying out the method described in any of Examples 1 to 33.

[0164] Example 36 is a non-temporary computer-readable medium for storing computer executable code, wherein the code, when executed by a processor, causes the processor to perform the method described in any of Examples 1 to 33.

Claims

1. A method for wireless communication in a user device (UE) (102), Multiplexing uplink control information (UCI) is performed by multiplexing UCI (508) for multiple codewords on a physical uplink shared channel (PUSCH) resource (202) in order to generate multiplexed uplink control information (UCI), wherein the multiple codewords are associated with one or more beams. To transmit the multiplexed UCI (508) on the PUSCH resource (202) to the network entity (104) (316, 716), Methods that include...

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

3. Receiving the above configuration for the UCI (308, 708) The method of claim 2, further comprising receiving (308, 708) instructions for a multiplexing scheme, and multiplexing the UCI (508) for the plurality of codewords associated with the one or more beams on the PUSCH resource (202) based on the instructions for the multiplexing scheme.

4. The method according to claim 3, wherein the instruction for the multiplexing scheme includes a first parameter for performing the multiplexing for the multicodeword PUSCH.

5. The method according to claim 4, wherein the instruction for the multiplexing scheme includes a second parameter for performing the multiplexing for a multibeam PUSCH.

6. The method according to any one of claims 1 to 5, further comprising transmitting to the network entity (104) a UE capability report (306, 706) indicating the UE's ability to multiplex the plurality of codewords associated with one or more beams on the PUSCH resource (202).

7. The capabilities of the aforementioned UE(102) are The first UCI multiplexing capability for the aforementioned plurality of codewords, The second UCI multiplexing capability on one or more of the aforementioned beams, or The data transmission capability of the first codeword among the plurality of codewords on the same resource element as the second codeword among the plurality of codewords assigned to the UCI(508), The method according to claim 6, which corresponds to at least one of the following.

8. The method according to any one of claims 1 to 7, wherein the multiplexed UCI (508) on the PUSCH resource (202) corresponds to iterations of the UCI (508) on the same resource element for the plurality of codewords or partitions of the UCI (508).

9. The method according to any one of claims 1 to 7, wherein the multiplexed UCI (508) on the PUSCH resource (202) corresponds to iterations of the UCI (508) on different resource elements for the plurality of codewords or partitions of the UCI (508).

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

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

12. The method according to any one of claims 1 to 11, further comprising receiving a first trigger instruction (310, 710a) from the network entity (104) for transmitting the multiplexed UCI (508) on the PUSCH resource (202).

13. The method according to claim 12, further comprising receiving (710b) a second trigger instruction from the network entity (104) for transmitting (716) the multiplexed UCI (508) on the PUSCH resource (202), wherein the first trigger instruction is for a first PUSCH transmission on a first beam, and the second trigger instruction is for a second PUSCH transmission on a second beam.

14. The method according to any one of claims 12 to 13, wherein at least one of the first trigger instruction or the second trigger instruction indicates a multiplexing scheme for the multiplexed UCI (508), the multiplexing scheme corresponds to at least one of a multicodeword PUSCH transmission (316) or a multibeam PUSCH transmission (716).

15. The method according to any one of claims 1 to 14, further comprising receiving a UCI trigger (312, 712) from the network entity (104) for transmitting the multiplexed UCI (508) on the PUSCH resource (202) to the network entity (104) (316, 716).

16. The method according to any one of claims 1 to 15, wherein the transmission (316, 716) of the multiple codewords is on a single beam.

17. The method according to any one of claims 1 to 15, wherein the transmission (316, 716) of the multiplexed UCI (508) for the multiple codewords is on multiple beams.

18. A method for wireless communication in a network entity (104), To transmit a configuration for uplink control information (UCI) on a physical uplink control channel (PUCCH) resource (204) to a user device (UE) (102) (308, 708), Receiving the UCI from the UE (102) which is multiplexed on a physical uplink shared channel (PUSCH) resource (202) (316, 716), wherein the UCI is for a plurality of codewords associated with one or more beams (316, 716), Methods that include...

19. A device for wireless communication comprising a memory, a transceiver, and a processor coupled to the memory and the transceiver, wherein the device is configured to carry out the method according to any one of claims 1 to 18.

Images