UCI multiplexing in PUSCH with multicodeword retransmission

Abstract

This disclosure provides a system, device, apparatus, and method for UCI multiplexing in PUSCH retransmission, including a computer program encoded in a storage medium. UE(102) receives (312) control signaling from a network entity (104) to schedule a PUSCH retransmission of a multicodeword PUSCH. UE(102) transmits (316) a PUSCH retransmission to the network entity (104) based on a UCI multiplexing procedure for a multicodeword PUSCH. The UCI multiplexing procedure prevents the UCI from being multiplexed on an invalidated codeword (202d) or on codewords (502a, 803a) that have a reserved MCS based on the value of the reserved MCS.

Description

Technical Field

[0001] The present disclosure generally relates to wireless communication, and more specifically, to uplink control information (UCI) multiplexing in multi-codeword physical uplink shared channel (PUSCH) retransmission.

Background Art

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

[0003] A wireless communication system generally provides various telecommunication services (e.g., telephone, video, data, messaging, broadcast, etc.) based on multiple access technologies such as orthogonal frequency division multiple access (OFDMA) technology that supports communication with multiple UEs. With the improvement of mobile broadband, the progress of such wireless communication technology continues. For example, a UE can multiplex uplink control information (UCI) on an assigned physical uplink shared channel (PUSCH) resource that temporally overlaps with a physical uplink control channel (PUCCH) resource configured for UCI transmission. However, the codewords of a multi-codeword PUSCH may have different characteristics during PUSCH retransmission than during the first PUSCH transmission.

Summary of the Invention

