Method for uplink control information multiplexing on physical uplink shared channel with orthogonal cover code

Abstract

This disclosure provides systems, devices, apparatus, and methods, including computer programs encoded on storage media, for multiplexing uplink control information (UCI) on physical uplink shared channel (PUSCH) with orthogonal code (OCC). A user equipment, UE, receives (404), from a network entity, an orthogonal cover code, OCC, configuration indicating an OCC for a physical uplink shared channel, PUSCH, transmission and an uplink control information, UCI, multiplexing scheme. The UE transmits (408), to the network entity, the PUSCH transmission based on the OCC and with the UCI multiplexed on the PUSCH transmission based on the UCI multiplexing scheme.

Description

METHOD FOR UPLINK CONTROL INFORMATION MULTIPLEXING ON PHYSICAL UPLINK SHARED CHANNEL WITH ORTHOGONAL COVER CODETECHNICAL FIELD

[0001] The present disclosure relates generally to wireless communication, and more particularly, to multiplexing uplink control information (UCI) on physical uplink shared channel (PUSCH) with orthogonal code (OCC) .BACKGROUND

[0002] The Third Generation Partnership Project (3GPP) specifies a radio interface referred to as fifth generation (5G) new radio (NR) (5G NR) . An architecture for a 5G NR wireless communication system includes a 5G core (5GC) network, a 5G radio access network (5G-RAN) , a user equipment (5G UE) , etc. The 5G NR architecture seeks to provide increased data rates, decreased latency, and / or increased capacity compared to prior generation cellular communication systems.

[0003] Wireless communication systems, in general, provide various telecommunication services (e.g., telephony, video, data, messaging, etc. ) based on multiple-access technologies, such as orthogonal frequency division multiple access (OFDMA) technologies, that support communication with multiple UEs. Improvements in mobile broadband continue the progression of such wireless communication technologies. For example, to improve the uplink capacity and coverage, the network entity may configure the UE to transmit the physical uplink shared channel (PUSCH) based on an orthogonal cover code (OCC) . Currently, the UE transmits the uplink control information (UCI) on one of the PUSCH repetitions. However, transmitting the UCI on one of the PUSCH repetitions may disrupt the orthogonality for the PUSCH repetitions with different OCCs.

[0004] BRIEF SUMMARY

[0005] The following presents a simplified summary of one or more aspects in order to provide a basic understanding of such aspects. This summary is not an extensive overview of all contemplated aspects. This summary neither identifies key or critical elements of all aspects nor delineates the scope of any or all aspects. Its sole purpose  is to present some concepts of one or more aspects in a simplified form as a prelude to the more detailed description that is presented later.

[0006] A user equipment (UE) transmits control signal including uplink control information (UCI) to a network entity on a physical uplink control channel (PUCCH) . In certain instances, the UE transmits the UCI multiplexed on a physical uplink shared channel (PUSCH) (i.e., UCI multiplexing on PUSCH) when the PUCCH collides with the PUSCH. To improve the uplink capacity and coverage, the network entity may configure the UE to transmit the PUSCH based on an orthogonal cover code (OCC) . Currently, the UE transmits the UCI on one of the PUSCH repetitions. However, transmitting the UCI on one of the PUSCH repetitions may disrupt the orthogonality for the PUSCH repetitions with different OCCs.

[0007] Aspects of the present disclosure address the above-noted and other deficiencies by implementing techniques for the UCI multiplexing on the PUSCH based on a granularity of the OCC. In examples, the network entity transmits, to the UE, a configuration to indicate OCC parameters of a repetition-level PUSCH, such that each PUSCH repetition is transmitted based on the configured OCC. In another example, the network entity transmits, to the UE, the configuration to indicate OCC parameters of a symbol-level PUSCH, such that different PUSCH symbols are transmitted according to different OCCs. In a further example, the network entity transmits, to the UE, the configuration to indicate OCC parameters of a resource element level, (RE) -level, PUSCH, such that different REs of the PUSCH are transmitted according to different OCCs. In still further examples, the network entity transmits, to the UE, the configuration to indicate OCC parameters of granularity of the OCC via radio resource control (RRC) signaling, medium access control element (MAC CE) or downlink control information (DCI) .

[0008] According to some aspects, a UE receives, from a network entity, an OCC configuration indicating an OCC for a PUSCH transmission and an UCI multiplexing scheme. The UE transmits, to the network entity, the PUSCH transmission based on the OCC and with the UCI multiplexed on the PUSCH transmission based on the UCI multiplexing scheme.

[0009] According to some aspects, a network entity transmits, to a UE, an OCC configuration indicating an OCC for a PUSCH transmission and an uplink control information, UCI, multiplexing scheme. The network entity receives, from the UE,  the PUSCH transmission based on the OCC and with the UCI multiplexed on the PUSCH transmission based on the UCI multiplexing scheme.BRIEF DESCRIPTION OF THE DRAWINGS

[0010] FIG. 1 illustrates a diagram of a wireless communications system that includes a plurality of user equipments (UEs) and network entities in communication over one or more cells according to an embodiment.

[0011] FIG. 2 is an example for UCI multiplexing on PUSCH with multiple repetitions according to an embodiment.

[0012] FIG. 3 is an example for PUSCH based on different OCCs for different UEs according to an embodiment.

[0013] FIG. 4 is a signaling diagram illustrating communications between a user equipment (UE) and a network entity for UCI multiplexing on PUSCH based on OCC according to an embodiment.

[0014] FIG. 5 is an example for OCC configuration with OCC length (OCC length = 4) smaller than number of repetitions according to an embodiment.

[0015] FIG. 6 is an example for beam-specific OCC according to an embodiment.

[0016] FIG. 7 is an example for the TCI and PUSCH repetition multiplexing based on the OCC length according to an embodiment.

[0017] FIG. 8 is an example for the PUSCH transmission with UCI multiplexed according to an embodiment.

[0018] FIG. 9 is an example for PUSCH with OCC for PUSCH repetitions with different size according to an embodiment.

[0019] FIG. 10 is an example for the OCC hopping for different sets of repetitions according to an embodiment.

[0020] FIG. 11 is an example for the symbol level OCC for PUSCH transmission with OCC = {1, -1} according to an embodiment.

[0021] FIG. 12 is an example for orphan PUSCH symbols for an OCC group according to an embodiment.

[0022] FIG. 13 is an example for the RE level OCC for PUSCH transmission with OCC = {1, 1} based on post-DFT FD-OCC-2 and OCC= {1, -1} based on TD-OCC-2 by frequency-first OCC group indexing according to an embodiment.

[0023] FIG. 14 is an example for the complex-valued symbol level OCC for PUSCH transmission with OCC = {1, 1} based on pre-DFT FD-OCC-2 according to an embodiment.

[0024] FIG. 15 is an example for the RE based OCC per RB, (a) OCC= {1, -1} with block-wise repetition; (b) OCC= {1, -1} with interlaced repetition; (c) OCC= {1, -1, 1, -1} with block-wise repetition; (d) OCC= {1, -1, 1, -1} with interlaced repetition according to an embodiment.

[0025] FIG. 16 is an example for the UCI multiplexing on X PUSCH repetitions with X = K (OCC length) according to an embodiment.

[0026] FIG. 17 is an example for UCI multiplexing on symbol-level OCC based PUSCH with OCC = {1, -1} according to an embodiment.

[0027] FIG. 18 is an example for the RE level OCC for PUSCH transmission with OCC = {1, 1} based on FD-OCC-2 and OCC= {1, -1} based on TD-OCC-2 for data and OCC= {1, 1, 1, 1} based on FD-OCC-4 and OCC= {1, -1} based on TD-OCC-2 for UCI according to an embodiment.

[0028] FIG. 19 is a flowchart of a method of wireless communication at a UE according to an embodiment.

[0029] FIG. 20 is a flowchart of a method of wireless communication at a network entity according to an embodiment.

[0030] FIG. 21 is a diagram illustrating a hardware implementation for an example UE apparatus according to some embodiments.

[0031] FIG. 22 is a diagram illustrating a hardware implementation for one or more example network entities according to some embodiments.DETAILED DESCRIPTION

[0032] FIG. 1 illustrates a diagram 100 of a wireless communications system associated with a plurality of cells 190. The wireless communications system includes user equipments (UEs) 102 and base stations / network entities 104. Some base stations may include an aggregated base station architecture and other base stations may include a disaggregated base station architecture. The aggregated base station architecture utilizes a radio protocol stack that is physically or logically integrated within a single radio access network (RAN) node. A disaggregated base station architecture utilizes a protocol stack that is physically or logically distributed among two or more units (e.g., radio unit (RU) 106, distributed unit (DU) 108, central unit (CU) 110) . For  example, a CU 110 is implemented within a RAN node, and one or more DUs 108 may be co-located with the CU 110, or alternatively, may be geographically or virtually distributed throughout one or multiple other RAN nodes. The DUs 108 may be implemented to communicate with one or more RUs 106. Any of the RU 106, the DU 108 and the CU 110 can be implemented as virtual units, such as a virtual radio unit (VRU) , a virtual distributed unit (VDU) , or a virtual central unit (VCU) . The base station / network entity 104 (e.g., an aggregated base station or disaggregated units of the base station, such as the RU 106 or the DU 108) , may be referred to as a transmission reception point (TRP) .

[0033] Operations of the base station 104 and / or network designs may be based on aggregation characteristics of base station functionality. For example, disaggregated base station architectures are utilized in an integrated access backhaul (IAB) network, an open-radio access network (O-RAN) network, or a virtualized radio access network (vRAN) , which may also be referred to a cloud radio access network (C-RAN) . Disaggregation may include distributing functionality across the two or more units at various physical locations, as well as distributing functionality for at least one unit virtually, which can enable flexibility in network designs. The various units of the disaggregated base station architecture, or the disaggregated RAN architecture, can be configured for wired or wireless communication with at least one other unit. For example, the base stations 104d, 104e and / or the RUs 106a, 106b, 106c, 106d may communicate with the UEs 102a, 102b, 102c, 102d, and / or 102s via one or more radio frequency (RF) access links based on a Uu interface. In examples, multiple RUs 106 and / or base stations 104 may simultaneously serve the UEs 102, such as by intra-cell and / or inter-cell access links between the UEs 102 and the RUs 106 / base stations 104.

[0034] The RU 106, the DU 108, and the CU 110 may include (or may be coupled to) one or more interfaces configured to transmit or receive information / signals via a wired or wireless transmission medium. For example, a wired interface can be configured to transmit or receive the information / signals over a wired transmission medium, such as via the fronthaul link 160 between the RU 106d and the baseband unit (BBU) 112 of the base station 104d associated with the cell 190d. The BBU 112 includes a DU 108 and a CU 110, which may also have a wired interface (e.g., midhaul link) configured between the DU 108 and the CU 110 to transmit or receive the information / signals between the DU 108 and the CU 110. In further examples, a  wireless interface, which may include a receiver, a transmitter, or a transceiver, such as an RF transceiver, configured to transmit and / or receive the information / signals via the wireless transmission medium, such as for information communicated between the RU 106a of the cell 190a and the base station 104e of the cell 190e via cross-cell communication beams 136-138 of the RU 106a and the base station 104e.

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