[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 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 UCI over a physical uplink shared channel (PUSCH) resource if the PUSCH resource temporally overlaps with a physical uplink control channel (PUCCH) resource associated with the UCI. In some embodiments, the network entity schedules data during the initial PUSCH transmission of a multicodeword PUSCH. The network entity may also schedule data during PUSCH retransmissions of a multicodeword PUSCH. In the case of a PUSCH retransmission, the network entity may invalidate the codewords of the multicodeword PUSCH or indicate that the codewords of the multicodeword PUSCH include a reserved modulation coding scheme (MCS).

[0006] A UE can multiplex the UCI for both the initial push transmission and the push retransmission of a multicodeword push. For example, a UE may multiplex the UCI for the initial push transmission on the first scheduled codeword of a multicodeword push, or the codeword with the highest MCS. However, in the case of a push retransmission, the first scheduled codeword, or the codeword with the highest MCS, may be invalidated. Therefore, multiplexing the UCI on an invalidated codeword may increase power consumption and / or demodulated reference signal (DMRS) overhead at the UE, as the UE must transmit DMRS from the port mapped to the invalidated codeword. Furthermore, while higher MCS codewords often result in better channel quality, if reserved MCSs typically have higher index numbers than unreserved MCSs, the UE may use a codeword containing a reserved MCS by default. However, reserved MCSs do not always provide better performance than unreserved MCSs.

[0007] Aspects of this disclosure address the aforementioned and other drawbacks by implementing a UCI multiplexing procedure when a codeword in a multicodeword PUSCH is disabled and / or when the MCS of a codeword in a multicodeword PUSCH includes a reserved MCS. Specifically, the UCI multiplexing procedure prevents the UCI from being multiplexed on a disabled codeword and / or on a codeword with a reserved MCS. Avoiding UCI multiplexing on disabled codewords can improve performance by reducing DMRS overhead. Furthermore, by preventing codewords with reserved MCSs from being the default target for UCI multiplexing in preference to codewords with unreserved MCSs, it may be possible to identify codewords for UCI multiplexing that can provide better performance for the UE.

[0008] In some embodiments, the UE receives control signaling from a network entity to schedule a PUSCH retransmission of a multicodeword PUSCH. The UE sends a PUSCH retransmission to the network entity based on a UCI multiplexing procedure for the multicodeword PUSCH. The UCI multiplexing procedure prevents the UCI from being multiplexed over an invalid codeword or a codeword with a reserved MCS, based on the value of the reserved MCS.

[0009] In some embodiments, a network entity sends a control signaling to the UE to schedule a PUSCH retransmission of a multicodeword PUSCH. The network entity receives the PUSCH retransmission from the UE based on a UCI multiplexing procedure for the multicodeword PUSCH. As described above, the UCI multiplexing procedure prevents the UCI from being multiplexed over an invalid codeword or a codeword with a reserved MCS, based on the value of the reserved MCS. [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 and B show diagrams related to the multiplexing of uplink control information (UCI) on a physical uplink shared channel (PUSCH). [Figure 3] This shows a signaling diagram for UCI multiplexing on PUSCH with multicodeword retransmission. [Figure 4] The diagram shows UCI multiplexing on an activated / scheduled codeword. [Figure 5] This diagram shows UCI multiplexing when a reserved MCS is indicated for a codeword. [Figure 6] This diagram shows UCI multiplexing when a reserved MCS is indicated for a codeword. [Figure 7]This diagram shows UCI multiplexing based on spectral efficiency when a reserved MCS is indicated for a codeword. [Figure 8] This diagram shows UCI multiplexing on each codeword in multicodeword PUSCH retransmission. [Figure 9] This is a flowchart of wireless communication methods in UE. [Figure 10] This is a flowchart of wireless communication methods in a network entity. [Figure 11] This figure shows a hardware implementation of an exemplary UE device. [Figure 12] This figure shows the hardware implementation of one or more exemplary network entities. [Modes for carrying out the invention]

[0011] Figure 1 shows Figure 100 of a wireless communication system associated with multiple cells 190. The wireless communication system includes user equipment (UE) 102 and base station / network entities 104. Some base stations may include a centralized base station architecture, while others may include a distributed base station architecture. A centralized base station architecture utilizes a radio protocol stack that is physically or logically integrated within a single radio access network (RAN) node. A distributed base station architecture utilizes a protocol stack that is physically or logically distributed among two or more units (e.g., radio units (RU) 106, distributed units (DU) 108, and central units (CU) 110). For example, a CU 110 may be implemented within a RAN node, and one or more DUs 108 may be located at the same site as the CU 110, or may be geographically or virtually distributed across one or more other RAN nodes. A DU 108 may be implemented to communicate with one or more RUs 106. RU106, DU108, and CU110 can be implemented as virtual units such as a virtual radio unit (VRU), virtual distributed unit (VDU), or virtual central unit (VCU). A base station / network entity 104 (e.g., a centralized base station, or a distributed unit of a base station such as RU106 or DU108) may be called a transmit / receive point (TRP).

[0012] The operation and / or network design of base station 104 may 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 a distributed 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 the UE102 via intracell and / or intercell access links between the UE102 and the 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. For example, a wired interface may be configured to transmit or receive information / signals over a wired transmission medium such as a fronthaul link 160 between RU106d and the baseband unit (BBU) 112 of base station 104d associated with cell 190d. The BBU 112 includes DU108 and CU110, which may also have a wired interface (e.g., a midhaul link) configured between DU108 and CU110 to transmit or receive information / signals between DU108d and CU110d. In further examples, 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 via 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. DU108 can control both real-time and non-real-time features of RU106's control plane communications and user plane communications.

[0016] Any combination of RU106, DU108, and CU110, or any individual reference to them, 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 can relay communications between UE102 and the core network (not shown). Base station 104 may be associated with a macrocell for high-power cellular base stations and / or a small cell 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. A network including at least one macrocell and at least one small cell may be called a “heterogeneous network”.

[0017] Transmission from UE102 to base station 104 / RU106 is called uplink (UL) transmission, while transmission from base station 104 / RU106 to UE102 is called downlink (DL) transmission. Uplink transmission is also called reverse link transmission, and downlink transmission is also called forward link transmission. For example, RU106d uses the antenna of base station 104d in cell 190d to transmit downlink / forward link communication to UE102d or receive uplink / reverse link communication from UE102d 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 can be based on multiple-input / multiple-output (MIMO) antenna technology including spatial multiplexing, beamforming, and / or transmit diversity. The communication link can be associated with one or more carriers. UE102 and base station 104 / RU106 may utilize a spectral bandwidth of Y MHz (e.g., 5, 10, 15, 20, 100, 400, 800, 1600, 2000 MHz, etc.) for each carrier assigned with carrier aggregation up to a total of Yx MHz, and the x component carriers (CCs) are used for each communication in the uplink and downlink directions. The carriers may be adjacent to each other along the frequency spectrum or may not be adjacent. In the example, the uplink carriers and downlink carriers may be asymmetrically assigned such that more or fewer carriers are assigned to either the uplink or the downlink. The component carriers may include a primary component carrier and one or more secondary component carriers. The primary component carrier may be associated with a primary cell (PCell), and the secondary component carriers may be associated with secondary cells (SCells).

[0019] Some UE102 models, such as the UE102a and UE102s, can 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. Such sidelink / D2D communication can be performed via various wireless communication systems, such as Wireless Fidelity (Wi-Fi) systems, Bluetooth® systems, Long-Term Evolution (LTE) systems, and New Radio (NR) systems.

[0020] The electromagnetic spectrum is often segmented into different classes, bands, channels, etc. based on the different frequencies / wavelengths associated with the electromagnetic spectrum. The 5th 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 range of FR1 is 410 MHz to 7.125 GHz, and the range of FR2 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). A 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 different from the "extremely high frequency" (EHF) band, which is also called the "millimeter wave" band in the range of 30 GHz to 300 GHz, but is a subset close to it. The frequencies between FR1 and FR2 are often referred to as "mid-band" frequencies. The operating band of the mid-band frequencies may be called frequency range 3 (FR3) with a frequency range of 7.125 GHz to 24.25 GHz. The frequency bands within FR3 may include the characteristics of FR1 and / or FR2. Therefore, the functions of FR1 and / or FR2 can be extended to mid-band frequencies. To extend 5G NR communication beyond 52.6 GHz associated with the upper limit of FR2, higher operating frequency bands have been identified. 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 in this specification, the term "sub-6 GHz" may refer to frequencies less than 6 GHz within FR1 or may include mid-band frequencies. Furthermore, unless otherwise specified in this specification, the term "millimeter wave" or mmW refers to frequencies that may include mid-band frequencies, may be within FR2-1, FR4, FR2-2, and / or FR5, or may be 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 in one or more receive directions of UE102b based on a second set of communication beams 134b from RU106b. In a further example, UE102b may also transmit an uplink beamforming signal (e.g., a sounding reference signal (SRS)) 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 be the same or different. 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 evolved node B (ng-eNB), next-generation NB (gNB), evolved 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 an entity of base station 104 can be implemented as an IAB node, relay node, sidelink node, aggregated (monolithic) base station, or a distributed base station including one or more RU106, DU108, and / or CU110. An aggregated or separated set of base stations may be referred to as a next-generation radio access network (NG-RAN). In some examples, UE102a operates in dual connectivity (DC) with base station 104e and base station / 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, any of the UE102 may include an uplink control information (UCI) multiplexing component 140, which receives control signaling from a network entity to schedule a PUSCH retransmission of a multicodeword physical uplink shared channel (PUSCH) and is configured to transmit a PUSCH retransmission to the network entity based on a UCI multiplexing procedure for the multicodeword PUSCH, the UCI multiplexing procedure preventing the UCI from being multiplexed over an invalid codeword or a codeword having a reserved MCS, based on a value of a reserved modulation coding scheme (MCS).

[0026] In certain embodiments, any of the base stations 104, or a network entity of base stations 104, may include a PUSCH scheduling component 150 configured to send control signaling to the UE to schedule PUSCH retransmissions of multicodeword PUSCH, and to receive PUSCH retransmissions from the UE based on a UCI multiplexing procedure for multicodeword PUSCH, the UCI multiplexing procedure preventing the UCI from being multiplexed over an invalid codeword or a codeword having a reserved MCS, based on a reserved MCS value.

[0027] Accordingly, Figure 1 illustrates a wireless communication system that may be implemented in relation to one or more other embodiments described herein. 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 and 2B show Figures 200 and 250 related to UCI multiplexing on PUSCH. Based on UCI multiplexing, a network entity can configure the UE to transmit UCI on the physical uplink control channel (PUCCH) 204 as shown in Figure 200, or on PUSCH 202b as shown in Figure 250. The UCI may include a scheduling request, a hybrid autoretransmission request acknowledgment (HARQ-ACK), and channel status information (CSI). Thus, the UCI may have seven permutations corresponding to: dedicated to hybrid autoretransmission request (HARQ), dedicated to scheduling request, dedicated to CSI, HARQ and scheduling request, HARQ and CSI, scheduling request and CSI, and HARQ + scheduling request + CSI. However, the UE does not transmit scheduling requests on PUSCH 202. A CSI may also include CSI Part 1 and CSI Part 2, where CSI Part 2 supports variable length, such as CSI Part 2-specific symbols, and can be punctured into two sections by symbols having demodulated reference signal (DMRS) resource elements and data resource elements. If a network entity configures the UE to transmit UCI on PUCCH204 and data on PUSCH202a with overlapping symbols as shown in Figure 200, the UE may transmit UCI on PUSCH202b as shown in Figure 250, based on UCI multiplexing. Furthermore, a network entity may also schedule the UE to report aperiodic CSI on PUSCH202.

[0029] A network entity may schedule data transmissions on PUSCH202 using one or more codewords. For example, a network entity may schedule an initial transmission of one or more codewords, followed by one or more retransmissions of one or more codewords. In the case of retransmissions on PUSCH202 involving multiple codewords, the network entity may invalidate one of the codewords via Downlink Control Information (DCI). In other embodiments of retransmissions on PUSCH202, the network entity may indicate the MCS of the codewords via DCI. The reserved MCS may indicate an MCS greater than V, where V may be equal to 27 or 28 in some embodiments. The reserved MCS indicates the modulation order of the PUSCH transmission. Thus, the UE can transmit a transport block (TB) for the initial PUSCH transmission based on the modulation order indicated by the reserved MCS.

[0030] In the case of an initial push transmission based on multiple codewords, the UE can multiplex the UCI with the first of the multiple codewords, or with a codeword having a higher MCS. A codeword with a higher MCS may have better channel quality than a codeword with a lower MCS. Therefore, transmitting the UCI with a codeword with a higher MCS may correspond to transmitting the UCI at a layer with higher channel quality. However, in the case of a push retransmission, the first of the multiple codewords or with a codeword having a higher MCS may be invalidated. If the UCI is multiplexed with an invalidated codeword, the UE may still need to transmit DMRS from ports mapped to the invalidated codeword, which can increase power consumption and / or DMRS overhead at the UE.

[0031] If one of the codewords is invalidated during retransmission, the UE may need to implement techniques for transmitting the UCI over a multicodeword PUSCH. For example, if the UE decides to multiplex the UCI during PUSCH retransmission, the UE may perform a procedure to multiplex the UCI with a codeword that has a higher MCS index, since the reserved MCS index is higher than the initial MCS. However, a codeword with a reserved MCS does not always provide the best performance for the UE. Therefore, if at least one codeword's MCS is a reserved MCS, the UE may also need to implement techniques for transmitting the UCI over a multicodeword PUSCH.

[0032] Therefore, if one of the multiple codewords is disabled and / or if the MCS of one of the multiple codewords is a reserved MCS, the UE may perform UCI multiplexing on a multicodeword PUSCH using at least one of the multiple codewords configured for PUSCH retransmission. Such a technique can avoid multiplexing UCI with a disabled codeword, thereby improving PUSCH202 performance by reducing DMRS overhead and / or, if the MCS of at least one codeword is a reserved MCS, it can help identify a codeword with better channel quality to transmit UCI, thereby improving UCI performance.

[0033] Figure 3 shows the signaling diagram 300 for UCI multiplexing over PUSCH with multicodeword retransmission. UE 102 may transmit (306) the UE's capability for UCI multiplexing over multicodeword PUSCH with retransmission to network entity 104 (e.g., in a UE capability report). 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 other base stations / network entities (e.g., gNB or eNB).

[0034] Network entity 104 may, (for example, based on the capabilities of the UE), provide UE 102 with a configuration for UCI multiplexing on a multicodeword PUSCH, including a configuration for UCI multiplexing in PUSCH retransmission (308). Network entity 104 may transmit a configuration for UCI multiplexing via control signaling (308). Network entity 104 may use RRC signaling to provide 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). Network entity 104 may also transmit a configuration for UCI multiplexing via a media access control-control element (MAC-CE) (308). The configuration for UCI multiplexing in PUSCH retransmission can show the multiplexing procedure when one of the multiple codewords is invalid, and / or when the MCS indicated for one of the multiple codewords is a reserved MCS.