[0036] The RUs 106 may transmit or receive over-the-air (OTA) communication with one or more UEs 102. For example, the RU 106b of the cell 190b communicates with the UE 102b of the cell 190b via a first set of communication beams 132 of the RU 106b and a second set of communication beams 134b of the UE 102b, which may correspond to inter-cell communication beams or, in some examples, cross-cell communication beams. For instance, the UE 102b of the cell 190b may communicate with the RU 106a of the cell 190a via a third set of communication beams 134a of the UE 102b and a fourth set of communication beams 136 of the RU 106a. DUs 108 can control both real-time and non-real-time features of control plane and user plane communications of the RUs 106.

[0037] Any combination of the RU 106, the DU 108, and the CU 110, or reference thereto individually, may correspond to a base station 104. Thus, the base station 104 may include at least one of the RU 106, the DU 108, or the CU 110. The base stations 104 provide the UEs 102 with access to a core network. The base stations 104 may relay communications between the UEs 102 and the core network (not shown) . The base stations 104 may be associated with macrocells for higher-power cellular base stations and / or small cells for lower-power cellular base stations. For example, the cell 190e may correspond to a macrocell, whereas the cells 190a-190d may correspond to small cells. Small cells include femtocells, picocells, microcells, etc. A network that includes at least one macrocell and at least one small cell may be referred to as a “heterogeneous network. ”

[0038] Transmissions from a UE 102 to a base station 104 / RU 106 are referred to as uplink (UL) transmissions, whereas transmissions from the base station 104 / RU 106 to the UE 102 are referred to as downlink (DL) transmissions. Uplink transmissions may also be referred to as reverse link transmissions and downlink transmissions may also be referred to as forward link transmissions. For example, the RU 106d utilizes antennas of the base station 104d of cell 190d to transmit a downlink / forward link communication to the UE 102d or receive an uplink / reverse link communication from the UE 102d based on the Uu interface associated with the access link between the UE 102d and the base station 104d / RU 106d.

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

[0040] Some UEs 102, such as the UEs 102a and 102s, may perform device-to-device (D2D) communications over sidelink. For example, a sidelink communication / D2D link utilizes a spectrum for a wireless wide area network (WWAN) associated with uplink and downlink communications. Such sidelink / D2D communication may be performed through various wireless communications systems, such as wireless fidelity (Wi-Fi) systems, Bluetooth systems, Long Term Evolution (LTE) systems, New Radio (NR) systems, etc.

[0041] The UEs 102 and the base stations 104 / RUs 106 may each include a plurality of antennas. The plurality of antennas may correspond to antenna elements, antenna panels, and / or antenna arrays that may facilitate beamforming operations. For example, the RU 106b transmits a downlink beamformed signal based on a first set  of communication beams 132 to the UE 102b in one or more transmit directions of the RU 106b. The UE 102b may receive the downlink beamformed signal based on a second set of communication beams 134b from the RU 106b in one or more receive directions of the UE 102b. In a further example, the UE 102b may also transmit an uplink beamformed signal (e.g., sounding reference signal (SRS) ) to the RU 106b based on the second set of communication beams 134b in one or more transmit directions of the UE 102b. The RU 106b may receive the uplink beamformed signal from the UE 102b in one or more receive directions of the RU 106b. The UE 102b may perform beam training to determine the best receive and transmit directions for the beamformed signals. The transmit and receive directions for the UEs 102 and the base stations 104 / RUs 106 may or may not be the same.

[0042] In further examples, beamformed signals may be communicated between a first base station / RU 106a and a second base station 104e. For instance, the base station 104e of the cell 190e may transmit a beamformed signal to the RU 106a based on the communication beams 138 in one or more transmit directions of the base station 104e. The RU 106a may receive the beamformed signal from the base station 104e of the cell 190e based on the RU communication beams 136 in one or more receive directions of the RU 106a. In further examples, the base station 104e transmits a downlink beamformed signal to the UE 102e based on the communication beams 138 in one or more transmit directions of the base station 104e. The UE 102e receives the downlink beamformed signal from the base station 104e based on UE communication beams 130 in one or more receive directions of the UE 102e. The UE 102e may also transmit an uplink beamformed signal to the base station 104e based on the UE communication beams 130 in one or more transmit directions of the UE 102e, such that the base station 104e may receive the uplink beamformed signal from the UE 102e in one or more receive directions of the base station 104e.

[0043] The base station 104 may include and / or be referred to as a network entity. That is, “network entity” may refer to the base station 104 or at least one unit of the base station 104, such as the RU 106, the DU 108, and / or the CU 110. The base station 104 may also include and / or be referred to as a next generation evolved Node B (ng-eNB) , a next generation NB (gNB) , an evolved NB (eNB) , an access point, a base transceiver station, a radio base station, a radio transceiver, a transceiver function, a basic service set (BSS) , an extended service set (ESS) , a TRP, a network node, network equipment, or other related terminology. The base station 104 or an entity at  the base station 104 can be implemented as an IAB node, a relay node, a sidelink node, an aggregated (monolithic) base station, or a disaggregated base station including one or more RUs 106, DUs 108, and / or CUs 110. A set of aggregated or disaggregated base stations may be referred to as a next generation-radio access network (NG-RAN) . In some examples, the UE 102a operates in dual connectivity (DC) with the base station 104e and the base station / RU 106a. In such cases, the base station 104e can be a master node and the base station / RU 160a can be a secondary node.

[0044] Still referring to FIG. 1, in certain aspects, any of the UEs 102 may include a UE UCI Multiplexing OCC component 140 configured to receive, from a network entity, an OCC configuration indicating an OCC for a PUSCH transmission and an UCI multiplexing scheme; and to transmit, to the network entity, the PUSCH transmission based on the OCC and with the UCI multiplexed on the PUSCH transmission based on the UCI multiplexing scheme.

[0045] In certain aspects, any of the base stations 104 or a network entity of the base stations 104 may include an NE UCI Multiplexing OCC component 150 configured to transmit, to a UE, an OCC configuration indicating an OCC for a PUSCH transmission and an uplink control information, UCI, multiplexing scheme; and to receive, from the UE, the PUSCH transmission based on the OCC and with the UCI multiplexed on the PUSCH transmission based on the UCI multiplexing scheme.

[0046] Accordingly, FIG. 1 describes a wireless communication system that may be implemented in connection with aspects of one or more other figures described herein. Further, although the following description may be focused on 5G NR, the concepts described herein may be applicable to other similar areas, such as 5G-Advanced and future versions, LTE, LTE-advanced (LTE-A) , and other wireless technologies, such as 6G.

[0047] FIG. 2 illustrates a diagram 200 of an example procedure for a UCI multiplexing on PUSCH with multiple repetitions.

[0048] In some implementations, the network entity may configure the UE to transmit the UCI by a physical uplink control channel (PUCCH) . The UCI may include one or multiple of the information: hybrid automatic repeat request (HARQ) acknowledgement (ACK) information 202, channel state information (CSI) , which may include at least one of the CSI part 1 204 and CSI part 2 206, and scheduling request (SR) . When the PUCCH collides with the PUSCH, the UE may multiplex the  UCI on the PUSCH except for the SR. If the UE transmits the PUSCH from multiple repetitions from the same beam (e.g., the same transmission configuration indicator (TCI) state) , the UE may multiplex the UCI on the first repetition 212. If the UE transmits the PUSCH from multiple repetitions from multiple beams (e.g., multiple TCI states) , the UE may multiplex the UCI on the first repetition 212 of each beam.

[0049] In some other implementations, the network entity may configure the UE to report the CSI, for example, semi-persistent CSI or aperiodic CSI, by the PUSCH. Then, the UE transmits the CSI on the first PUSCH repetition 212 or the first PUSCH repetition of each beam. The UE refrains from transmitting other repetitions if the UE is not scheduled to transmit data on the PUSCH repetitions. Thus, the UE may transmit the PUSCH with CSI only from 1 repetition or N, e.g., N=2, repetitions, where N equals to the number of beams applied to the PUSCH. If the UE is scheduled to transmit data on the PUSCH repetitions, the UE transmit the data on each PUSCH repetition and multiplex the semi-persistent CSI or aperiodic CSI on the first PUSCH repetition 212 or the first PUSCH repetition of each beam.

[0050] The network entity can configure the number of resource elements (REs) for HARQ-ACK 202, CSI part 1 204 and CSI part 2 206 based on a first beta offset  asecond beta offset and a third beta offset The UE determines the coding rate for the HARQ-ACK RHARQ-ACK, coding rate for the CSI part 1 RCSI-part1 and coding rate for the CSI part 2 RCSI-part2 based on the coding rate R for data 208 (when there is data on the PUSCH) or the target coding rate (when there is no data on the PUSCH) and the beta offsets as follows:

[0051] Accordingly, the number of REs for HARQ-ACK QHARQ-ACK, the number of REs for CSI part 1 QCSI-part1, the number of REs for CSI part 2 QCSI-part2 can be obtained based on the number of bits for HARQ-ACK with CRC OHARQ-ACK, the number of bits for CSI part 1 with CRC OCSI-part1, the number of bits for CSI part 2 with CRC OCSI-part2, the coding rate and modulation order Qm as follows:

[0052] where, α is a scaling factor configured by radio resource control (RRC) signaling by the network entity; NRE indicates number of REs for the PUSCH transmission, for example, the PUSCH repetition with the UCI multiplexed, excluding a demodulation reference signals (DMRS) 210.

[0053] FIG. 3 is an example for PUSCH based on different OCCs for different UEs according to an embodiment.

[0054] To improve the uplink capacity and coverage, the network entity may configure the UE to transmit the PUSCH based on an OCC. The UE may apply a list of OCCs to PUSCH repetitions or PUSCH symbols / REs within a repetition. Then, the network entity can schedule the PUSCHs from different UEs by different OCCs to reduce the mutual interference between the UEs. For example, the network entity can schedule the PUSCHs from a UE1 300 by using OCC 302. The network entity can schedule the PUSCHs from a UE2 310 by using OCC 312.

[0055] FIG. 4 is a signaling diagram 400 illustrating communications between a user equipment (UE) and a network entity for UCI multiplexing on PUSCH based on OCC according to an embodiment. The network entity 104 may correspond to a base station or a unit of a base station, such as the RU 106, the DU 108, the CU 110, etc.

[0056] Referring to FIG. 4, in some implementations, a UE may optionally transmit 402 (or the network entity may receive, from the UE) , to a network entity, UE capability report indicating UE capability on the supported configuration for the PUSCH based on OCC and / or the supported configuration for the UCI multiplexing on PUSCH based on OCC. For example, the UE reports at least one of the following capabilities: whether the UE supports the PUSCH with OCC; the supported OCC granularity, e.g., repetition level, symbol level and / or RE level; the supported maximum OCC length; whether the UE supports UCI multiplexing on the PUSCH with OCC; whether the  UE supports aperiodic and / or semi-persistent CSI feedback on the PUSCH with OCC; supported OCC granularity for the UCI multiplexed on PUSCH based on OCC; supported maximum OCC length for the UCI multiplexed on PUSCH based on OCC; whether the UE supports OCC hopping; whether the UE supports OCC hopping based on configured candidate OCCs. The UE may report the UE capabilities as described above per feature set, per band or per band combination. The UE may report the UE capabilities as described above separately for different PUSCH transmission operations, such as, single transmission reception point (sTRP) , single DCI based multiple TRP (mTRP) , and multiple DCI based mTRP.

[0057] In response to receiving the UE capability report and based on the UE capability report, the network entity transmits 404, to the UE 102, (or the UE receives, from the network entity) , control signaling configuring at least one of: configuration of OCC for PUSCH; configuration of the PUSCH waveform; configuration of UCI multiplexing on PUSCH based on OCC; and optionally configuring an uplink grant for PUSCH transmission based on OCC and configured waveform, and / or a PUCCH resource for CSI feedback.

[0058] In some examples, the configuration of the PUSCH based on the OCC includes at least one of the parameters: the OCC to be applied, the OCC granularity (e.g., repetition level, symbol level, and / or RE level) , OCC length, and / or configuration for OCC hopping.

[0059] In some examples, the configuration of the OCC for the UCI multiplexed on the PUSCH includes at least one of the parameters: the OCC to be applied for UCI, the OCC granularity for the UCI, the OCC length for the UCI, and / or number of repetitions to be applied for the UCI.

[0060] In some examples, the configuration of the PUSCH waveform, such as, whether the transform precoder is enabled or not. In one example, the PUSCH based on OCC may only be applicable when transform precoder is enabled.

[0061] In some implementations, the network entity may optionally transmit 406, to the UE (the UE may receive, from the network entity) , medium access control element (MAC CE) activating semi-persistent CSI feedback on PUSCH; or downlink control information (DCI) triggering aperiodic CSI on PUSCH; or DCI triggering a PUSCH transmission overlapping with a PUCCH in time domain. The MAC CE or DCI optionally indicating at least one of the following: part of or all the configuration of OCC for PUSCH, part of or all the configuration of UCI multiplexing on PUSCH  based on OCC, and / or the waveform for the PUSCH. The network entity may optionally configure an uplink grant for PUSCH based on OCC, and / or a PUCCH resource for CSI report, e.g., periodic CSI report. The network entity may transmit the control signaling by Radio Resource Control (RRC) signaling, e.g., RRCReconfiguration.

[0062] The network entity and the UE may determine the OCC for the UCI and PUSCH and the UCI multiplexing scheme based on the configuration and indication.

[0063] The UE transmits 408, to the network entity, (the network entity receives from the UE) the PUSCH based on OCC and UCI multiplexed on one or multiple PUSCH repetitions based on the determined UCI multiplexing scheme. The network entity may receive the PUSCH based on OCC and UCI multiplexed on one or multiple PUSCH repetitions based on the determined UCI multiplexing scheme. In different examples or implementations, a PUSCH repetition may indicate an actual PUSCH repetition or a nominal PUSCH repetition. A PUSCH repetition corresponds to a PUSCH transmission occasion. In some other implementations, the UE may drop the UCI or drop the PUSCH when it identifies the collision between PUCCH with UCI other than SR and the PUSCH based on OCC. Thus, the UE may transmit the PUCCH only or transmit the PUSCH with data based on OCC only.

[0064] In some implementations, the UE may transmit the PUSCH based on OCC if the UE identifies one or multiple of the following condition: the transform precoder is enabled; the PUSCH with OCC is enabled; the PUSCH includes data; the PUSCH does not include any UCI. If the UE does not identify the one or multiple of the conditions as described above, the UE may transmit the PUSCH without OCC.

[0065] In an embodiment, the network entity may configure the UE to transmit the PUSCH by K repetitions and configure the OCC with a length of K for the PUSCH. The network entity may configure the OCC from a list of pre-defined or configured OCCs and / or the OCC length for the PUSCH transmission. The UE transmits each PUSCH repetition based on the configured OCC including or excluding the DMRS for the PUSCH.

[0066] In some implementations, the OCC length may be the same as the number of repetitions. In some other implementations, the number of repetitions may be larger than the OCC length, such as, the number of repetitions may be multiple of the OCC length.

[0067] FIG. 5 is an example 500 for OCC configuration with OCC length (OCC length = 4) smaller than number of repetitions according to an embodiment.

[0068] Referring to FIG. 5, the OCC 508 {1, 1, -1, -1} length is 4. As shown in FIG. 5, the number of repetitions 502 for the PUSCH transmission is larger than 4. Therefore, the UE may apply the OCC cyclically. For example, the UE applies the OCC 508 in the first cycle 504 (e.g., 4 PUSCH repetitions) and in the second cycle 506 (e.g., 4 PUSCH repetitions) .

[0069] In some other implementations, the number of repetitions (Nrep) may be smaller than the OCC length. The UE may apply the first Nrep OCC for the PUSCH repetitions. Alternatively, the network entity may refrain from configuring smaller number of repetitions for PUSCH than the OCC length. Thus, the UE may expect the number of repetitions for PUSCH is equal to or larger than the OCC length.

[0070] In some implementations, the network entity and the UE may determine the OCC for the PUSCH repetitions from the same beam (e.g., the same TCI state) . In some other implementations, the network entity may configure a common OCC or separate OCCs for PUSCH repetitions corresponding to different beams (e.g., different TCI states) .

[0071] FIG. 6 is an example 600 for beam-specific OCC according to an embodiment. Referring to FIG. 6, the network entity may configure an OCC 610 {1, 1, -1, -1} for PUSCH repetitions corresponding to different beams, such as, TCI 1 and TCI 2. For TCI 1, first OCC group 602 and second OCC group 606 may be configured. Similarly, for TCI 2, first OCC group 604 and second OCC group 608 may be configured.

[0072] Alternatively, the network entity refrains from scheduling the PUSCH with different beams applied to different PUSCH repetitions, e.g., time division multiplexing (TDM) scheme for PUSCH transmission, with OCC.

[0073] In some other implementations, the network entity may configure the multiplexing scheme for the indicated TCI states and PUSCH repetitions based on the OCC length.

[0074] FIG. 7 is an example 700 for the TCI and PUSCH repetition multiplexing based on the OCC length according to an embodiment.

[0075] In one example, the network entity schedules the PUSCH transmission from two TCI states (e.g., two beams) , TCI 1 706 and TCI 2 708. The network entity configures the first TCI state 706 to be applied to the PUSCH repetitions 702 based on the OCC {1, 1, -1, -1) and the second TCI state 708 to be applied to the PUSCH repetitions 704  based on the OCC {1, 1, -1, -1} . In another example, the network entity may configure each indicated TCI state to be applied to every K PUSCH repetitions in turns.

[0076] In some implementations, the UE and the network entity may apply the OCC for the PUSCH repetitions without UCI multiplexed. Thus, the UE and network entity may determine the OCC is applied to PUSCH repetitions without UCI multiplexed.

[0077] FIG. 8 is an example for the PUSCH transmission with UCI multiplexed according to an embodiment. Referring to FIG. 8, the PUSCH transmission 802 is transmitted without OCC. The UCI is multiplexed on the PUSCH transmission 802 without OCC. The PUSCH transmission 804 is transmitted without UCI based on OCC 806.

[0078] In some implementations, if the number of REs for PUSCH transmission or number of symbols for PUSCH transmission in different repetitions are different, the UE may perform one of the following: drop the PUSCH repetition based on a different number of REs / symbols for PUSCH compared to a reference PUSCH repetition, e.g., the first PUSCH repetition or the PUSCH repetition with minimum number of REs or symbols; drop the whole PUSCH transmission; transmit the PUSCH repetitions based on the available REs or symbols as the reference PUSCH repetition; transmit all the PUSCH repetitions but applying the OCC to the PUSCH repetition with the same number of REs or symbols as the reference PUSCH repetition only; transmit all the PUSCH repetitions and applying the OCC to each PUSCH repetition. Alternatively, the network entity may configure the corresponding UE behavior based on one of the above for this case. The UE may report the UE capability indicating the supported UE behavior (s) based on one or multiple of the above for this case.

[0079] FIG. 9 is an example 900 for PUSCH with OCC for PUSCH repetitions with different size according to an embodiment.

[0080] Referring to FIG. 9, the number of REs may be different because of a slot boundary. For example, in one slot of 14 symbols, the first repetition 902 is transmitted on the first 5 symbols, the second repetition 904 is transmitted on the second 5 symbols. In this case, 4 symbols remain within this slot and therefore, the third repetition 906 is transmitted on the remaining 4 symbols. Therefore, the number of REs for the first and second repetitions 902, 904 is different from the number of REs for the third repetition 906.

[0081] In some implementations, the UE may transmit the PUSCH repetitions based on the same transmission power, such as, the transmission power that the UE determined for the first transmission occasion or the first repetition for the PUSCH. In some other implementations, the UE may transmit every M PUSCH repetitions based on the same transmission power, such as, the transmission power that the UE determined for the first transmission occasion or the first repetition for every M PUSCH repetitions. The value of M may be configured by the network entity by the RRC signaling, MAC CE or DCI, or be predefined, for example, the same as one or multiple of OCC length.

[0082] In one example, the value of M may be configured or indicated by the uplink grant configured by the RRC signaling or DCI. In another example, the value of M may be indicated by the MAC CE activating the semi-persistent CSI report. In some other implementations, the value of M may be reported by the UE. The UE may report the value of M by UE capability.

[0083] In some implementations, the network entity may refrain from indicating the transmission power control (TPC) command that may lead to different transmission power for the PUSCH repetitions within the whole PUSCH transmission or the PUSCH repetitions within every M PUSCH repetitions. In some other implementations, the UE may apply the TPC command before the minimum preparation time before the first PUSCH repetition within the whole PUSCH transmission or the first PUSCH repetition within every M PUSCH repetitions, where the minimum preparation time may be predefined or reported by the UE capability or configured by the network entity (e.g., minimum k2 configured in PUSCH-ConfigCommon or minimum Tproc, 2 defined in 3GPP Technical Specification (TS) 38.214, section 6.4) .

[0084] In some implementation, the network entity transmits an OCC configuration to a UE, where the OCC configuration includes a number of PUSCH repetition and an orthogonal sequence indication. Then the network entity transmits a scheduling DCI to a network entity, where the scheduling DCI allocates the same number of REs and orthogonal frequency division multiple (OFDM) symbols to each PUSCH repetition and a redundancy version (RV) . Based on the scheduling DCI, the UE applies the same RV to each PUSCH repetition in the bit selection and rate matching procedures. Then, the UE applies the orthogonal sequence indicated by the OCC configuration to PUSCH repetitions. If the length of the orthogonal sequence is shorter than the number of PUSCH repetitions, the UE repeats the orthogonal sequence pattern to all  PUSCH repetitions. The UE expects the network entity configures a length of orthogonal sequence that can divide the number of PUSCH repetitions. After the UE applies the OCC to the PUSCH repetition, the UE transmits the PUSCH repetition to the network entity.

[0085] In some implementations, the network entity indicates the number of PUSCH repetitions and the orthogonal sequence by the scheduling DCI. In some examples, the indications in the scheduling DCI associated to at least one of the followings: a predefined (defined in the specification) list (or table) of applicable number of PUSCH repetitions and / or a list (or table) of applicable orthogonal sequences. In some other examples, the network entity includes at least one of following information in the OCC configuration, a list of applicable number of PUSCH repetitions and / or a list of applicable orthogonal sequences index where each index associate with a predefined orthogonal sequence.