[0035] UE102 sends an initial PUSCH transmission from multiple codewords to network entity 104 (310). The initial PUSCH transmission may be for a first HARQ process. Network entity 104 may send a DCI scheduling / trigger instruction to UE102 (312) for a PUSCH retransmission of at least one of the multiple codewords for the first HARQ process. The DCI scheduling / trigger instruction may be for a PUSCH retransmission with one of the multiple codewords disabled, or for a PUSCH retransmission with one of the multiple codewords having a reserved MCS. In some embodiments, the UCI may be on a PUCCH that overlaps with the PUSCH in the time domain.

[0036] UE102 determines (314) the UCI multiplexing procedure for retransmitting a multicodeword PUSCH. The determination (314) may be performed based on configuration and / or DCI scheduling / trigger instructions. The UCI multiplexing procedure determined (314) by UE102 may correspond to a first UCI multiplexing procedure that performs PUSCH retransmission when one of the multiple codewords is invalidated, or a second UCI multiplexing procedure that performs PUSCH retransmission when one of the multiple codewords has a reserved MCS.

[0037] UE102 multiplexes the PUSCH and UCI based on the determined UCI multiplexing procedure and transmits them to network entity 104 (316). Network entity 104 may also determine the UCI multiplexing procedure that UE102 used to multiplex the PUSCH and UCI and transmit them to network entity 104 (316), based on similar techniques as UE102. Such techniques may be indicated to UE102 (e.g., via the configuration in (308)) or based on a predefined protocol. Network entity 104 decodes (318) the PUSCH and UCI received (316) from UE102 based on the determined UCI multiplexing procedure.

[0038] Figure 4 shows UCI multiplexing in an enabled / scheduled codeword (for example, when other codewords are disabled in a multicodeword PUSCH retransmission). That is, the first PUSCH202c may have an enabled / scheduled codeword with a multiplexed UCI at retransmission, and the second PUSCH202d may have a disabled codeword at retransmission. Therefore, DCI scheduling from the network entity is exclusive to PUSCH202c with an enabled codeword and may not be used for PUSCH202d with a disabled codeword.

[0039] In some embodiments, the UE transmits the UCI with a first activated / scheduled codeword. In some other embodiments, the UE transmits the UCI with the activated / scheduled codeword having the highest MCS. If multiple codewords are configured to have the same MCS, the codeword with the lowest codeword index may be used for UCI multiplexing. That is, the first activated / scheduled codeword having the same / highest MCS is selected for UCI multiplexing.

[0040] In some embodiments of UCI multiplexing in PUSCH retransmission, if UCI is multiplexed on a PUSCH202d with an invalidated codeword, the UE may drop the UCI or skip UCI transmission. That is, the UE refrains from transmitting UCI on a PUSCH202d with an invalidated codeword. Similarly, a network entity may refrain from receiving (e.g., scanning) UCI ​​on a PUSCH202d with an invalidated codeword. If UCI is multiplexed on a PUSCH with an invalidated codeword, the UE may also drop data or skip data transmission. For example, the UE may drop data such as all scheduled TB associated with a PUSCH202d.

[0041] The UE transmits a UCI on the PUSCH202c based on scheduling information for the multiplexed codewords (e.g., MCS and precoder information). The UE may also transmit a UCI on the PUSCH202c based on scheduling information for an activated / scheduled codeword. The activated / scheduled codeword may be the first of several codewords or the codeword with the highest MCS among several codewords. In some embodiments, the UE transmits a UCI on a PUSCH resource configured or indicated by a network entity via RRC signaling, MAC-CE, or DCI, and then drops the PUSCH transmission.

[0042] In some embodiments, a network entity may indicate a configurable UCI multiplexing procedure in case one of the codewords is disabled. The network entity configures whether the UE transmits UCIs with the enabled / scheduled codeword. If the network entity configures the UE to transmit UCIs with the enabled / scheduled codeword, the UE performs UCI multiplexing on the PUSCH202c. Otherwise, the UE may transmit UCIs on the PUSCH202d with the disabled codeword, drop the UCIs, transmit UCIs on the PUCCH, or transmit UCIs on the PUSCH202d and drop the data.

[0043] A network entity may configure multiple options for UCI transmission, or multiple options for UCI transmission may be predefined for the UE. The UE may choose one of these options to transmit the UCI. The network entity may perform blind detection to determine which option the UE chose to decode the UCI transmission received from the UE.

[0044] The UE may send a UE capability report to the network entity indicating whether the UE supports UCI multiplexing on a disabled codeword. If the UE does not support UCI multiplexing on a disabled codeword, the UE may drop the UCI, transmit the UCI over PUCCH, or transmit the UCI over PUSCH202d and drop the data when multiplexing the UCI over the disabled codeword based on the UCI multiplexing scheme. Alternatively, the network entity may refrain from disabling a codeword if the UCI is multiplexed for multicodeword PUSCH retransmission.

[0045] Figures 5-8 show UCI multiplexing in Figures 500-850 when reserved MCSs are indicated for codewords. For example, in Figure 500 of Figure 5, the network entity indicates the MCS for the initial transmission of the second codeword 506a among several codewords 506a-506b (e.g., during retransmission), and also indicates the reserved MCS for the second codeword 506a. Specifically, the first codeword 506b has MCS=18, and the second codeword 506a has MCS=6 for the initial transmission. The second codeword 506a further has reserved MCS=29. Network entity 104 may also indicate unreserved MCSs for retransmission.

[0046] If the DCI scheduling indicates that a codeword's MCS includes a reserved MCS, the network entity and / or UE may determine codeword 502b for UCI multiplexing based on the MCS indicated for codeword 506b and other MCS indicated in the scheduling DCI for other codewords (e.g., 506a). In Figure 550, the UE selects the codeword with the highest MCS for UCI multiplexing. For example, the first codeword 506b has a higher MCS than the second codeword 506a. Therefore, the UE selects the first codeword 506b / 502b for UCI multiplexing. If the MCS of codewords 506a and 506b are the same, the UE may select the first codeword 502b from among several codewords 502a and 502b for UCI multiplexing.

[0047] In Figure 600 of Figure 6, a network entity indicates a reserved MCS for one of several codewords 606a and 606b, and the network entity and / or UE determines the nominal MCS based on the reserved MCS indicated for codeword 606a. Specifically, the first codeword 606b has an MCS of 18, and the second codeword 606a has a nominal MCS of 8. The second codeword 606a also has a reserved MCS of 29.

[0048] If DCI scheduling indicates that a codeword's MCS includes a reserved MCS, the network entity and / or UE may determine codeword 502b for UCI multiplexing based on the MCS of codeword 606b and the nominal MCS of other codewords 606a. The network entity and / or UE uses the MCS table to determine the nominal MCS based on the spectral efficiency (SE) of the retransmitted codeword and the spectral efficiency of the unreserved MCS. The UE selects the codeword with the highest indicated / nominal MCS for UCI multiplexing. For example, if the first codeword 606b has a higher MCS than the second codeword 606a, the UE selects the first codeword 606b / 502b for UCI multiplexing. If the MCS of codewords 606a and 606b are the same, the UE may select the first codeword 502b from among several codewords 502a and 502b for UCI multiplexing.

[0049] The nominal MCS can be calculated based on the reserved MCS. In some embodiments, the nominal MCS is based on the average SE and MCS table calculated for each layer of the corresponding codeword. A network entity may select the nominal MCS based on the largest MCS in the MCS table corresponding to SEs less than or equal to the calculated SE. For example, if the calculated SE is 1.5 and the SE with MCS=6 in the MCS table is 1.5, then MCS=6 is selected as the nominal MCS. Alternatively, a network entity may select the nominal MCS based on the smallest MCS in the MCS table corresponding to SEs higher than the calculated SE. For example, if the calculated SE is 1.4 and the smallest MCS in the MCS table with an SE higher than 1.4 is MCS=6, then MCS=6 is selected as the nominal MCS.

[0050] The SE for each layer can be calculated based on the following formula:

[0051]

number

[0052] In the formula, B corresponds to the TB size of the codeword, and N L This corresponds to the number of layers in the codeword, N RE N0 corresponds to the number of resource elements scheduled for PUSCH, and N0 corresponds to the overhead of DMRS and other signals.

[0053] In Figure 700 of Figure 7, the network entity not only shows the MCS of multiple codewords 706a and 706b, but also the SE of each of the multiple codewords 706a and 706b, and the reserved MCS of one of the multiple codewords 706a, codeword 706a. Specifically, the first codeword 706b has SE=2.73, and the second codeword 706a has SE=1.6. The second codeword 706a also has a reserved MCS=29, and the first codeword 706b has an MCS=18.

[0054] If DCI scheduling indicates that a codeword's MCS includes a reserved MCS, the network entity and / or UE may determine codeword 502b for UCI multiplexing based on the actual SE of codeword 706b (derived, for example, from the reserved MCS of the second codeword 706a and the indicated MCS of the first codeword 706b). In some embodiments, the UE selects the codeword with the highest SE for UCI multiplexing. For example, the first codeword 706b has a higher SE than the second codeword 706a. Therefore, the UE selects the first codeword 706b / 502b for UCI multiplexing. In some embodiments, the UE selects the codeword with the lowest SE for UCI multiplexing. For example, the second codeword 706a has a lower SE than the first codeword 706b, so the UE selects the second codeword 706a for UCI multiplexing. If the MCS for codewords 706a and 706b have the same SE, the UE may select the first codeword 502b from among multiple codewords 502a and 502b for UCI multiplexing.

[0055] The UE may determine the SE based on the MCS table for indicated MCSs other than reserved MCSs. For indicated MCSs other than reserved MCSs, the UE may also determine the SE based on the actual transmission of the codeword, which may be the same as the SE determination for reserved MCSs. The UE may determine UCI multiplexing based on the average SE per layer. The average SE per layer may be based on parameters such as the TB size of the codeword, the number of layers mapped to the codeword, the PUSCH resource element, and the overhead of other signals. In the example, the SE per layer may be calculated based on the following formula:

[0056]

number

[0057] The UE may also determine UCI multiplexing based on the sum of SEs across all layers mapped to the codeword, determined based on parameters (e.g., the TB size of the codeword, the number of layers mapped to the codeword, the resource elements of PUSCH, and the overhead of other signals). For example, the SE per layer may be based on the following formula:

[0058]

number

[0059] In some embodiments, if DCI scheduling indicates that a codeword's MCS includes a reserved MCS, the UE drops the UCI; that is, the UE refrains from sending the UCI to a network entity on the PUSCH. The network entity may similarly refrain from receiving (e.g., scanning) the UCI on the PUSCH. In other embodiments, if DCI scheduling indicates that only one codeword can apply / use a reserved MCS, the UE drops the UCI transmission / multiplexing. If DCI scheduling indicates that either or both codewords can apply / use a reserved MCS, the UE may select / use the first codeword for UCI transmission / multiplexing.

[0060] In a further embodiment, if DCI scheduling indicates that a codeword's MCS includes a reserved MCS, the UE drops the data. For example, the UE drops all scheduled TBs. The UE transmits UCIs on PUSCH based on the scheduling information (e.g., MCS and precoder) of the codeword multiplexed on PUSCH. The UE may transmit UCIs on PUSCH based on the scheduling information (e.g., MCS and precoder) of either a first enable / scheduled codeword or an enable / scheduled codeword having a higher or lower MCS depending on the implementation. In another embodiment, the UE transmits UCIs on a PUSCH resource configured or indicated by a network entity via RRC signaling, MAC-CE, or DCI, and the UE drops / skips the PUSCH transmission.

[0061] In Figure 800 of Figure 8, the network entity shows multiple codewords 806a and 806b with MCS=18, and the second codeword 806a with reserved MCS=29. If DCI scheduling indicates that a codeword's MCS includes a reserved MCS, the UE may transmit UCI over all scheduled codewords 502b / 803a, as shown in Figure 850. That is, Figure 850 includes both the first codeword 502b with UCI and the second codeword 803a with UCI.

[0062] In some embodiments, if DCI scheduling indicates that a codeword's MCS includes a reserved MCS, the UE transmits the UCI over all activated codewords 502b / 803a. The UE may also transmit the UCI as multiple iterative transmissions over multiple codewords. In other embodiments, the UE may apply a single channel coding scheme to the entire UCI by transmitting different coded bits of the UCI over different codewords. The UE may transmit different parts of the UCI (e.g., source bits) over different codewords or perform separate channel coding for the UCI for each codeword. Portions or parts of the UCI coded bits or source bits to be multiplexed over a codeword may be pre-indicated or pre-configured to the UE by the network entity.

[0063] If DCI scheduling indicates that a codeword's MCS includes a reserved MCS, the network entity may use an index to the codeword for UCI multiplexing. The network entity may indicate the codeword index by RRC signaling, MAC-CE, or DCI. In the example, a field in DCI used to schedule a PUSCH retransmission may indicate the codeword index for UCI multiplexing. In another example, if DCI scheduling indicates that a codeword's MCS includes a reserved MCS, the UE multiplexes the UCI over a predefined codeword (e.g., the first scheduled codeword among several codewords).

[0064] A network entity may configure a UCI multiplexing scheme via RRC signaling, MAC-CE, or DCI, etc., if the MCS indicated by the codeword is a reserved MCS. For periodic UCI or Type 1 configured grant push, a network entity may configure a UCI multiplexing scheme via RRC signaling. For semi-persistent UCI, a network entity may configure a UCI multiplexing scheme via MAC-CE. For aperiodic UCI, dynamic grant push, or Type 2 configured grant push, a network entity may configure a UCI multiplexing scheme in a DCI used to trigger aperiodic UCI transmission, or in a DCI used to trigger / activate a push.

[0065] The UCI multiplexing scheme / procedure may be determined based on the content or type of UCI. Network entities and UEs may determine different UCI multiplexing procedures for different types of UCI (e.g., HARQ-ACK, CSI, beam report, etc.). CSI may correspond to CSI reports that do not have Layer 1 reference signal received power (L1-RSRP) / Layer 1 signal-to-interference noise ratio (L1-SINR) information. Beam reports may correspond to CSI reports that have L1-RSRP / L1-SINR information.

[0066] The UE may report to the network entity its ability to support UCI multiplexing in PUSCH retransmissions from multiple codewords where at least one of the codewords has a reserved MCS. If the UE does not support that ability, the UE may drop either the UCI or the data. Similarly, the network entity may refrain from indicating the reserved MCS of a codeword when the UCI is multiplexed over a multicodeword PUSCH. If the UE does not support its ability to support UCI multiplexing in PUSCH retransmissions from multiple codewords where at least one of the codewords has a reserved MCS, the UE may report to the network entity the ability to support it. Figures 3-8 illustrate UCI multiplexing in multicodeword PUSCH retransmissions. Figures 9-10 illustrate how to implement one or more embodiments of Figures 3-8. Specifically, Figure 9 shows an embodiment by UE 102 of one or more embodiments of Figures 3-8. Figure 10 shows an embodiment by network entity 104 of one or more embodiments of Figures 3-8.

[0067] Figure 9 shows a flowchart 900 of a wireless communication method in the UE. Referring to Figures 1, 3, and 11, the method may include memory 1126', 1106', 1116 and may be performed by the UE 102, the UE device 1102, etc., corresponding to the entire UE 102 or the entire UE device 1102, or components of the UE 102 or UE device 1102 such as the wireless baseband processor 1126 and / or application processor 1106.

[0068] If the multicodeword PUSCH includes at least one of the invalidated codewords or codewords with reserved MCS, UE102 sends a UE capability report to the network entity (906) indicating the UE's capability regarding the UCI multiplexing procedure in PUSCH retransmission. For example, referring to Figure 3, UE102 sends (306) the UE's capability regarding UCI multiplexing on the multicodeword PUSCH with retransmission to the network entity 104.

[0069] UE102 receives (908) a configuration of the UCI multiplexing procedure in PUSCH retransmission from the network entity if the multicodeword PUSCH includes at least one of the codewords that are invalidated or have a reserved MCS. For example, referring to Figure 3, UE102 receives (308) a configuration of UCI multiplexing on the multicodeword PUSCH from the network entity 104 (based on, for example, an invalidated codeword or a reserved MCS).

[0070] UE102 receives control signaling from the network entity (912) to schedule the PUSCH retransmission of the multicodeword PUSCH. For example, referring to Figure 3, UE102 receives (312) DCI scheduling from the network entity 104 for the PUSCH retransmission of at least one of the multiple codewords for the first HARQ process (for example, based on an invalidated codeword or a reserved MCS).

[0071] UE102 determines the UCI multiplexing procedure (914). For example, referring to Figure 3, UE102 determines the UCI multiplexing procedure in the retransmission of the multicodeword PUSCH (314). UE102 may decide to multiplex (914a) the UCI in the PUSCH retransmission as shown in Figures 400-850 of Figures 4-8. Alternatively, UE102 may decide to drop (914b) the UCI or data from the PUSCH retransmission if the UCI is scheduled on a codeword where control signaling is disabled or based on a reserved MCS.