[0086] In some implementations, the network entity configures, to the UE, either the number of PUSCH repetitions or the orthogonal sequence by using the OCC configuration. And the network entity indicates, to the UE, another information (refer to the number of PUSCH repetitions or the orthogonal sequence that is not included in the OCC configuration) by using the scheduling DCI, and / or with the associated list included in the OCC configuration as described in the previous implementations.

[0087] In some implementations, instead of using DCI, the network entity transmits a MAC CE, to the UE, to indicate the number of PUSCH repetitions or the orthogonal sequence.

[0088] In some implementations, the UE may perform OCC hopping for the repetitions. The UE may apply the first OCC for the first set of repetitions and a second OCC for a second of repetitions and so on. The UE may determine the OCC for the repetitions based on at least one of the followings: the time resource, e.g., symbol / slot / subframe / frame index, for one of the repetitions within the K repetition, e.g., the first repetition; an identification (ID) for OCC hopping pattern configuration; candidate OCC for OCC hopping; OCC for the first set of repetitions. The network entity may configure whether to enable the OCC hopping or not by RRC signaling, MAC CE or DCI. The ID for OCC hopping pattern configuration, candidate OCC for OCC hopping and / or OCC for the first OCC group may be predefined or configured by the network entity via RRC signaling, MAC CE, or DCI.

[0089] FIG. 10 is an example 1000 for the OCC hopping for different sets of repetitions according to an embodiment. Referring to Fig. 10, a UE transmits a repetition of a first OCC group 1002 (e.g., PUSCH repetition with OCC for hop 1) based on a first OCC {1, 1, -1, -1} ; and the UE transmits a repetition of a second OCC group 1004 (e.g., PUSCH repetition with OCC for hop 2) based on a second OCC {1, -1, 1, -1} .

[0090] In an embodiment, the network entity may configure the UE to transmit different PUSCH symbols by different OCCs. The network entity may configure the OCC from a list of pre-defined or configured OCCs and / or the OCC length (K) for the PUSCH transmission. The UE transmits each PUSCH symbol based on the configured OCC including or excluding the DMRS for the PUSCH, including or excluding the PT-RS for the PUSCH. The UE transmits the same signal prior to applying the OCC on the same subcarrier in every K PUSCH symbols including or excluding the DMRS symbols, including or excluding the PT-RS for the PUSCH. The network entity and UE may determine the REs in an OCC group based on the symbol index. In one example, an OCC group can also indicate a code division multiplexing (CDM) group.

[0091] In some implementations, the network entity may configure the number of symbols for a PUSCH repetition as one or multiple of the OCC length. In some other implementations, the network entity may configure the number of OCC groups and the number of symbols for a PUSCH repetition. Then the UE may determine the OCC length based on the configured number of OCC groups and the number of symbols for a PUSCH repetition. In some other implementations, the network entity may configure the number of OCC groups and the OCC length, and the UE may determine the number of symbols based on the configured number of OCC groups and the OCC length.

[0092] FIG. 11 is an example 1100 for the symbol level OCC for PUSCH transmission with OCC = {1, -1} according to an embodiment.

[0093] Referring to FIG. 11, OCC {1, -1} is used for the PUSCH transmission and xm, n indicates the pre-coded PUSCH complex-valued symbol to be mapped to subcarrier m and the symbol in the OCC group n, and every 2 symbols in FIG. 11 indicates one OCC group. In one example, the network entity and the UE may determine the OCC group index as l mod K, where l indicates the symbol index within a PUSCH repetition or slot. As shown in FIG. 11, for OCC group 0 1102, X0 is transmitted for the first symbol 1104 of the first subcarrier, and -X0 is transmitted for the second symbol 1106 of the first subcarrier.

[0094] In some other implementations, if the number of symbols for a PUSCH repetition is not one or multiple of the OCC length, the UE may drop the whole PUSCH repetition or drop the PUSCH symbols that cannot be mapped to a completed OCC group or transmit the same signal as another OCC group, such as, previous OCC group or next OCC group.

[0095] FIG. 12 is an example 1200 for orphan PUSCH symbols for an OCC group according to an embodiment.

[0096] In some implementations, the network entity may transmit the configuration configuring whether the UE should drop the whole PUSCH repetition or drop the PUSCH symbols that cannot be mapped to a completed OCC group or transmit the same signal as another OCC group.

[0097] Referring to FIG. 12, the OCC group k 1202 includes REs for data in an orphan symbol and unused REs. For example, for one OCC group, such as OCC group k 1202, there is only one symbol 1204 and there is no symbol 1206 for the PUSCH transmission. Because the OCC group k 1202 includes REs for data in an orphan symbol, the UE drops the PUSCH symbols that cannot be mapped to a completed OCC group. Accordingly, the UE may determine the REs on the PUSCH symbols that cannot be mapped to a completed OCC group are not available for PUSCH rate matching.

[0098] In some implementations, the UE may perform OCC hopping for different OCC groups. The UE may apply a first OCC for a first OCC group and a second OCC for a second OCC group and so on. The UE may determine the OCC for an OCC group based on at least one of the followings: the OCC group index; the time resource, e.g., first / last symbol / slot / subframe / frame index, for the OCC group; an ID for OCC hopping pattern configuration; candidate OCC for OCC hopping; OCC for the first OCC group. The network entity may configure whether to enable the OCC hopping or not by RRC signaling, MAC CE, or DCI. The ID for OCC hopping pattern configuration, candidate OCC for OCC hopping and / or OCC for the first OCC group may be predefined or configured by the network entity via RRC signaling, MAC CE, or DCI.

[0099] In some implementations, when calculating the number of REs used for the data transmission to determine the rate matching for data and / or the bit per RE (BPRE) for uplink power control (e.g., power control factor ΔTF, b, f, c (i) as defined in 3GPP TS 38.213, section 7.1.1) , the network entity and UE may determine the number of REs  for a PUSCH repetition or transmission occasion in a bandwidth part (BWP) in a serving cell based on the number of subcarriers in one symbol within an OCC group and the number of OCC groups as equation (7) or (8) :

[0100] Where N indicates the number of slots for the PUSCH repetition or transmission occasion;  indicates the number of RBs for the PUSCH repetition or transmission occasion;  indicates the number of subcarriers per RB for a symbol within OCC group j used for the PUSCH repetition or transmission occasion which may include or exclude the subcarrier used for DMRS and / or phase tracking reference signal (PT-RS) ; G indicates the number of OCC groups for the PUSCH repetition or transmission occasion.

[0101] In some other implementations, when calculating the number of REs used for the BPRE calculation for uplink power control (e.g., power control factor ΔTF, b, f, c (i) as defined in 3GPP TS 38.213, section 7.1.1) , the network entity and UE may determine the number of REs for a PUSCH repetition or transmission occasion in a bandwidth part (BWP) in a serving cell based on the number of subcarriers in one symbol used for PUSCH transmission excluding DMRS and / or PT-RS and the number of symbols for PUSCH transmission. In one example, the network entity and UE may determine the number of REs as NRE.

[0102] In one example, the UE determines the power control factor where Ks=1.25 and ΔTF, b, f, c (i) =0 for Ks=0 where Ks is provided by deltaMCS for each UL BWP b of each carrier f and serving cell c. If the PUSCH transmission is over more than one layer, ΔTF, b, f, c (i) =0. is 1 when the PUSCH includes the data and when the PUSCH includes CSI but does not include data. For PUSCH with data,  or where C is the number of code blocks for the transport block (TB) on PUSCH, and Kr is the size of code block r.

[0103] The UE determines the transmission power for the PUSCH in active uplink BWP b, carrier f of serving c at transmission occasion i, power control parameter j, pathloss qd and closed-loop power adjustment state l as follows, where the variables other than ΔTF, b, f, c (i) are defined in 3GPP TS 38.213, section 7.1.1.

[0104] In an embodiment, the network entity may configure the UE to transmit different PUSCH REs or different complex-valued symbols before transform precoder by different OCC. The network entity may configure the OCC from a list of pre-defined or configured OCCs and / or the OCC length (K) in frequency-domain (FD) and / or time-domain (TD) for the PUSCH transmission. The UE transmits each PUSCH REs or different complex-valued symbols before transform precoder based on the configured OCC including or excluding the DMRS for the PUSCH, including or excluding the PT-RS REs or symbols for the PUSCH. The UE transmits the same signal prior to applying the OCC on the REs or complex-valued symbols before transform precoder for an OCC group including or excluding the DMRS REs, including or excluding the PT-RS REs or symbols for the PUSCH. The network entity and UE may determine the REs in an OCC group based on the subcarrier index and / or symbol index. The network entity and UE may determine the complex-valued symbols before transform precoder in an OCC group based on the index of the complex-valued symbols within all the complex-valued symbols for one transform precoder, including or excluding the PT-RS symbols for the transform precoder.

[0105] In some implementations, the network entity may refrain from configuring the PUSCH transmission with orphan REs for an OCC group. Thus, the UE shall not expect the network entity configure the PUSCH transmission with orphan REs for an OCC group. The number of REs in an OCC group should be the same as the OCC length in time and / or frequency domain. In some other implementations, if the network entity configures the PUSCH transmission with orphan REs for an OCC group, the UE may drop the whole PUSCH transmission or drop the PUSCH on the REs in the OCC group or determine the REs in the OCC group as not available for PUSCH rate matching or transmit the PUSCH based on the available REs for the OCC group or transmit the same signal as another OCC group, e.g., previous OCC  group or next OCC group. The network entity may configure whether the UE should drop the whole PUSCH transmission or drop the PUSCH on the REs in the OCC group or determine the REs in the OCC group as not available for PUSCH rate matching or transmit the PUSCH based on the available REs for the OCC group or transmit the same signal as another OCC group.

[0106] In some implementations, for FD-OCC, when transform precoder is enabled, the UE may perform the OCC after transform precoder (post-DFT OCC) or before transform precoder (pre-DFT OCC) . For post-DFT OCC, one OCC group in FD may comprise continuous or discontinuous subcarriers. For pre-DFT OCC, one OCC group may comprise continuous or discontinuous complex-valued symbols before transform precoder. For pre-DFT OCC, the FD-OCC can be replaced by the symbol-domain (SD) -OCC. For per-DFT OCC, the network entity and UE may determine one OCC group should include or exclude the PT-RS. The UE may apply the OCC on PUSCH only (excluding PT-RS) , or the UE may apply the OCC to both PUSCH and PT-RS.

[0107] FIG. 13 is an example 1300 for the RE level OCC for PUSCH transmission with OCC = {1, 1} based on post-DFT FD-OCC-2 and OCC {1, -1} based on TD-OCC-2 by frequency-first OCC group indexing according to an embodiment.

[0108] In this example, xn indicates the pre-coded PUSCH complex-valued symbol to be mapped to OCC group n. The network entity and UE may determine the OCC group index in a frequency first or time first manner. The total OCC length is 4. TD-OCC 1302 is denoted by {1-1} and the FD-OCC 1304 is denoted by {1, 1} . The PUSCH is transmitted using four REs with two different OCCs.

[0109] FIG. 14 is an example 1400 for the complex-valued symbol level OCC for PUSCH transmission with OCC = {1, 1} based on pre-DFT FD-OCC-2 according to an embodiment.

[0110] Complex-valued symbol of the UCI 1402 is mapped to OCC group 1406 before a DFT operation 1404. After the DFT operation 1404, the PUSCH transmission is transmitted using different signals in different REs.