[0072] UE102 transmits a PUSCH retransmission to the network entity (916) based on the UCI multiplexing procedure for the multicodeword PUSCH, which prevents the UCI from being multiplexed over an invalid codeword or over a codeword with a reserved Modulation Scheme (MCS) based on the value of the reserved Modulation Scheme (MCS). For example, referring to Figure 3, UE102 transmits the PUSCH and UCI to the network entity 104 (316) based on the UCI multiplexing procedure. Figure 9 shows the method from the UE side of the wireless communication link, and Figure 10 shows the method from the network side of the wireless communication link.

[0073] Figure 10 is a flowchart 1000 of a wireless communication method in a network entity. Referring to Figures 1, 3, and 12, the method may be performed by one or more network entities 104, which may correspond to a base station or a base station unit such as RU106, DU108, CU110, RU processor 1206, DU processor 1226, or CU processor 1246. One or more network entities 104 may include memory 1206' / 1226' / 1246', which 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 1206, DU processor 1226, or CU processor 1246.

[0074] Network entity 104 receives a UE capability report from UE (1006) indicating the UE's capability regarding the UCI multiplexing procedure in PUSCH retransmission if the multicodeword PUSCH includes at least one of the invalidated codewords or codewords with reserved MCS. For example, referring to Figure 3, network entity 104 receives (306) the UE's capability regarding UCI multiplexing over the multicodeword PUSCH with retransmission from UE 102.

[0075] If the multicodeword PUSCH includes at least one of the invalidated codewords or codewords with reserved MCS, the network entity 104 transmits (1008) the configuration of the UCI multiplexing procedure in PUSCH retransmission to the UE. For example, referring to Figure 3, the network entity 104 transmits (308) the configuration of UCI multiplexing on the multicodeword PUSCH (based on, for example, an invalidated codeword or a reserved MCS) to the UE 102.

[0076] Network entity 104 sends control signaling to the UE (1012) to schedule the PUSCH retransmission of the multicodeword PUSCH. For example, referring to Figure 3, network entity 104 sends DCI scheduling to UE 102 (312) for the PUSCH retransmission of at least one of the multiple codewords for the first HARQ process (e.g., based on an invalidated codeword or a reserved MCS).

[0077] Network entity 104 receives a PUSCH retransmission from the UE (1016) based on the UCI multiplexing procedure for the multicodeword PUSCH, and the UCI multiplexing procedure prevents the UCI from being multiplexed over an invalid codeword or over a codeword with a reserved modulation coding scheme (MCS) based on the value of the reserved modulation coding scheme (MCS). For example, referring to Figure 3, network entity 104 receives PUSCH and UCI from UE 102 (316) based on the UCI multiplexing procedure. UE device 1102 may perform the method of flowchart 900 as shown in Figure 11. One or more network entities 104 may perform the method of flowchart 1000 as shown in Figure 12.

[0078] Figure 11 is Figure 1100, which shows an example of a hardware implementation for UE device 1102. UE device 1102 may be UE 102, a component of UE 102, or may implement UE functionality. UE device 1102 may include an application processor 1106 which may have on-chip memory 1106'. In this example, the application processor 1106 may be coupled to a secure digital (SD) card 1108 and / or a display 1110. The application processor 1106 may also be coupled to a sensor module 1112, a power supply 1114, an additional memory module 1116, a camera 1118, and / or other related components. For example, the sensor module 1112 may 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 detection and ranging (RADAR) device, a sound navigation and ranging (SONAR) device, a magnetometer, an audio device, and / or other technologies used for positioning.

[0079] The UE device 1102 may further include a wireless baseband processor 1126, which may be called a modem. The wireless baseband processor 1126 may have on-chip memory 1126'. Together with, and similar to, the application processor 1106, the wireless baseband processor 1126 may also be coupled to a sensor module 1112, a power supply 1114, an additional memory module 1116, a camera 1118, and / or other related components. The wireless baseband processor 1126 may further be coupled to one or more subscriber identification module (SIM) cards 1120, and / or one or more transceivers 1130 (e.g., wireless RF transceivers).

[0080] The UE device 1102 may include a Bluetooth module 1132, a WLAN module 1134, an SPS module 1136 (e.g., a GNSS module), and / or a cellular module 1138 within one or more transceivers 1130. Each of the Bluetooth module 1132, WLAN module 1134, SPS module 1136, and cellular module 1138 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 1132, WLAN module 1134, SPS module 1136, and cellular module 1138 may include a dedicated antenna for communication with one or more other nodes, and / or utilize antenna 1140. For example, UE device 1102 can communicate with other UEs (e.g., sidelink communications) and / or network entities 104 (e.g., uplink / downlink communications) via transceiver(s)(1130) and antenna 1140, where network entities 104 may correspond to base stations or base station units such as RU106, DU108, or CU110.

[0081] The wireless baseband processor 1126 and the application processor 1106 may each include computer-readable media / memories 1126' and 1106', respectively. An additional memory module 1116 may also be considered computer-readable media / memories. Each of the computer-readable media / memories 1126', 1106', and 1116 may be non-temporary. The wireless baseband processor 1126 and the application processor 1106 may each be responsible for general processing, including the execution of software stored in the computer-readable media / memories 1126', 1106', and 1116. When the software is executed by the wireless baseband processor 1126 / application processor 1106, it causes the wireless baseband processor 1126 / application processor 1106 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 1126 / application processor 1106 when the software is executed. The wireless baseband processor 1126 / application processor 1106 may be components of the UE 102. The UE device 1102 may be a processor chip (e.g., a modem and / or application) and may include only the wireless baseband processor 1126 and / or the application processor 1106. In other examples, the UE device 1102 may be the entire UE 102 and may include additional modules of the device 1102.

[0082] As illustrated in Figure 1 and implemented with respect to Figure 8, the UCI multiplexing component 140 is configured to receive control signaling from a network entity to schedule a PUSCH retransmission of a multicodeword PUSCH and to transmit a PUSCH retransmission to the network entity based on a UCI multiplexing procedure for the multicodeword PUSCH, the UCI multiplexing procedure preventing the UCI from being multiplexed on an invalid codeword or on a codeword having a reserved MCS based on the value of the reserved MCS. The UCI multiplexing component 140 may reside in the application processor 1106 (e.g., as 140a), in the wireless baseband processor 1126 (e.g., as 140b), or in both the application processor 1106 and the wireless baseband processor 1126. The UCI multiplexing components 140a to 140b may be one or more hardware components specifically configured to execute a defined process / algorithm, may be implemented by one or more processors configured to execute a defined process / algorithm, may be stored in a computer-readable medium for implementation by one or more processors, or may be a combination thereof.