[0111] In some implementations, a network entity transmits, to a UE, an OCC configuration, where the configuration includes an OCC indication associates with a predefined orthogonal sequence. Then the network entity schedules the UE to transmit a PUSCH transmission by a scheduling DCI. According to the OCC configuration  and the scheduling DCI, the UE performs RE-based repetition in each RB and then applies OCC to the RE repetitions in each RB.

[0112] FIG. 15 is an example 1500 for the RE based OCC per RB, (a) OCC = {1, -1} with a block-wise repetition; (b) OCC = {1, -1} with interlaced repetition; (c) OCC={1, -1, 1, -1} with block-wise repetition; (d) OCC = {1, -1, 1, -1} with interlaced repetition.

[0113] Referring to FIG. 15 (a) , the configured OCC is {1, -1} with a length of 2. The UE splits the REs in the RB 1506 into two blocks, for example, the first RE block 1502 {RE0, RE1, RE2, RE3, RE4, RE5} and the second RE block 1504 {RE6, RE7, RE8, RE9, RE10, RE11} . According to the first code in the configured OCC (referring to {1} ) , the UE allocates modulated data {X0, X1, X2, X3, X4, X5} to the first RE block 1502, and allocates the repetition {-X0, -X1, -X2, -X3, -X4, -X5} with the second code in the configured OCC (refer to {-1} ) to the second RE block 1504.

[0114] Referring to FIG. 15 (b) , the configured OCC is {1, -1} , with a length of 2. As shown, the UE splits the REs in the RB 1508 into two interlaces. The first RE interlace is 1510 {RE0, RE2, RE4, RE6, RE8, RE10} and the second RE interlace 1512 {RE1, RE3, RE5, RE7, RE9, RE11} . According to the first code in the configured OCC (referring to {1} ) , the UE allocates modulated data 1514 {X0, X1, X2, X3, X4, X5} to the first RE interlace 1510, and allocates the repetition 1516 {-X0, -X1, -X2, -X3, -X4, -X5} with the second code in the configured OCC (referring to {-1} ) to the second RE interlace 1512.

[0115] Referring to FIG. 15 (c) , the configured OCC is {1, -1, 1, -1} with a length of 4. The UE splits the REs in the RB 1518 into four blocks, for example, the first RE block 1520 {RE0, RE1, RE2} , the second RE block 1522 {RE3, RE4, RE5} , the third RE block 1524 {RE6, RE7, RE8} , and the fourth RE block 1526 {RE9, RE10, RE11} . According to the first code in the configured OCC (referring to {1} ) , the UE allocates modulated data {X0, X1, X2} to the first RE block 1520, allocates the repetition {-X0, -X1, -X2} with the second code in the configured OCC (refer to {-1} ) to the second RE block 1522, allocates the repetition {X0, X1, X2} with the third code in the configured OCC (refer to {1} ) to the third RE block 1524, and allocates the repetition {-X0, -X1, -X2} with the fourth code in the configured OCC (refer to {-1} ) to the second RE block 1526 .

[0116] Referring to FIG. 15 (d) , the configured OCC is {1, -1, 1, -1} with a length of 4. The UE divides the RB 1540 into 4 RE blocks 1542, 1544, 1546, 1548 and interlaces.  This configuration generates 4 repetitions of modulated data {X0, X1, X2} , and applies OCC to repetitions in each RB.

[0117] In some implementations, instead of using the OCC configuration to indicate the orthogonal sequence of OCC, the network entity uses the scheduling DCI or MAC CE to indicate the orthogonal sequence of OCC to the UE.

[0118] In some implementations, the UE may perform OCC hopping for different OCC groups. The UE may apply a first OCC for a first OCC group and a second OCC for a second OCC group and so on. The UE may determine the OCC for an OCC group based on at least one of the followings: the OCC group index; the frequency resource, e.g., first / last subcarrier / RB index for an OCC group; the index of the complex-valued symbols after precoder and before transform precoder for the OCC group; the time resource, e.g., first / last symbol / slot / subframe / frame index, for the OCC group; an ID for OCC hopping pattern configuration; candidate OCC for OCC hopping; OCC for the first OCC group. The network entity may configure whether to enable the OCC hopping or not by RRC signaling, MAC CE or DCI. The ID for OCC hopping pattern configuration, candidate OCC for OCC hopping and / or OCC for the first OCC group may be predefined or configured by the network entity via RRC signaling, MAC CE or DCI. The UE may perform the OCC hopping in TD and FD jointly or separately. The network entity may configure the OCC hopping in TD and FD jointly or separately.

[0119] In some implementations, when calculating the number of REs used for the data transmission to determine the rate matching for data and / or the bit per RE (BPRE) for uplink power control (e.g., power control factor ΔTF, b, f, c (i) as defined in 3GPP TS 38.213, section 7.1.1) , the network entity and UE may determine the number of REs for a PUSCH repetition or transmission occasion in a bandwidth part (BWP) in a serving cell based on the number of subcarriers in one symbol within an OCC group and the number of OCC groups as equation (9) or (10) : NRE"=NG              (10)

[0120] where KTD indicates the OCC length in TD; KFD indicates the OCC length in TD; indicates the number of symbols for the PUSCH repetition or transmission occasion;  indicates the number of subcarriers per RB for the symbol l used for the PUSCH repetition or transmission occasion which may include or exclude the subcarrier used for DMRS and / or phase tracking reference signal (PT-RS) ; G indicates the number of OCC groups for the PUSCH repetition or transmission occasion.

[0121] In some other implementations, when calculating the number of REs used for the BPRE calculation for uplink power control (e.g., power control factor ΔTF, b, f, c (i) as defined in 3GPP TS 38.213, section 7.1.1) , the network entity and the UE may determine the number of REs for a PUSCH repetition or transmission occasion in a bandwidth part (BWP) in a serving cell based on the number of subcarriers in one symbol used for PUSCH transmission excluding DMRS and / or PT-RS and the number of symbols for PUSCH transmission. In one example, the network entity and UE may determine the number of REs as NRE.

[0122] In one example, the UE determines the power control factor where Ks=1.25 and ΔTF, b, f, c (i) =0 for Ks=0 where Ks is provided by deltaMCS for each UL BWP b of each carrier f and serving cell c. If the PUSCH transmission is over more than one layer, ΔTF, b, f, c (i) =0. is 1 when the PUSCH includes the data and when the PUSCH includes CSI but does not include data. For PUSCH with data,  where C is the number of code blocks for the transport block (TB) on PUSCH, and Kr is the size of code block r.

[0123] In an embodiment, the network entity may configure OCC granularity for the PUSCH transmission by RRC signaling, MAC CE, or DCI. In one example, the OCC granularity may be configured or indicated by the uplink grant configured by the RRC signaling or DCI. In another example, the OCC granularity may be indicated by the MAC CE activating the semi-persistent CSI report.

[0124] In some implementations, the network entity may configure one OCC granularity, e.g., repetition level or symbol level or RE level, for the PUSCH transmission. In some other implementations, the network entity may configure multiple OCC granularities (e.g., PUSCH repetition level, symbol level, or RE  level) . Then the UE may apply one OCC for different repetitions and the same or another OCC for different symbols or REs within a repetition. The UE may report the UE capability indicating whether it supports multiple OCC granularities.

[0125] In an embodiment, for the PUSCH with repetition level OCC configured, the UE may transmit the UCI on X PUSCH repetitions. The X PUSCH repetitions may correspond to the same beam, e.g., the same TCI state. The value of X may be predefined, e.g., based on the number of PUSCH repetitions or based on the OCC length, or configured by the network entity by RRC signaling, MAC CE, or DCI, or reported by the UE (e.g., by UE capability or another RRC message (e.g., UE assistance information) , or MAC CE, or another UCI) .

[0126] For PUSCH repetitions from multiple beams, e.g., multiple TCI states, the network entity may configure a common or separate value of X for each beam.

[0127] The UE may transmit the complex-valued symbol of the UCI after precoder repeatedly in each PUSCH repetition with UCI multiplexed. The UE transmit the UCI at the same REs in different PUSCH repetitions. The PUSCH repetitions may correspond to the same TCI state.

[0128] The starting PUSCH repetition for the X PUSCH repetitions may be pre-defined, e.g., the first PUSCH repetition, or configured by the network entity by RRC signaling, MAC CE, or DCI, or determined based on the location of the PUCCH for the UCI report and / or the minimum processing delay for the UCI feedback which may be predefined or reported by the UE capability or configured by the network entity. In one example, the starting PUSCH repetition is the first PUSCH repetition in the same slot as the PUCCH for the UCI report.

[0129] FIG. 16 is an example 1600 for the UCI multiplexing on X PUSCH repetitions with X = K (OCC length) . Referring to FIG. 16, the configured OCC 1606 is {1, 1, -1, -1} with a length of 4. The UCI is transmitted on four repetitions according to the length of the code. For example, the UCI is transmitted on the first four repetitions 1602 with OCC, and the UCI is not transmitted on the second four repetitions 1604 with OCC.

[0130] In some implementations, if the number of REs for the UCI transmission in different repetitions are different, the UE may drop the UCI on a PUSCH repetition based on a different number of REs / symbols for PUSCH compared to a reference PUSCH repetition, e.g., the first PUSCH repetition or the PUSCH repetition with minimum number of REs or symbols, or drop the whole PUSCH transmission, or drop  the UCI, or transmit the UCI on the PUSCH repetitions based on the available REs or symbols as the reference PUSCH repetition, or transmit the UCI on the next PUSCH repetition based on the same number of REs as the reference PUSCH repetition or still transmit the PUSCH repetitions. Alternatively, the network entity may configure whether the UE should drop the UCI on a PUSCH repetition based on a different number of REs / symbols for PUSCH compared to a reference PUSCH repetition, e.g., the first PUSCH repetition or the PUSCH repetition with minimum number of REs or symbols, or drop the whole PUSCH transmission, or drop the UCI, or transmit the UCI on the PUSCH repetitions based on the available REs or symbols as the reference PUSCH repetition, or transmit the UCI on the next PUSCH repetition based on the same number of REs as the reference PUSCH repetition or still transmit the PUSCH repetitions.

[0131] In some implementations, the UE may transmit the PUSCH repetitions with the UCI repetitions based on the same transmission power, e.g., the transmission power that the UE determined for the first PUSCH repetition or transmission occasion.

[0132] In some implementations, when calculating the BPRE for uplink power control for PUSCH with CSI only, e.g., PUSCH without data, the UE may determine the BPRE based on the modulation order, coding rate for PUSCH, beta offset for CSI part 1 or CSI part 2, and the number of repetitions or the OCC length. In one example, the UE may determine the BPRE as follows:

[0133] In another example, the UE may determine the BPRE as follows:

[0134] Where

[0135] In an embodiment, for the PUSCH with symbol level OCC configured, the UE may transmit one complex-valued symbol of the UCI after precoder in one subcarrier on in Y symbols. The value of Y may be based on the OCC length for the data or  based on an OCC length configured for UCI. The network entity may configure a common OCC or separate OCCs for data and UCI.

[0136] FIG. 17 is an example 1700 for UCI multiplexing on symbol-level OCC based PUSCH with OCC = {1, -1} . Um, n indicates the precoded PUSCH complex-valued symbol for UCI to be mapped to subcarrier m and the symbol in the OCC group n, and every 2 symbols in FIG. 17 indicates one OCC group. Referring to FIG. 17, different OCC may be applied to the UCI and the data. OCC group 0 1704 is applied to the UCI 1702. The same OCC is applied to the UCI 1702.