[0083] Figure 12 is a diagram 1200 showing an example of a hardware implementation for one or more network entities 104. One or more network entities 104 may be a base station, a base station component, or perform the functions of a base station. One or more network entities 104 may include or correspond to at least one of RU106, DU108, or CU110. CU110 may include a CU processor 1246 which may have on-chip memory 1246'. In some embodiments, CU110 may further include an additional memory module 1256 and / or a communication interface 1248 which may be coupled to the CU processor 1246. CU110 may communicate with DU108 via a midhall link 162, such as an F1 interface, between the communication interface 1248 of CU110 and the communication interface 1228 of DU108.

[0084] DU108 may include a DU processor 1226 which may have on-chip memory 1226'. In some embodiments, DU108 may further include an additional memory module 1236 and / or a communication interface 1228 which may be coupled to the DU processor 1226. DU108 may communicate with RU106 via a fronthaul link 160 between the communication interface 1228 of DU108 and the communication interface 1208 of RU106.

[0085] RU106 may include an RU processor 1206 which may have on-chip memory 1206'. In some embodiments, RU106 may further include an additional memory module 1216, a communication interface 1208, and one or more transceivers 1230 which may be coupled to the RU processor 1206. RU106 may further include an antenna 1240 which may be coupled to one or more transceivers 1230, thereby enabling RU106 to communicate with UE102 via the antenna 1240 through one or more transceivers 1230.

[0086] The on-chip memories 1206', 1226', 1246', and the additional memory modules 1216, 1236, 1256 may each be considered computer-readable media / memory. Each computer-readable media / memory may be non-temporary. Each of the processors 1206, 1226, and 1246 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) 1206, 1226, and 1246, it causes the processor(s) 1206, 1226, and 1246 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) 1206, 1226, and 1246 when the software is executed. In the example, the PUSCH scheduling 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.

[0087] As illustrated in Figure 1 and implemented with respect to Figure 9, the PUSCH scheduling component 150 is configured to send control signaling to the UE to schedule PUSCH retransmissions of multicodeword PUSCH and to receive PUSCH retransmissions from the UE based on a UCI multiplexing procedure for multicodeword PUSCH, the UCI multiplexing procedure preventing the UCI from being multiplexed on an invalid codeword or on a codeword having a reserved MCS based on the value of the reserved MCS. The PUSCH scheduling component 150 may reside in one or more processors of one or more network entities 104, such as the RU processor 1206 (e.g., as 150a), the DU processor 1226 (e.g., as 150b), and / or the CU processor 1246 (e.g., as 150c). The PUSCH scheduling components 150a to 150c may be one or more hardware components specifically configured to execute a defined process / algorithm, or may be implemented by one or more processors 1206, 1226, 1246 configured to execute a defined process / algorithm, or may be stored in a computer-readable medium for implementation by one or more processors 1206, 1226, 1246, or a combination thereof.

[0088] The specific order or hierarchy of the blocks in the processes and flowcharts disclosed herein is illustrative and describes an exemplary approach. Therefore, the specific order or hierarchy of the 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 figures. The claims of the accompanying methods present the 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.

[0089] 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.

[0090] 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.

[0091] 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.

[0092] 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.

[0093] 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.

[0094] 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.

[0095] 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.

[0096] 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.

[0097] 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.

[0098] 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.).

[0099] 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.

[0100] The following examples are illustrative and may be combined with other examples or teachings described herein without limitation. Embodiment 1 is a wireless communication method in a UE, which includes receiving control signaling from a network entity to schedule a PUSCH retransmission of a multicodeword PUSCH, and transmitting a PUSCH retransmission to the network entity based on a UCI multiplexing procedure for the multicodeword PUSCH, the UCI multiplexing procedure preventing the UCI from being multiplexed on an invalid codeword or on a codeword having a reserved MCS based on the value of the reserved MCS.

[0101] Example 2 can be combined with Example 1, and the control signaling indicates that the multicodeword PUSCH includes the invalidated codeword in PUSCH retransmission.

[0102] Embodiment 3 can be combined with Embodiment 2, and the transmission of PUSCH retransmission further includes transmitting a UCI multiplexed over an enabled codeword of multicodeword PUSCH to a network entity.

[0103] Example 4 can be combined with Example 2, and the UCI multiplexing procedure includes dropping the UCI or data from the PUSCH retransmission when scheduling the UCI over a codeword where control signaling has been disabled.

[0104] Example 5 may be combined with Example 1, and the control signaling includes the multicodeword PUSCH indicating a codeword with a reserved MCS in PUSCH retransmission.

[0105] Example 6 may be combined with Example 5, and the UCI multiplexing procedure includes multiplexing the UCI to the PUSCH retransmission based on a value different from the reserved MCS value, where the different value corresponds to at least one of the following: the MCS of the initial transmission codeword, the nominal MCS calculated based on the reserved MCS, or the spectral efficiency.

[0106] Example 7 can be combined with Example 5, and the UCI multiplexing procedure includes dropping the UCI or data from the PUSCH retransmission when the control signaling schedules the UCI on a codeword that has a reserved MCS.

[0107] Example 8 can be combined with Example 5, and the UCI multiplexing procedure that prevents the UCI from being multiplexed on a codeword having a reserved MCS based on the value of the reserved MCS includes transmitting the UCI multiplexed on each codeword of the multicodeword PUSCH to the network entity.

[0108] Example 9 can be combined with Example 5 and further includes multiplexing the UCI over the indicated codeword of the multicodeword PUSCH for PUSCH retransmission, the indicated codeword is indicated by control signaling.

[0109] Example 10 may be combined with Example 5 and further includes multiplexing the UCI over a predefined codeword associated with the multicodeword PUSCH for PUSCH retransmission.

[0110] Example 11 may be combined with any one of Examples 1 to 10 and further includes receiving the configuration of the UCI multiplexing procedure in PUSCH retransmission from a network entity, if the multicodeword PUSCH includes at least one of the invalidated codewords or codewords having a reserved MCS.

[0111] Example 12 may be combined with any one of Examples 1 to 11 and further includes sending a UE capability report to the network entity indicating the UE's capability with respect to the UCI multiplexing procedure in PUSCH retransmission, if the multicodeword PUSCH includes at least one of the codewords that have been disabled or have a reserved MCS.

[0112] Example 13 is a wireless communication method in a network entity, which includes transmitting a control signaling to the UE to schedule a PUSCH retransmission of a multicodeword PUSCH, and receiving a PUSCH retransmission from the UE based on a UCI multiplexing procedure for the multicodeword PUSCH, the UCI multiplexing procedure preventing the UCI from being multiplexed on an invalid codeword or on a codeword having a reserved MCS based on a reserved MCS value.