[0137] In some implementations, when calculating the number of coded bits for UCI, the network entity and UE may determine the number of REs for the PUSCH transmission based on equation (7) or (8) , e.g., NRE′. Then, the network entity and the UE may determine number of REs for HARQ-ACK QHARQ-ACK, number of REs for CSI part 1 QCSI-part1, number of REs for CSI part 2 QCSI-part2 as follows:

[0138] When calculating the BPRE for uplink power control for PUSCH with CSI only, e.g., PUSCH without data, the UE may determine the BPRE based on the modulation order, coding rate for PUSCH, beta offset for CSI part 1 or CSI part 2, and the OCC length. In one example, the UE may determine the BPRE as follows:

[0139] Where

[0140] In an embodiment, for the PUSCH with RE level OCC configured, the UE may transmit one complex-valued of the UCI after precoder in the REs in one OCC group. The number of REs in one OCC group for UCI may be based on the number of REs  in one OCC group for data or based on the number of REs in one OCC group configured for UCI. The network entity may configure a common or separate number of REs in one OCC for data and UCI. The network entity may configure the TD-OCC length and / or FD-OCC length for UCI by RRC signaling, MAC CE or DCI.

[0141] FIG. 18 is an example 1800 for the RE level OCC for PUSCH transmission with OCC = {1, 1} based on FD-OCC-2 and OCC= {1, -1} based on TD-OCC-2 for data and OCC= {1, 1, 1, 1} based on FD-OCC-4 and OCC= {1, -1} based on TD-OCC-2 for UCI. Un indicates the precoded UCI complex-valued symbol to be mapped to OCC group n. The network entity and the UE may determine the OCC group index in a frequency first or time first manner. Referring to FIG. 18, UCI 1802 indicates the precoded UCI complex-valued symbol to be mapped to OCC group 1804.

[0142] In some implementations, the UE performs RE-based OCC per RB to the UCI as the method in FIG. 15, and then multiplexes the UCI to the front of the PUSCH transmission. In some implementations, the UE uses the same or different OCC methods to the UCI and PUSCH transmission. In one example, the UE applies RE-based OCC per RB to UCI and PUSCH transmission. In another example, the UE applies RE-based OCC per RB to UCI, and applies repetition-level PUSCH OCC to the PUSCH. In this case, the UE does not perform slot level repetition to the UCI. In some implementations, the UE applies the same or different orthogonal sequence (OCC) to the UCI and the PUSCH transmission.

[0143] In some implementations, when calculating the number of coded bits for UCI, the network entity and UE may determine the number of REs for the PUSCH transmission based on equation (9) or (10) , e.g., NRE". Then the network entity and UE may determine number of REs for HARQ-ACK QHARQ-ACK, number of REs for CSI part 1 QCSI-aart1, number of REs for CSI part 2 QCSI-part2 as follows:

[0144] When calculating the BPRE for uplink power control for PUSCH with CSI only, e.g., PUSCH without data, the UE may determine the BPRE based on the modulation order, coding rate for PUSCH, beta offset for CSI part 1 or CSI part 2, and the OCC length in FD (KFD) and / or the OCC length in TD (KTD) . In one example, the UE may determine the BPRE as follows:

[0145] Where

[0146] FIGs. 19-20 show methods for implementing one or more aspects of FIGs. 2-18.

[0147] In particular, FIG. 19 shows an implementation by the UE 102 of the one or more aspects of FIGs. 2-18. FIG. 20 shows an implementation by the network entity 104 of the one or more aspects of FIGs. 2-18.

[0148] FIG. 19 illustrates a flowchart 1900 of a method of wireless communication at a UE. With reference to FIGs. 1-18 the method may be performed by the UE 102. In embodiments, the UE 102 may transmit 1902, to the network entity 104, a UE capability report indicating UE capability on the supported configuration for the PUSCH based on OCC and / or the supported configuration for the UCI multiplexing on PUSCH based on OCC. For example, referring to FIG. 4, the UE 102 transmits 402, to a network entity 104, UE capability report indicating UE capability on the supported configuration for the PUSCH based on OCC and / or the supported configuration for the UCI multiplexing on PUSCH based on OCC.

[0149] In embodiments, the UE 102 receives 1904, from the network entity 104, an OCC, configuration indicating an OCC for a PUSCH transmission and a UCI multiplexing scheme. For example, referring to FIG. 4, the UE 102 receives, from the network entity 104, control signaling configuring at least one of: configuration of OCC for PUSCH; configuration of the PUSCH waveform; configuration of UCI multiplexing on PUSCH based on OCC, and optionally configuring an uplink grant for PUSCH transmission based on OCC and configured waveform, and / or a PUCCH resource for CSI feedback.

[0150] In embodiments, the UE 102 may receive 1906, from the network entity 104, DCI that triggers the OCC configuration or a medium access control, MAC CE, that activates the OCC configuration. For example, referring to FIG. 4, the UE 102 may  receive, from the network entity 104, MAC CE activating semi-persistent CSI feedback on PUSCH; or DCI) triggering aperiodic CSI on PUSCH; or DCI triggering a PUSCH transmission overlapping with a PUCCH in time domain.

[0151] In embodiments, the UE 102 transmits 1908, to the network entity 104, the PUSCH transmission based on the OCC and with the UCI multiplexed on the PUSCH transmission based on the UCI multiplexing scheme. For example, referring to FIG. 4, the UE transmits 408, to the network entity 104 the PUSCH based on OCC and UCI multiplexed on one or multiple PUSCH repetitions based on the determined UCI multiplexing scheme.

[0152] FIG. 19 describes a method from a UE-side of a wireless communication link, whereas FIG. 20 describes a method from a network-side of the wireless communication link.

[0153] FIG. 20 is a flowchart 2000 of a method of wireless communication at a network entity. With reference to FIGs. 1-18, the method may be performed by one or more network entities 104, which may correspond to a base station or a unit of the base station, such as the RU 106, the DU 108, and / or the CU 110.

[0154] In embodiments, the network entity 104 may receive 2002, from a UE 102, a UE capability report indicating UE capability on the supported configuration for the PUSCH based on OCC and / or the supported configuration for the UCI multiplexing on PUSCH based on OCC. For example, referring to FIG. 4, the network entity 104 receives, from the UE 102, UE capability report indicating UE capability on the supported configuration for the PUSCH based on OCC and / or the supported configuration for the UCI multiplexing on PUSCH based on OCC.

[0155] In embodiments, the network entity 104 transmits 2004, to the UE 102 an OCC configuration indicating an OCC for a PUSCH transmission and an UCI multiplexing scheme. For example, referring to FIG. 4, the network entity 104 transmits, to the UE 102, control signaling configuring at least one of: configuration of OCC for PUSCH; configuration of the PUSCH waveform; configuration of UCI multiplexing on PUSCH based on OCC, and optionally configuring an uplink grant for PUSCH transmission based on OCC and configured waveform, and / or a PUCCH resource for CSI feedback.

[0156] In embodiments, the network entity 104 may transmit 2006, to the UE 102, DCI that triggers the OCC configuration or a MAC CE that activates the OCC configuration. For example, referring to FIG. 4, the network entity may transmit 406,  to the UE (the UE may receive, from the network entity) , medium access control element (MAC CE) activating semi-persistent CSI feedback on PUSCH; or downlink control information (DCI) triggering aperiodic CSI on PUSCH; or DCI triggering a PUSCH transmission overlapping with a PUCCH in time domain.

[0157] In embodiments, the network entity 104 receives 2008, from the UE 102, the PUSCH transmission based on the OCC and with the UCI multiplexed on the PUSCH transmission based on the UCI multiplexing scheme. For example, referring to FIG. 4, the network entity receives from the UE) the PUSCH based on OCC and UCI multiplexed on one or multiple PUSCH repetitions based on the determined UCI multiplexing scheme.

[0158] A UE apparatus 2102, as described in FIG. 21, may perform the method of flowchart 1900. The one or more network entities 104, as described in FIG. 22, may perform the method of flowchart 2000.

[0159] FIG. 21 is a diagram 2100 illustrating an example of a hardware implementation for a UE apparatus 2102. The UE apparatus 2102 may be the UE 102, a component of the UE 102, or may implement UE functionality. The UE apparatus 2102 may include an application processor 2106, which may have on-chip memory 2106’ . In examples, the application processor 2106 may be coupled to a secure digital (SD) card 2108 and / or a display 2110. The application processor 2106 may also be coupled to a sensor (s) module 2112, a power supply 2114, an additional module of memory 2116, a camera 2118, and / or other related components.

[0160] The UE apparatus 2102 may further include a wireless baseband processor 2126, which may be referred to as a modem. The wireless baseband processor 2126 may have on-chip memory 2126'. Along with, and similar to, the application processor 2106, the wireless baseband processor 2126 may also be coupled to the sensor (s) module 2112, the power supply 2114, the additional module of memory 2116, the camera 2118, and / or other related components. The wireless baseband processor 2126 may be additionally coupled to one or more subscriber identity module (SIM) card (s) 2120 and / or one or more transceivers 2130 (e.g., wireless RF transceivers) .

[0161] Within the one or more transceivers 2130, the UE apparatus 2102 may include a Bluetooth module 2132, a WLAN module 2134, an SPS module 2136 (e.g., GNSS module) , and / or a cellular module 2138. The Bluetooth module 2132, the WLAN module 2134, the SPS module 2136, and the cellular module 2138 may each include an on-chip transceiver (TRX) , or in some cases, just a transmitter (TX) or just a  receiver (RX) . The Bluetooth module 2132, the WLAN module 2134, the SPS module 2136, and the cellular module 2138 may each include dedicated antennas and / or utilize antennas 2140 for communication with one or more other nodes. For example, the UE apparatus 2102 can communicate through the transceiver (s) 2130 via the antennas 2140 with another UE (e.g., sidelink communication) and / or with a network entity 104 (e.g., uplink / downlink communication) , where the network entity 104 may correspond to a base station or a unit of the base station, such as the RU 106, the DU 108, or the CU 110.

[0162] The wireless baseband processor 2126 and the application processor 2106 may each include a computer-readable medium  / memory 2126', 2106', respectively. The additional module of memory 2116 may also be considered a computer-readable medium  / memory. Each computer-readable medium  / memory 2126', 2106', 2116 may be non-transitory. The wireless baseband processor 2126 and the application processor 2106 may each be responsible for general processing, including execution of software stored on the computer-readable medium  / memory 2126', 2106', 2116. The software, when executed by the wireless baseband processor 2126  / application processor 2106, causes the wireless baseband processor 2126  / application processor 2106 to perform the various functions described herein. The computer-readable medium  / memory may also be used for storing data that is manipulated by the wireless baseband processor 2126  / application processor 2106 when executing the software. The wireless baseband processor 2126  / application processor 2106 may be a component of the UE 102. The UE apparatus 2102 may be a processor chip (e.g., modem and / or application) and include just the wireless baseband processor 2126 and / or the application processor 2106. In other examples, the UE apparatus 2102 may be the entire UE 102 and include the additional modules of the apparatus 2102.

[0163] As discussed in FIG. 1 and implemented with respect to FIG. 19, the UE UCI Multiplexing OCC component 140 is configured to receive, from a network entity, an OCC configuration indicating an OCC for a PUSCH transmission and an UCI multiplexing scheme; and to transmit, to the network entity, the PUSCH transmission based on the OCC and with the UCI multiplexed on the PUSCH transmission based on the UCI multiplexing scheme.

[0164] The UE UCI Multiplexing OCC component 140 may be within the application processor 2106 (e.g., at 140a) , the wireless baseband processor 2126 (e.g., at 140b) , or both the application processor 2106 and the wireless baseband processor 2126. The  UE UCI Multiplexing OCC component 140a-140b may be one or more hardware components specifically configured to carry out the stated processes / algorithm, implemented by one or more processors configured to perform the stated processes / algorithm, stored within a computer-readable medium for implementation by the one or more processors, or a combination thereof.

[0165] FIG. 22 is a diagram 2200 illustrating an example of a hardware implementation for one or more network entities 104. The one or more network entities 104 may be a base station, a component of a base station, or may implement base station functionality. The one or more network entities 104 may include, or may correspond to, at least one of the RU 106, the DU, 108, or the CU 110. The CU 110 may include a CU processor 2246, which may have on-chip memory 2246'. In some aspects, the CU 110 may further include an additional module of memory 2256 and / or a communications interface 2248, both of which may be coupled to the CU processor 2246. The CU 110 can communicate with the DU 108 through a midhaul link 162, such as an F1 interface between the communications interface 2248 of the CU 110 and a communications interface 2228 of the DU 108.

[0166] The DU 108 may include a DU processor 2226, which may have on-chip memory 2226'. In some aspects, the DU 108 may further include an additional module of memory 2236 and / or the communications interface 2228, both of which may be coupled to the DU processor 2226. The DU 108 can communicate with the RU 106 through a fronthaul link 160 between the communications interface 2228 of the DU 108 and a communications interface 2208 of the RU 106.

[0167] The RU 106 may include an RU processor 2206, which may have on-chip memory 2206'. In some aspects, the RU 106 may further include an additional module of memory 2216, the communications interface 2208, and one or more transceivers 2230, all of which may be coupled to the RU processor 2206. The RU 106 may further include antennas 2240, which may be coupled to the one or more transceivers 2230, such that the RU 106 can communicate through the one or more transceivers 2230 via the antennas 2240 with the UE 102.

[0168] The on-chip memory 2206', 2226', 2246'a nd the additional modules of memory 2216, 2236, 2256 may each be considered a computer-readable medium  / memory. Each computer-readable medium  / memory may be non-transitory. Each of the processors 2206, 2226, 2246 is responsible for general processing, including execution of software stored on the computer-readable medium  / memory. The  software, when executed by the corresponding processor (s) 2206, 2226, 2246 causes the processor (s) 2206, 2226, 2246 to perform the various functions described herein. The computer-readable medium  / memory may also be used for storing data that is manipulated by the processor (s) 2206, 2226, 2246 when executing the software. In examples, the NE UCI Multiplexing OCC component 150 may sit at any of the one or more network entities 104, such as at the CU 110; both the CU 110 and the DU 108; each of the CU 110, the DU 108, and the RU 106; the DU 108; both the DU 108 and the RU 106; or the RU 106.

[0169] As discussed in FIG. 1 and implemented with respect to FIG. 20, the NE UCI Multiplexing OCC component 150 is configured to transmit, to a UE, an OCC configuration indicating an OCC for a PUSCH transmission and an uplink control information, UCI, multiplexing scheme; and to receive, from the UE, the PUSCH transmission based on the OCC and with the UCI multiplexed on the PUSCH transmission based on the UCI multiplexing scheme.

[0170] The NE UCI Multiplexing OCC component 150 may be within one or more processors of the one or more network entities 104, such as the RU processor 2206 (e.g., at 150a) , the DU processor 2226 (e.g., at 150b) , and / or the CU processor 2246 (e.g., at 150c) . The NE UCI Multiplexing OCC component 150a-150c may be one or more hardware components specifically configured to carry out the stated processes / algorithm, implemented by one or more processors 2206, 2226, 2246 configured to perform the stated processes / algorithm, stored within a computer-readable medium for implementation by the one or more processors 2206, 2226, 2246, or a combination thereof.

[0171] The specific order or hierarchy of blocks in the processes and flowcharts disclosed herein is an illustration of example approaches. Hence, the specific order or hierarchy of blocks in the processes and flowcharts may be rearranged. Some blocks may also be combined or deleted. Dashed lines may indicate optional elements of the diagrams. The accompanying method claims present elements of the various blocks in an example order, and are not limited to the specific order or hierarchy presented in the claims, processes, and flowcharts.

[0172] The detailed description set forth herein describes various configurations in connection with the drawings and does not represent the only configurations in which the concepts described herein may be practiced. The detailed description includes specific details for the purpose of providing a thorough explanation of various  concepts. However, these concepts may be practiced without these specific details. In some instances, well known structures and components are shown in block diagram form in order to avoid obscuring such concepts.

[0173] Aspects of wireless communication systems, such as telecommunication systems, are presented with reference to various apparatuses and methods. These apparatuses and methods are described in the following detailed description and are illustrated in the accompanying drawings by various blocks, components, circuits, processes, call flows, systems, algorithms, etc. (collectively referred to as “elements” ) . These elements may be implemented using electronic hardware, computer software, or combinations thereof. Whether such elements are implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system.

[0174] An element, or any portion of an element, or any combination of elements may be implemented as a “processing system” that includes one or more processors. Examples of processors include microprocessors, microcontrollers, graphics processing units (GPUs) , central processing units (CPUs) , application processors, digital signal processors (DSPs) , reduced instruction set computing (RISC) processors, systems-on-chip (SoC) , baseband processors, field programmable gate arrays (FPGAs) , programmable logic devices (PLDs) , state machines, gated logic, discrete hardware circuits, and other similar hardware configured to perform the various functionality described throughout this disclosure. One or more processors in the processing system may execute software, which may be referred to as software, firmware, middleware, microcode, hardware description language, or otherwise. Software shall be construed broadly to mean instructions, instruction sets, code, code segments, program code, programs, subprograms, software components, applications, software applications, software packages, routines, subroutines, objects, executables, threads of execution, procedures, functions, or any combination thereof.

[0175] If the functionality described herein is implemented in software, the functions may be stored on, or encoded as, one or more instructions or code on a computer-readable medium, such as a non-transitory computer-readable storage medium. Computer-readable media includes computer storage media and can include a random-access memory (RAM) , a read-only memory (ROM) , an electrically erasable programmable ROM (EEPROM) , optical disk storage, magnetic disk storage, other magnetic storage devices, combinations of these types of computer-readable media, or any other  medium that can be used to store computer executable code in the form of instructions or data structures that can be accessed by a computer. Storage media may be any available media that can be accessed by a computer.

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

[0177] Devices incorporating the aspects and features described herein may also include additional components and features for the implementation and practice of the claimed and described aspects and features. For example, transmission and reception of wireless signals necessarily includes a number of components for analog and digital purposes, such as hardware components, antennas, RF-chains, power amplifiers, modulators, buffers, processor (s) , interleavers, adders / summers, etc. Techniques described herein may be practiced in a wide variety of devices, chip-level components, systems, distributed arrangements, aggregated or disaggregated components, end-user devices, etc., of varying configurations.

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

[0179] Reference to an element in the singular does not mean “one and only one” unless specifically stated, but rather “one or more. ” Terms such as “if, ” “when, ” and “while” do not imply an immediate temporal relationship or reaction. That is, these phrases, e.g., “when, ” do not imply an immediate action in response to or during the occurrence of an action, but simply imply that if a condition is met then an action will occur, but  without requiring a specific or immediate time constraint for the action to occur. The terms “may” , “might” , and “can” , as used in this disclosure, often carry certain connotations. For example, “may” refers to a permissible feature that may or may not occur, “might” refers to a feature that probably occurs, and “can” refers to a capability (e.g., capable of) . The phrase “For example” often carries a similar connotation to “may” and, therefore, “may” is sometimes excluded from sentences that include “for example” or other similar phrases.

[0180] Unless specifically stated otherwise, the term “some” refers to one or more. Combinations such as “at least one of A, B, or C” or “one or more of A, B, or C”include any combination of A, B, and / or C, such as A and B, A and C, B and C, or A and B and C, and may include multiples of A, multiples of B, and / or multiples of C, or may include A only, B only, or C only. Sets should be interpreted as a set of elements where the elements number one or more. Terms or articles such as “a” , “an” , and / or “the” may refer to one of an item, feature, element, etc., that the term or article precedes, or may refer to more than one of said item, feature, element, etc. that the term or article precedes. For example, the recitation “awidget” does not preclude reference to multiples of said widget, as “multiple widgets” necessarily includes “awidget” . Hence, the recitation “awidget” may be interpreted as “at least one widget” or, similarly, interpreted as “one or more widgets” .

[0181] Unless otherwise specifically indicated, ordinal terms such as “first” and “second” do not necessarily imply an order in time, sequence, numerical value, etc., but are used to distinguish between different instances of a term or phrase that follows each ordinal term.

[0182] Reference numbers, as used in the specification and figures, are sometimes cross-referenced among drawings to denote same or similar features. A feature that is exactly the same in multiple drawings may be labeled with the same reference number in the multiple drawings. A feature that is similar among the multiple drawings, but not exactly the same, may be labeled with reference numbers that have different leading numbers but have one or more of the same trailing numbers (e.g., 206, 306, 406, etc., may refer to similar features in the drawings) . Hence, like numbers may refer to like actions.

[0183] Structural and functional equivalents to elements of the various aspects described throughout this disclosure that are known or later come to be known to those of ordinary skill in the art are expressly incorporated herein by reference and are  encompassed by the claims. The words “module, ” “mechanism, ” “element, ” “device, ” and the like may not be a substitute for the word “means. ” As such, no claim element is to be construed as a means plus function unless the element is expressly recited using the phrase “means for. ” As used herein, the phrase “based on” shall not be construed as a reference to a closed set of information, one or more conditions, one or more factors, or the like. In other words, the phrase “based on A” , where “A” may be information, a condition, a factor, or the like, shall be construed as “based at least on A” unless specifically recited differently.

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

[0185] Example 1 is a method of wireless communication at a UE, including: receiving, from a network entity, an orthogonal cover code, OCC, configuration indicating an OCC for a physical uplink shared channel, PUSCH, transmission and an uplink control information, UCI, multiplexing scheme; and transmitting, to the network entity, the PUSCH transmission based on the OCC and with the UCI multiplexed on the PUSCH transmission based on the UCI multiplexing scheme.

[0186] Example 2 may be combined with Example 1 and further includes that the OCC configuration further indicates a granularity of the OCC as a repetition-level OCC, and at least one of: a number of repetitions for the PUSCH transmission, or an OCC length.

[0187] Example 3 may be combined with Example 1 and further includes that the OCC configuration further indicates a granularity of the OCC as a symbol-level OCC, and an OCC for a symbol associated with the PUSCH transmission.

[0188] Example 4 may be combined with Example 1 and further includes that the OCC configuration further indicates a granularity of the OCC as a resource element-level, RE-level OCC, and an OCC for an RE associated with the PUSCH transmission.