[0113] Example 14 may be combined with Example 13, and the control signaling includes the multicodeword PUSCH indicating an invalidated codeword in PUSCH retransmission.

[0114] Example 15 may be combined with Example 14, and receiving a PUSCH retransmission further includes receiving a UCI multiplexed on an enabled codeword of the multicodeword PUSCH from the UE.

[0115] Example 16 may be combined with Example 14, and the PUSCH retransmission includes dropping the UCI or data when scheduling the UCI on a codeword where control signaling has been disabled.

[0116] Example 17 can be combined with Example 13, and the control signaling shows that the multicodeword PUSCH includes a codeword with a reserved MCS in PUSCH retransmission.

[0117] Example 18 can be combined with Example 17, in which the UCI is multiplexed to the PUSCH retransmission based on a value different from the reserved MCS value, the different value corresponding to at least one of the following: the MCS of the initial transmission codeword, the nominal MCS calculated based on the reserved MCS, or the spectral efficiency.

[0118] Example 19 can be combined with Example 17, and the PUSCH retransmission includes dropping a UCI or data when the control signaling schedules a UCI on a codeword that has a reserved MCS.

[0119] Example 20 may be combined with Example 17, and receiving a PUSCH retransmission includes receiving a UCI multiplexed on each codeword of the multicodeword PUSCH from the UE.

[0120] Example 21 can be combined with Example 17, in which the UCI is multiplexed to PUSCH retransmission based on the indicated codeword of the multicodeword PUSCH, and the indicated codeword is indicated by control signaling.

[0121] Example 22 can be combined with Example 17, in which the UCI is multiplexed to PUSCH retransmission based on a predefined codeword associated with the multicodeword PUSCH.

[0122] Example 23 may be combined with any one of Examples 13 to 22 and further includes transmitting the configuration of the UCI multiplexing procedure in PUSCH retransmission to the UE if the multicodeword PUSCH includes at least one of the invalidated codewords or codewords having a reserved MCS.

[0123] Example 24 may be combined with any one of Examples 13 to 23 and further includes receiving a UE capability report from the UE indicating the UE's capability with respect to the UCI multiplexing procedure in PUSCH retransmission, if the multicodeword PUSCH includes at least one of the invalidated codewords or codewords with reserved MCS.

[0124] Example 25 is a wireless communication device for carrying out the method described in any one of Examples 1 to 24. Example 26 is a wireless communication device that includes means for carrying out the method described in any one of Examples 1 to 24.

[0125] Example 27 is a non-temporary computer-readable medium for storing computer executable code, which, when executed by a processor, causes the processor to perform the method described in any one of Examples 1 to 24.

Claims

1. Receiving (312) a control signaling from a network entity (104) to schedule PUSCH retransmission of a multicodeword physical uplink shared channel (PUSCH), A wireless communication method in a user equipment (UE) 102, comprising transmitting (316) the PUSCH retransmission to the network entity (104) based on the uplink control information (UCI) multiplexing procedure of the multicodeword PUSCH, wherein the UCI multiplexing procedure prevents the UCI from being multiplexed over an invalid codeword (202d) or over codewords (502a, 803a) having a reserved modulation coding scheme (MCS) based on the value of the reserved modulation coding scheme (MCS).

2. The method according to claim 1, wherein the control signaling indicates that the multicodeword PUSCH includes the invalidated codeword (202d) in the PUSCH retransmission.

3. Transmitting the aforementioned PUSCH retransmission (316) is: The method according to claim 2, further comprising transmitting (316) the UCI multiplexed on the activated codeword (202c) of the multicodeword PUSCH to the network entity (104).

4. The aforementioned UCI multiplexing procedure is: The method of claim 2, comprising dropping the UCI or data from the PUSCH retransmission when the control signaling schedules the UCI on the invalidated codeword (202d).

5. The method according to claim 1, wherein the control signaling indicates that the multicodeword PUSCH includes a codeword (502a, 803a) having the reserved MCS in the PUSCH retransmission.

6. The aforementioned UCI multiplexing procedure is: The process includes multiplexing the UCI to the PUSCH retransmission based on a value different from the reserved MCS value, wherein the different value is The MCS codeword for the initial transmission, The nominal MCS calculated based on the reserved MCS, or The method according to claim 5, which corresponds to at least one of the spectral efficiencies (SE).

7. The aforementioned UCI multiplexing procedure is: The method according to claim 5, comprising dropping the UCI or data from the PUSCH retransmission when the control signaling schedules the UCI on a codeword (502a, 803a) having the reserved MCS.

8. The UCI multiplexing procedure, which prevents the UCI from being multiplexed on a codeword (502a, 803a) having the reserved MCS based on the value of the reserved MCS, The method according to claim 5, comprising transmitting (316) the UCI multiplexed on each codeword (502b, 803a) of the multicodeword PUSCH to the network entity (104).

9. The method of claim 5, further comprising multiplexing the UCI over the indicated codeword of the multicodeword PUSCH for the purpose of retransmitting the PUSCH, wherein the indicated codeword is indicated by the control signaling.

10. The method according to claim 5, further comprising multiplexing the UCI on a predefined codeword associated with the multicodeword PUSCH for the purpose of retransmitting the PUSCH.

11. The method according to any one of claims 1 to 10, further comprising receiving (308) the configuration of the UCI multiplexing procedure in the PUSCH retransmission from the network entity (104) if the multicodeword PUSCH includes at least one of the invalidated codeword (202d) or the codewords having the reserved MCS (502a, 803a).

12. The method according to any one of claims 1 to 11, further comprising sending (306) a UE capability report to the network entity (104) indicating the UE's capability with respect to the UCI multiplexing procedure in the PUSCH retransmission, if the multicodeword PUSCH includes at least one of the invalidated codeword (202d) or the codewords (502a, 803a) having reserved MCS.

13. Sending control signaling to user equipment (UE) (102) (312) to schedule PUSCH retransmission of a multicodeword physical uplink shared channel (PUSCH), A wireless communication method in a network entity (104), comprising receiving (316) the PUSCH retransmission from the UE (102) based on the uplink control information (UCI) multiplexing procedure of the multicodeword PUSCH, wherein the UCI multiplexing procedure prevents the UCI from being multiplexed on an invalid codeword (202d) or on codewords (502a, 803a) having a reserved modulation coding scheme (MCS) based on the value of the reserved modulation coding scheme (MCS).

14. The method according to claim 13, wherein the control signaling indicates that the multicodeword PUSCH includes the invalidated codeword (202d) in the PUSCH retransmission.

15. The method according to claim 13, wherein the control signaling indicates that the multicodeword PUSCH includes codewords (502a, 803a) having the reserved MCS in the PUSCH retransmission.

16. A wireless communication device comprising a memory, a transceiver, and a processor coupled to the memory and the transceiver, the device being configured to carry out the method according to any one of claims 1 to 15.

Images