[0189] Example 5 may be combined with Example 1 and further includes receiving, from the network entity, downlink control information, DCI, that triggers the OCC configuration or a medium access control, MAC CE, that activates the OCC configuration.

[0190] Example 6 may be combined with Example 1 or 2 and further includes that the OCC configuration indicates the granularity of the OCC is at the repetition-level OCC and a number of repetitions for the PUSCH transmission; and further includes that the transmitting the PUSCH transmission includes transmitting, to the network entity, the  UCI multiplexed on the PUSCH transmission according to the number of repetitions for the PUSCH transmission.

[0191] Example 7 may be combined with Example 1 or 3 and further includes the OCC configuration indicates the granularity of the OCC is at the symbol-level OCC; and further includes that the transmitting the PUSCH transmission includes transmitting, to the network entity, a complex-valued symbol of the UCI in a subcarrier in a symbol in an OCC group.

[0192] Example 8 may be combined with Example 1 or 4 and further includes that the OCC configuration indicates the granularity of the OCC is at the RE-level OCC; and further includes that the transmitting the PUSCH transmission includes transmitting, to the network entity, a complex-valued symbol of the UCI in REs in an OCC group.

[0193] Example 9 may be combined with Example any Examples1-8, further includes transmitting, to the network entity, a UE capability report indicating support for at least one of: the PUSCH transmission based on the OCC; a granularity of the OCC; a maximum OCC length; a UCI multiplexing scheme; aperiodic channel state information, CSI, feedback multiplexing on the PUSCH transmission based on the OCC; a semi-persistent CSI feedback multiplexing on the PUSCH based on the OCC; the granularity of the OCC for the UCI multiplexed on the PUSCH transmission based on the OCC; a maximum OCC length for the UCI multiplexed on the PUSCH transmission based on the OCC; an OCC hopping scheme; or the OCC hopping scheme based on configured candidate OCCs.

[0194] Example 10 may be combined with any Examples 1-9 and further includes that the PUSCH transmission includes one or more repetitions of a PUSCH; and further includes that the transmitting the PUSCH transmission includes transmitting, to the network entity, the one or more repetitions of the PUSCH in one or more OCC groups based on a same transmission power.

[0195] Example 11 may be combined with Example 10 and further includes that the transmission power for the PUSCH is based on a bit per RE.

[0196] Example 12 may be combined with Example 4 or 8 and further includes that the RE associated with the one or more OCC group is based on a symbol index and a subcarrier index within each repetition.

[0197] Example 13 is a method of wireless communication at a network entity, the method including: transmitting, to a user equipment, UE, an orthogonal cover code, OCC, configuration indicating an OCC for a physical uplink shared channel, PUSCH,  transmission and an uplink control information, UCI, multiplexing scheme; and receiving, from the UE, the PUSCH transmission based on the OCC and with the UCI multiplexed on the PUSCH transmission based on the UCI multiplexing scheme.

[0198] Example 14 may be combined with Example 13 and further includes that the OCC configuration further indicates a granularity of the OCC as at least one of: a repetition-level OCC, a symbol-level OCC, or a resource-element, RE, -level OCC.

[0199] Example 15 may be combined with any Examples 13-14, and further includes that the receiving the PUSCH transmission includes receiving the UCI multiplexed on the PUSCH transmission based on at least one of: the repetition-level OCC, wherein the UCI is received according to a number of repetitions for the PUSCH transmission; the symbol-level OCC, wherein the UCI is received according to a complex-valued symbol of the UCI in a subcarrier in a symbol in an OCC group; or the RE-level OCC, wherein the UCI is received according to a complex-valued symbol of the UCI in REs in an OCC group.

[0200] Example 16 may be combined with Example 13 and further includes that the OCC configuration further indicates a granularity of the OCC as a repetition-level OCC, and at least one of: a number of repetitions for the PUSCH transmission, or an OCC length.

[0201] Example 17 may be combined with Example 13 and further includes that the OCC configuration further indicates a granularity of the OCC as a symbol-level OCC, and an OCC for a symbol associated with the PUSCH transmission.

[0202] Example 18 may be combined with Example 13 and further includes that the OCC configuration further indicates a granularity of the OCC as a resource element-level, RE-level OCC, and an OCC for an RE associated with the PUSCH transmission.

[0203] Example 19 may be combined with Example 13 and further includes transmitting, to the UE, downlink control information, DCI, that triggers the OCC configuration or a medium access control, MAC CE, that activates the OCC configuration.

[0204] Example 20 may be combined with Example 13-15 and further includes that the OCC configuration indicates the granularity of the OCC is at the repetition-level OCC and a number of repetitions for the PUSCH transmission; wherein the receiving the PUSCH transmission includes receiving, from the UE, the UCI multiplexed on the PUSCH transmission according to the number of repetitions for the PUSCH transmission.

[0205] Example 21 may be combined with Example 13 or 18 and further includes the OCC configuration indicates the granularity of the OCC is at the symbol-level OCC; and further includes that the receiving the PUSCH transmission includes receiving, from the UE, a complex-valued symbol of the UCI in a subcarrier in a symbol in an OCC group.

[0206] Example 22 may be combined with Example 13 or 19 and further includes that the OCC configuration indicates the granularity of the OCC is at the RE-level OCC; and further includes that the receiving the PUSCH transmission includes receiving, from the UE, a complex-valued symbol of the UCI in REs in an OCC group.

[0207] Example 23 may be combined with any Example 13-22 and further includes receiving, from the UE, a UE capability report indicating support for at least one of: the PUSCH transmission based on the OCC; a granularity of the OCC; a maximum OCC length; a UCI multiplexing scheme; aperiodic channel state information, CSI, feedback multiplexing on the PUSCH transmission based on the OCC; a semi-persistent CSI feedback multiplexing on the PUSCH based on the OCC; the granularity of the OCC for the UCI multiplexed on the PUSCH transmission based on the OCC; a maximum OCC length for the UCI multiplexed on the PUSCH transmission based on the OCC; an OCC hopping scheme; or the OCC hopping scheme based on configured candidate OCCs.

[0208] Example 24 may be combined with any Example 13-23 and further includes that the PUSCH transmission includes one or more repetitions of a PUSCH; and further includes that the receiving the PUSCH transmission includes: receiving, from the UE, the one or more repetitions of the PUSCH in one or more OCC groups based on a same transmission power.

[0209] Example 25 may be combined with Example 15 or 22 and further includes that the transmission power for the PUSCH is based on a bit per RE.

[0210] Example 26 is an apparatus for wireless communication for implementing a method as in any of examples 1-25.

[0211] Example 27 is an apparatus for wireless communication including means for implementing a method as in any of examples 1-25.

[0212] Example 28 is a non-transitory computer-readable medium storing computer executable code, the code when executed by a processor causes the processor to implement a method as in any of examples 1-25.

Claims

1.A method of wireless communication at a user equipment, UE, (102) , the method comprising:receiving (404) , from a network entity (104) , an orthogonal cover code, OCC, configuration indicating an OCC for a physical uplink shared channel, PUSCH, transmission and an uplink control information, UCI, multiplexing scheme; andtransmitting (408) , to the network entity (104) , the PUSCH transmission based on the OCC and with the UCI multiplexed on the PUSCH transmission based on the UCI multiplexing scheme.2.The method of claim 1, wherein the OCC configuration further indicates a granularity of the OCC as a repetition-level OCC, and at least one of:a number of repetitions for the PUSCH transmission, oran OCC length.3.The method of claim 1, wherein the OCC configuration further indicates a granularity of the OCC as a symbol-level OCC, and an OCC for a symbol associated with the PUSCH transmission.4.The method of claim 1, wherein the OCC configuration further indicates a granularity of the OCC as a resource element-level, RE-level OCC, and an OCC for an RE associated with the PUSCH transmission.5.The method of claim 1, further comprising:receiving (406) , from the network entity (104) , downlink control information, DCI, that triggers the OCC configuration or a medium access control, MAC CE, that activates the OCC configuration.6.The method of claim 1 or 2, wherein the OCC configuration indicates the granularity of the OCC is at the repetition-level OCC and a number of repetitions for the PUSCH transmission;wherein the transmitting the PUSCH transmission comprises transmitting (408) , to the network entity (104) , the UCI multiplexed on the PUSCH transmission according to the number of repetitions for the PUSCH transmission.7.The method of claim 1 or 3, wherein the OCC configuration indicates the granularity of the OCC is at the symbol-level OCC;wherein the transmitting the PUSCH transmission comprises transmitting (408) , to the network entity (104) , a complex-valued symbol of the UCI in a subcarrier in a symbol in an OCC group.8.The method of claim 1 or 4, wherein the OCC configuration indicates the granularity of the OCC is at the RE-level OCC;wherein the transmitting the PUSCH transmission comprises transmitting (408) , to the network entity (104) , a complex-valued symbol of the UCI in REs in an OCC group.9.The method of any claims 1-8, further comprising:transmitting (402) , to the network entity (104) , a UE capability report indicating support for at least one of:the PUSCH transmission based on the OCC;a granularity of the OCC;a maximum OCC length;a UCI multiplexing scheme;aperiodic channel state information, CSI, feedback multiplexing on the PUSCH transmission based on the OCC;a semi-persistent CSI feedback multiplexing on the PUSCH based on the OCC;the granularity of the OCC for the UCI multiplexed on the PUSCH transmission based on the OCC;a maximum OCC length for the UCI multiplexed on the PUSCH transmission based on the OCC;an OCC hopping scheme; orthe OCC hopping scheme based on configured candidate OCCs.10.The method of any claims 1-9, wherein the PUSCH transmission includes one or more repetitions of a PUSCH;wherein the transmitting the PUSCH transmission comprises:transmitting (408) , to the network entity (104) , the one or more repetitions of the PUSCH in one or more OCC groups based on a same transmission power.11.The method of claim 10, wherein the transmission power for the PUSCH is based on a bit per RE.12.The method of claim 4 or 8, wherein the RE associated with the one or more OCC group is based on a symbol index and a subcarrier index within each repetition.13.A method of wireless communication at a network entity (104) , the method comprising:transmitting (404) , to a user equipment, UE, (102) , an orthogonal cover code, OCC, configuration indicating an OCC for a physical uplink shared channel, PUSCH, transmission and an uplink control information, UCI, multiplexing scheme; andreceiving (408) , from the UE (102) , the PUSCH transmission based on the OCC and with the UCI multiplexed on the PUSCH transmission based on the UCI multiplexing scheme.14.The method of claim 13, wherein the OCC configuration further indicates a granularity of the OCC as at least one of:a repetition-level OCC,a symbol-level OCC, ora resource-element, RE, -level OCC.15.The method of any claims 13-14, wherein the receiving the PUSCH transmission comprises:receiving the UCI multiplexed on the PUSCH transmission based on at least one of:the repetition-level OCC, wherein the UCI is received according to a number of repetitions for the PUSCH transmission;the symbol-level OCC, wherein the UCI is received according to a complex-valued symbol of the UCI in a subcarrier in a symbol in an OCC group; orthe RE-level OCC, wherein the UCI is received according to a complex-valued symbol of the UCI in REs in an OCC group.16.An apparatus for wireless communication comprising a memory, a transceiver, and a processor coupled to the memory and the transceiver, the apparatus being configured to implement a method as in any of claims 1-15.

Images