210 can be logically split into one or more CU-UP units and one or more CU-CP units. The CU-UP unit can communicate bidirectionally with the CU-CP unit via an interface, such as the E1 interface when implemented in an O-RAN configuration. The CU 210 can be implemented to communicate with the DU 230, as necessary, for network control and signaling.

The DU 230 may correspond to a logical unit that includes one or more base station functions to control the operation of one or more RUs 240. In some aspects, the DU 230 may host one or more of a radio link control (RLC) layer, a medium access control (MAC) layer, and one or more high physical (PHY) layers (such as modules for forward error correction (FEC) encoding and decoding, scrambling, modulation and demodulation, or the like) depending, at least in part, on a functional split, such as those defined by the 3^rdGeneration Partnership Project (3GPP). In some aspects, the DU 230 may further host one or more low PHY layers. Each layer (or module) can be implemented with an interface configured to communicate signals with other layers (and modules) hosted by the DU 230, or with the control functions hosted by the CU 210.

Lower-layer functionality can be implemented by one or more RUs 240. In some deployments, an RU 240, controlled by a DU 230, may correspond to a logical node that hosts RF processing functions, or low-PHY layer functions (such as performing fast Fourier transform (FFT), inverse FFT (iFFT), digital beamforming, physical random access channel (PRACH) extraction and filtering, or the like), or both, based at least in part on the functional split, such as a lower layer functional split. In such an architecture, the RU(s) 240 can be implemented to handle over the air (OTA) communications with one or more UEs 104. In some implementations, real-time and non-real-time aspects of control and user plane communications with the RU(s) 240 can be controlled by the corresponding DU 230. In some scenarios, this configuration can enable the DU(s) 230 and the CU 210 to be implemented in a cloud-based RAN architecture, such as a vRAN architecture.

The SMO Framework 205 may be configured to support RAN deployment and provisioning of non-virtualized and virtualized network elements. For non-virtualized network elements, the SMO Framework 205 may be configured to support the deployment of dedicated physical resources for RAN coverage requirements which may be managed via an operations and maintenance interface (such as an O1 interface). For virtualized network elements, the SMO Framework 205 may be configured to interact with a cloud computing platform (such as an open cloud (O-Cloud) 290) to perform network element life cycle management (such as to instantiate virtualized network elements) via a cloud computing platform interface (such as an O2 interface). Such virtualized network elements can include, but are not limited to, CUs 210, DUs 230, RUs 240 and Near-RT RICs 225. In some implementations, the SMO Framework 205 can communicate with a hardware aspect of a 4G RAN, such as an open eNB (O-eNB) 211, via an O1 interface. Additionally, in some implementations, the SMO Framework 205 can communicate directly with one or more RUs 240 via an O1 interface. The SMO Framework 205 also may include a Non-RT RIC 215 configured to support functionality of the SMO Framework 205.

The Non-RT RIC 215 may be configured to include a logical function that enables non-real-time control and optimization of RAN elements and resources, Artificial Intelligence/Machine Learning (AI/ML) workflows including model training and updates, or policy-based guidance of applications/features in the Near-RT RIC 225. The Non-RT RIC 215 may be coupled to or communicate with (such as via an A1 interface) the Near-RT RIC 225. The Near-RT RIC 225 may be configured to include a logical function that enables near-real-time control and optimization of RAN elements and resources via data collection and actions over an interface (such as via an E2 interface) connecting one or more CUs 210, one or more DUs 230, or both, as well as an O-eNB, with the Near-RT RIC 225.

In some implementations, to generate AI/ML models to be deployed in the Near-RT RIC 225, the Non-RT RIC 215 may receive parameters or external enrichment information from external servers. Such information may be utilized by the Near-RT RIC 225 and may be received at the SMO Framework 205 or the Non-RT RIC 215 from non-network data sources or from network functions. In some examples, the Non-RT RIC 215 or the Near-RT RIC 225 may be configured to tune RAN behavior or performance. For example, the Non-RT RIC 215 may monitor long-term trends and patterns for performance and employ AI/ML models to perform corrective actions through the SMO Framework 205 (such as reconfiguration via O1) or via creation of RAN management policies (such as A1 policies).

FIG. 3 depicts aspects of an example BS 102 and a UE 104.

Generally, BS 102 includes various processors (e.g., 320, 330, 338, and 340), antennas 334a-t (collectively 334), transceivers 332a-t (collectively 332), which include modulators and demodulators, and other aspects, which enable wireless transmission of data (e.g., data source 312) and wireless reception of data (e.g., data sink 339). For example, BS 102 may send and receive data between BS 102 and UE 104. BS 102 includes controller/processor 340, which may be configured to implement various functions described herein related to wireless communications.

Generally, UE 104 includes various processors (e.g., 358, 364, 366, and 380), antennas 352a-r (collectively 352), transceivers 354a-r (collectively 354), which include modulators and demodulators, and other aspects, which enable wireless transmission of data (e.g., retrieved from data source 362) and wireless reception of data (e.g., provided to data sink 360). UE 104 includes controller/processor 380, which may be configured to implement various functions described herein related to wireless communications.

In regards to an example downlink transmission, BS 102 includes a transmit processor 320 that may receive data from a data source 312 and control information from a controller/processor 340. The control information may be for the physical broadcast channel (PBCH), physical control format indicator channel (PCFICH), physical HARQ indicator channel (PHICH), physical downlink control channel (PDCCH), group common PDCCH (GC PDCCH), and/or others. The data may be for the physical downlink shared channel (PDSCH), in some examples.

Transmit processor 320 may process (e.g., encode and symbol map) the data and control information to obtain data symbols and control symbols, respectively. Transmit processor 320 may also generate reference symbols, such as for the primary synchronization signal (PSS), secondary synchronization signal (SSS), PBCH demodulation reference signal (DMRS), and channel state information reference signal (CSI-RS).

Transmit (TX) multiple-input multiple-output (MIMO) processor 330 may perform spatial processing (e.g., precoding) on the data symbols, the control symbols, and/or the reference symbols, if applicable, and may provide output symbol streams to the modulators (MODs) in transceivers 332a-332t. Each modulator in transceivers 332a-332t may process a respective output symbol stream to obtain an output sample stream. Each modulator may further process (e.g., convert to analog, amplify, filter, and upconvert) the output sample stream to obtain a downlink signal. Downlink signals from the modulators in transceivers 332a-332t may be transmitted via the antennas 334a-334t, respectively.

In order to receive the downlink transmission, UE 104 includes antennas 352a-352r that may receive the downlink signals from the BS 102 and may provide received signals to the demodulators (DEMODs) in transceivers 354a-354r, respectively. Each demodulator in transceivers 354a-354r may condition (e.g., filter, amplify, downconvert, and digitize) a respective received signal to obtain input samples. Each demodulator may further process the input samples to obtain received symbols.

MIMO detector 356 may obtain received symbols from all the demodulators in transceivers 354a-354r, perform MIMO detection on the received symbols if applicable, and provide detected symbols. Receive processor 358 may process (e.g., demodulate, deinterleave, and decode) the detected symbols, provide decoded data for the UE 104 to a data sink 360, and provide decoded control information to a controller/processor 380.

In regards to an example uplink transmission, UE 104 further includes a transmit processor 364 that may receive and process data (e.g., for the PUSCH) from a data source 362 and control information (e.g., for the physical uplink control channel (PUCCH)) from the controller/processor 380. Transmit processor 364 may also generate reference symbols for a reference signal (e.g., for the sounding reference signal (SRS)). The symbols from the transmit processor 364 may be precoded by a TX MIMO processor 366 if applicable, further processed by the modulators in transceivers 354a-354r (e.g., for SC-FDM), and transmitted to BS 102.

At BS 102, the uplink signals from UE 104 may be received by antennas 334a-t, processed by the demodulators in transceivers 332a-332t, detected by a MIMO detector 336 if applicable, and further processed by a receive processor 338 to obtain decoded data and control information sent by UE 104. Receive processor 338 may provide the decoded data to a data sink 339 and the decoded control information to the controller/processor 340.

Memories 342 and 382 may store data and program codes for BS 102 and UE 104, respectively.

Scheduler 344 may schedule UEs for data transmission on the downlink and/or uplink.

In various aspects, BS 102 may be described as transmitting and receiving various types of data associated with the methods described herein. In these contexts, “transmitting” may refer to various mechanisms of outputting data, such as outputting data from data source 312, scheduler 344, memory 342, transmit processor 320, controller/processor 340, TX MIMO processor 330, transceivers 332a-t, antenna 334a-t,and/or other aspects described herein. Similarly, “receiving” may refer to various mechanisms of obtaining data, such as obtaining data from antennas 334a-t, transceivers 332a-t, RX MIMO detector 336, controller/processor 340, receive processor 338, scheduler 344, memory 342, and/or other aspects described herein.

In various aspects, UE 104 may likewise be described as transmitting and receiving various types of data associated with the methods described herein. In these contexts, “transmitting” may refer to various mechanisms of outputting data, such as outputting data from data source 362, memory 382, transmit processor 364, controller/processor 380, TX MIMO processor 366, transceivers 354a-t, antenna 352a-t, and/or other aspects described herein. Similarly, “receiving” may refer to various mechanisms of obtaining data, such as obtaining data from antennas 352a-t, transceivers 354a-t, RX MIMO detector 356, controller/processor 380, receive processor 358, memory 382, and/or other aspects described herein.

In some aspects, a processor may be configured to perform various operations, such as those associated with the methods described herein, and transmit (output) to or receive (obtain) data from another interface that is configured to transmit or receive, respectively, the data.

FIGS. 4A, 4B, 4C, and 4D depict aspects of data structures for a wireless communications network, such as wireless communications network 100 of FIG. 1.

In particular, FIG. 4A is a diagram 400 illustrating an example of a first subframe within a 5G (e.g., 5G NR) frame structure, FIG. 4B is a diagram 430 illustrating an example of DL channels within a 5G subframe, FIG. 4C is a diagram 450 illustrating an example of a second subframe within a 5G frame structure, and FIG. 4D is a diagram 480 illustrating an example of UL channels within a 5G subframe.

Wireless communications systems may utilize orthogonal frequency division multiplexing (OFDM) with a cyclic prefix (CP) on the uplink and downlink. Such systems may also support half-duplex operation using time division duplexing (TDD). OFDM and single-carrier frequency division multiplexing (SC-FDM) partition the system bandwidth (e.g., as depicted in FIGS. 4B and 4D) into multiple orthogonal subcarriers. Each subcarrier may be modulated with data. Modulation symbols may be sent in the frequency domain with OFDM and/or in the time domain with SC-FDM.

A wireless communications frame structure may be frequency division duplex (FDD), in which, for a particular set of subcarriers, subframes within the set of subcarriers are dedicated for either DL or UL. Wireless communications frame structures may also be time division duplex (TDD), in which, for a particular set of subcarriers, subframes within the set of subcarriers are dedicated for both DL and UL.

In FIG. 4A and 4C, the wireless communications frame structure is TDD where D is DL, U is UL, and X is flexible for use between DL/UL. UEs may be configured with a slot format through a received slot format indicator (SFI) (dynamically through DL control information (DCI), or semi-statically/statically through radio resource control (RRC) signaling). In the depicted examples, a 10 ms frame is divided into 10 equally sized 1 ms subframes. Each subframe may include one or more time slots. In some examples, each slot may include 7 or 14 symbols, depending on the slot format. Subframes may also include mini-slots, which generally have fewer symbols than an entire slot. Other wireless communications technologies may have a different frame structure and/or different channels.

In certain aspects, the number of slots within a subframe is based on a slot configuration and a numerology. For example, for slot configuration 0, different numerologies (μ) 0 to 5 allow for 1, 2, 4, 8, 16, and 32 slots, respectively, per subframe. For slot configuration 1, different numerologies 0 to 2 allow for 2, 4, and 8 slots, respectively, per subframe. Accordingly, for slot configuration 0 and numerology μ, there are 14 symbols/slot and 2μ slots/subframe. The subcarrier spacing and symbol length/duration are a function of the numerology. The subcarrier spacing may be equal to 24×15 kHz, where μ is the numerology 0 to 5. As such, the numerology μ=0 has a subcarrier spacing of 15 kHz and the numerology μ=5 has a subcarrier spacing of 480 kHz. The symbol length/duration is inversely related to the subcarrier spacing. FIGS. 4A, 4B, 4C, and 4D provide an example of slot configuration 0 with 14 symbols per slot and numerology μ=2 with 4 slots per subframe. The slot duration is 0.25 ms, the subcarrier spacing is 60 kHz, and the symbol duration is approximately 16.67 μs.

As depicted in FIGS. 4A, 4B, 4C, and 4D, a resource grid may be used to represent the frame structure. Each time slot includes a resource block (RB) (also referred to as physical RBs (PRBs)) that extends, for example, 12 consecutive subcarriers. The resource grid is divided into multiple resource elements (REs). The number of bits carried by each RE depends on the modulation scheme.

As illustrated in FIG. 4A, some of the REs carry reference (pilot) signals (RS) for a UE (e.g., UE 104 of FIGS. 1 and 3). The RS may include demodulation RS (DMRS) and/or channel state information reference signals (CSI-RS) for channel estimation at the UE. The RS may also include beam measurement RS (BRS), beam refinement RS (BRRS), and/or phase tracking RS (PT-RS).

FIG. 4B illustrates an example of various DL channels within a subframe of a frame. The physical downlink control channel (PDCCH) carries DCI within one or more control channel elements (CCEs), each CCE including, for example, nine RE groups (REGs), each REG including, for example, four consecutive REs in an OFDM symbol.

A primary synchronization signal (PSS) may be within symbol 2 of particular subframes of a frame. The PSS is used by a UE (e.g., 104 of FIGS. 1 and 3) to determine subframe/symbol timing and a physical layer identity.

A secondary synchronization signal (SSS) may be within symbol 4 of particular subframes of a frame. The SSS is used by a UE to determine a physical layer cell identity group number and radio frame timing.

Based on the physical layer identity and the physical layer cell identity group number, the UE can determine a physical cell identifier (PCI). Based on the PCI, the UE can determine the locations of the aforementioned DMRS. The physical broadcast channel (PBCH), which carries a master information block (MIB), may be logically grouped with the PSS and SSS to form a synchronization signal (SS)/PBCH block. The MIB provides a number of RBs in the system bandwidth and a system frame number (SFN). The physical downlink shared channel (PDSCH) carries user data, broadcast system information not transmitted through the PBCH such as system information blocks (SIBs), and/or paging messages.

As illustrated in FIG. 4C, some of the REs carry DMRS (indicated as R for one particular configuration, but other DMRS configurations are possible) for channel estimation at the base station. The UE may transmit DMRS for the PUCCH and DMRS for the PUSCH. The PUSCH DMRS may be transmitted, for example, in the first one or two symbols of the PUSCH. The PUCCH DMRS may be transmitted in different configurations depending on whether short or long PUCCHs are transmitted and depending on the particular PUCCH format used. UE 104 may transmit sounding reference signals (SRS). The SRS may be transmitted, for example, in the last symbol of a subframe. The SRS may have a comb structure, and a UE may transmit SRS on one of the combs. The SRS may be used by a base station for channel quality estimation to enable frequency-dependent scheduling on the UL.

FIG. 4D illustrates an example of various UL channels within a subframe of a frame. The PUCCH may be located as indicated in one configuration. The PUCCH carries uplink control information (UCI), such as scheduling requests, a channel quality indicator (CQI), a precoding matrix indicator (PMI), a rank indicator (RI), and HARQ ACK/NACK feedback. The PUSCH carries data, and may additionally be used to carry a buffer status report (BSR), a power headroom report (PHR), and/or UCI.

Overview of Multiplexing UCI on PUSCH

As noted above, UCI multiplexing on PUSCH is a mechanism that allows UCI to be transmitted on PUSCH resources. Certain types of UCI, such as hybrid automatic repeat request (HARQ) acknowledgment feedback and channel state information (CSI) are typically mapped to all layers of the TB on PUSCH in case of single TB for PUSCH. Modulation order of UCI typically follows the modulation order of the UL-SCH. For aperiodic CSI on PUSCH, triggered by an UL grant without UL-SCH data, the modulation order for PUSCH is typically handled the same way as the case when PUSCH is transmitted with UL-SCH data.

FIG. 5 is a conceptual diagram illustrating how UCI may be multiplexed with an UL data channel, in accordance with certain aspects of the present disclosure. As illustrated, UCI multiplexing on PUSCH may occur when a physical uplink control channel (PUCCH) scheduled to carry UCI overlaps (e.g., in the time domain) with a PUSCH. In this case, the PUCCH transmission may dropped and the UCI may be multiplexed on the PUSCH so that the PUSCH channel now carries data and UCI (UL-SCH+UCI).

How UCI is multiplexed may depend on the type and size of UCI content. For example, for HARQ-ACK multiplexed on PUSCH, if the payload is less than or equal to 2 bits, PUSCH may be punctured. On the other hand, for HARQ-ACK multiplexed on PUSCH, if the payload is more than 2 bits, PUSCH may be rate-matched. For a periodic CSI report configured by RRC and aperiodic CSI report triggered by UL grant, the UCI may rate-match PUSCH. For CSI multiplexing on PUSCH, CSI may be mapped to distributed REs across PUSCH allocated RBs. In some cases splitting CSI by mapping (at least for some CSI) into two parts may be supported. In such cases, the two parts may be mapped differently.

In some cases, HARQ-ACK content may be mapped to REs around demodulation reference signal (DMRS) symbol(s). Modulated HARQ-ACK symbols may be mapped starting on the first available non-DMRS symbol after the first DMRS symbol(s), regardless of number of DMRS symbols in a PUSCH transmission. Different types of CSI (e.g., CSI part 1 and CSI part 2) may be mapped starting on the first available non-DMRS symbol, regardless of number of DMRS symbols in a PUSCH.

If PUSCH is punctured by HARQ-ACK, CSI part 1 may be mapped starting after certain amount of reserved HARQ-ACK REs. CSI part 1 may not be mapped on the reserved HARQ-ACK REs. CSI part 2 may not be mapped on the CSI part 1 REs. CSI part 2 and PUSCH can be mapped to reserved HARQ-ACK REs. If PUSCH is rate matched by HARQ-ACK, HARQ-ACK may be mapped first, followed by CSI part 1. In such cases, CSI part 1 may not be mapped on the HARQ-ACK REs, while CSI part 2 may not be mapped on the HARQ-ACK RES.

One potential challenge is how to multiplex UCI on simultaneous multi-panel UL transmission. Multi-panel transmission may allow for higher UL throughput and reliability, particularly on certain frequency bands (e.g., on FR2) and multiple transmitter receiver point (mTRP) scenarios, assuming up to 2 TRPs and up to 2 panels. Uplink precoding may be indicated for PUSCH, where no new codebook is introduced for multi-panel simultaneous transmission.

In some cases, a total number of layers may be up to four across all panels and total number of codewords is up to two across all panels, considering single DCI and multi-DCI based multi-TRP operation. In other cases, UL DMRS, SRS, SRI, and TPMI (including codebook) may be enhanced to enable 8 Tx UL operation to support 4 and more layers per UE in the uplink. And multiple codewords may be needed for more than 4 layers for UL.

Aspects Related to Multiplexing UCI on PUSCH with Multiple TBs

As noted above, the potential to multiple TBs with different transmission parameters creates potential challenges with multiplexing UCI on PUSCH. For example, one challenge is how to map the UCI content to available resources on the different TBs.

Aspects of the present disclosure, however, provide various approaches that may help determine how to multiplex UCI on PUSCH with multiple TBs.

According to one example aspect, when more than one TB is transmitted on a PUSCH, UCI may be multiplexed on all layers of all TBs on the PUSCH, regardless of the UCI type. This may provide increased robustness for the UCI.

FIG. 6 illustrates one example mechanism 600 for multiplexing UCI on resource elements (REs) on all layers of all TBs (e.g., TB0 and TB1) on the PUSCH.

As illustrated, in this example, the UCI multiplexed on one TB (e.g., a first TB, labeled “TB0”) may be a replica of the UCI multiplexed on another TB (e.g., a second TB, labeled “TB1”). In some aspects, each replica of the UCI may be multiplexed on the same resource elements (REs) across the layers of all TBs. The UCI may include hybrid automatic repeat request (HARQ) acknowledgement (HARQ-ACK) feedback as well as channel state information (CSI) which may be separated into CSI part 1 and CSI part 2. In some aspects, the same coded bits before rate matching are rate matched separately and mapped to the layers of the first TB and second TB, respectively.

FIG. 7 illustrates another example mechanism 700 for multiplexing UCI on all layers of all TBs on the PUSCH.

In this example, the UCI may be multiplexed on the same REs across the layers of all TBs without repeating (e.g., replicating) the UCI on the different TBs. As illustrated, in some aspects, the coded bits may be mapped to the layers of the first TB and the second TB separately. For example, the coded UCI bits may be split into a first part 702 and a second part 704 to balance the UCI bits multiplexed on different TBs. In one example, the first part 702 may be multiplexed on TB0 and the second part 704 may be multiplexed on TB1, as shown. In this case, the UCI bits multiplexed on TB0 may be excluded from the UCI bits multiplexed on TB1.

According to certain aspects, when more than one TB is transmitted on a PUSCH, the UCI may be multiplexed on all layers of one of the TBs on the PUSCH. That is, all UCI may be multiplexed on all layers of one TB.

FIG. 8 illustrates an example mechanism 800 for multiplexing UCI on all layers of one TB (e.g., either TB0 or TB1).

In the example shown, the UE determines to multiplex the UCI on TB1. Accordingly, all of the UCI may be multiplexed only on TB1 (and TBO may be used to transmit uplink (UL) scheduling (UL-SCH, as shown). The selection of the TB on which the UCI will be multiplexed may or may not depend on a type of the UCI. This may provide increased robustness for the UCI. In some aspects, the UCI may be multiplexed on the TB with the highest modulation coding scheme (MCS). So, in the example illustrated in FIG. 8, TB1 may have a higher MCS than TB0. In some aspects, if the MCS of both TBs are the same, the UCI may be multiplexed on the TB that is first sequentially (e.g., TB0).

In some cases, different UCI (e.g., different UCI types) may have different reliability standards. Therefore, according to certain aspects, when more than one TB is transmitted on a PUSCH, the UCI may be multiplexed on all layers of one or more selected TBs, which may be selected based on the type of the UCI to be multiplexed. That is, some UCI may be multiplexed on all layers of both TBs, while other UCI may be multiplexed on all layers of only one TB.

For example, FIG. 9 illustrates another example mechanism 900 for multiplexing UCI based on a type of the UCI.

In this case, UCI with relatively high reliability standards (e.g., HARQ-ACK and/or CG-UCI) may be multiplexed on all layers of both TBs with repetition, while UCI with relatively low reliability standards (e.g., CSI) may be multiplexed on all layers of a single TB. In the example in FIG. 9, the HARQ-ACK feedback may be multiplexed on both TB0 and TB1, and the CSI (parts 1 and 2) may be multiplexed on TB1 (but not on TB0). In certain aspects, the UCI which is included in both TBs (e.g., HARQ-ACK feedback in FIG. 9) may be multiplexed on the same REs across the layers of all TBs, and the UCI multiplexed on one TB may be a replica of the UCI multiplexed on another TB. In certain other aspects, the UCI may be multiplexed on the same REs across the layers of all TBs without repeating the UCI on different TBs (e.g., the UCI may be split, as discussed above).

In some cases, different UCI may have a different payload size. In such cases, for UCI with a relatively larger payload (such as CSI) the UCI may be multiplexed on all layers of both TBs without repetition, while for UCI with a relatively smaller payload (such as HARQ-ACK and/or CG-UCI) the UCI may be multiplexed on all layers of a single TB.

For example, FIG. 10 illustrates an example mechanism 1000 for multiplexing UCI in this manner.

In this example, the CSI (parts 1 and 2) may be multiplexed on both TB0 and TB1, and the HARQ-ACK feedback may be multiplexed on TB0 (but not on TB1). In certain aspects, the UCI which is included in both TBs (e.g., CSI in FIG. 10) may be multiplexed on the same REs across the layers of all TBs, and the UCI multiplexed on one TB may be a replica of the UCI multiplexed on another TB. In certain other aspects, the UCI may be multiplexed on the same REs across the layers of all TBs without repeating the UCI on different TBs (e.g., the UCI may be split, as discussed above).

According to certain aspects, some UCI (e.g., of a first type) may be multiplexed on all layers of one TB while other UCI (e.g., of a second type) may be mapped to the layers of another TB. This may help balance the REs used for UCI multiplexing on different TBs.

For example, FIG. 11 illustrates an example mechanism 1100 for multiplexing UCI in this manner. As illustrated, the HARQ-ACK feedback and the CSI part 1 may be multiplexed on TB0, while the CSI part 2 may be multiplexed on TB1.

In some aspects, (such as the one shown in FIG. 11) different UCI may be multiplexed on different REs across all layers of different TBs. That is, REs in TB1 that correspond to the REs in TB0 used to transmit the HARQ-ACK feedback and CSI part 1 may not be used to multiplex CSI part 2.

Alternatively, as illustrated by the example method 1200 in FIG. 12, different UCI (content) may be multiplexed on the same REs across all layers of different TBs (e.g., when multiplexing UCI bits on the layers of the second TB, the REs of the first TB on which UCI has been multiplexed are not excluded). That is, REs in TB1 that correspond to the REs in TB0 used to transmit the HARQ-ACK feedback and CSI part 1 may also be used to multiplex CSI part 2.

In some examples, one or more types of UCI (e.g., HARQ-ACK feedback, CSI part 1, and/or CG-UCI) may be multiplexed on all layers of the first TB or the TB with highest MCS, while one or more other types of UCI (e.g., CSI part 1, CSI part 2, and/or CG-UCI) may be multiplexed on all layers of the second TB or the TB with lowest MCS.

In any of the aspects described above, the modulation order of the UCI may follow the modulation order of the corresponding TB on which the UCI is multiplexed. That is, the UCI multiplexed on the first TB may follow the modulation order of the first TB, and UCI multiplexed on the second TB may follow the modulation order of the second TB. Additionally, in any of the aspects described above in which the UCI is multiplexed on more than one TB, the coded bits of the UCI (e.g., before rate matching) may be rate matched separately and then multiplexed on the first TB and the second TB.

When the UCI is multiplexed on the first TB on a first set of resource elements (REs), data in the PUSCH may not be mapped to the first set of REs on the first TB.

However, as illustrated in FIG. 13, the data in the PUSCH may be mapped to REs in the second TB (e.g., TB0 in this case) that correspond to the first set of REs on the first TB (e.g., TB1 in this case). Alternatively, as illustrated in FIG. 14, the data in the PUSCH may not be mapped to REs in the second TB that correspond to the first set of REs in the first TB.

Example Operations of a User Equipment

FIG. 15 shows an example of a method 1500 for wireless communications. In some cases, method 1500 may be performed by a UE, such as UE 104 of FIGS. 1 and 3.

Method 1500 begins at step 1505 with receiving signaling scheduling a PUSCH with at least a first TB and a second TB, wherein the first and second TBs have separate transmission parameters. In some cases, the operations of this step refer to, or may be performed by, circuitry for receiving and/or code for receiving as described with reference to FIG. 17.

Method 1500 then proceeds to step 1510 with determining how to multiplex UCI on the PUSCH. In some cases, the operations of this step refer to, or may be performed by, circuitry for determining and/or code for determining as described with reference to FIG. 17.

Method 1500 then proceeds to step 1515 with transmitting the PUSCH with the UCI multiplexed on the PUSCH in accordance with the determination. In some cases, the operations of this step refer to, or may be performed by, circuitry for transmitting and/or code for transmitting as described with reference to FIG. 17.

In some aspects, the UCI is multiplexed on one of the first TB or the second TB

In some aspects, the UCI is multiplexed on either: the TB with a higher MCS; or the first TB if the MCS of the first TB and the second TB are the same.

In some aspects, a modulation order of the UCI follows: a modulation order of the first TB based on the UCI being multiplexed on the first TB; or a modulation order of the second TB based on the UCI being multiplexed on the second TB.

In some aspects, at least a portion of the UCI is multiplexed on each of the first TB and the second TB.

In some aspects, a modulation order of the UCI multiplexed on the first TB follows a modulation order of the first TB, and the UCI multiplexed on the second TB follows a modulation order of the second TB.

In some aspects, coded bits of the UCI multiplexed on the first TB are rate matched separately from coded bits of the UCI multiplexed on the second TB.

In some aspects, the UCI is multiplexed on same REs across layers of the first TB and the second TB; and the UCI multiplexed on the first TB is a replica of the UCI multiplexed on the second TB.

In some aspects, a first set of coded bits of the UCI is multiplexed on the first TB; and a second set of coded bits of the UCI is multiplexed on the second TB.

In some aspects, the determination of how to multiplex the UCI on the PUSCH is based on a type of the UCI.

In some aspects, UCI of a first type is multiplexed on each of the first TB and the second TB; and UCI of a second type is multiplexed on either the first TB or the second TB.

In some aspects, UCI of a first type is multiplexed on the first TB; and UCI of a second type is multiplexed on the second TB.

In some aspects, the UCI is multiplexed on different REs across layers of the first TB and the second TB.

In some aspects, the UCI is multiplexed on same REs across layers of the first TB and the second TB.

In some aspects, the UCI is multiplexed on the first TB on a first set of Res; data in the PUSCH is not mapped to the first set of REs on the first TB; and the data in the PUSCH is mapped to REs in the second TB that correspond to the first set of REs.

In some aspects, the UCI is multiplexed on the first TB on a first set of REs; data in the PUSCH is not mapped to the first set of REs on the first TB; and the data in the PUSCH is not mapped to REs in the second TB that correspond to the first set of REs.

In one aspect, method 1500, or any aspect related to it, may be performed by an apparatus, such as communications device 1700 of FIG. 17, which includes various components operable, configured, or adapted to perform the method 1500. Communications device 1700 is described below in further detail.

Note that FIG. 15 is just one example of a method, and other methods including fewer, additional, or alternative steps are possible consistent with this disclosure.

Example Operations of a Network Entity

FIG. 16 shows an example of a method 1600 for wireless communications by a network entity, such as BS 102 of FIGS. 1 and 3, or a disaggregated base station as discussed with respect to FIG. 2.

Method 1600 begins at step 1605 with transmitting signaling scheduling a UE for a PUSCH with at least a first TB and a second TB, wherein the first and second TBs have separate transmission parameters. In some cases, the operations of this step refer to, or may be performed by, circuitry for transmitting and/or code for transmitting as described with reference to FIG. 18.

Method 1600 then proceeds to step 1610 with determining how the UE will multiplex UCI on the PUSCH. In some cases, the operations of this step refer to, or may be performed by, circuitry for determining and/or code for determining as described with reference to FIG. 18.

Method 1600 then proceeds to step 1615 with monitoring for the PUSCH with the UCI multiplexed on the PUSCH in accordance with the determination. In some cases, the operations of this step refer to, or may be performed by, circuitry for monitoring and/or code for monitoring as described with reference to FIG. 18.

In some aspects, the UCI is multiplexed on one of the first TB or the second TB.

In some aspects, the UCI is multiplexed on either: the TB with a higher MCS; or the first TB if the MCS of the first TB and the second TB are the same.

In some aspects, a modulation order of the UCI follows: a modulation order of the first TB based on the UCI being multiplexed on the first TB; or a modulation order of the second TB based on the UCI being multiplexed on the second TB.

In some aspects, at least a portion of the UCI is multiplexed on each of the first TB and the second TB.

In some aspects, the modulation order of the portion of the UCI multiplexed on the first TB follows a modulation order of the first TB, and the portion of the UCI multiplexed on the second TB follows a modulation order of the second TB.

In some aspects, coded bits of the UCI multiplexed on the first TB are rate matched separately from coded bits of the UCI multiplexed on the second TB.

In some aspects, the UCI is multiplexed on same REs across layers of the first TB and the second TB; and the UCI multiplexed on the first TB is a replica of the UCI multiplexed on the second TB.

In some aspects, a first set of coded bits of the UCI is multiplexed on the first TB; and a second set of coded bits of the UCI is multiplexed on the second TB.

In some aspects, the determination of how the UE will multiplex the UCI on the PUSCH is based on a type of the UCI.

In some aspects, UCI of a first type is multiplexed on each of the first TB and the second TB; and UCI of a second type is multiplexed on either the first TB or the second TB.

In some aspects, UCI of a first type is multiplexed on the first TB; and UCI of a second type is multiplexed on the second TB.

In some aspects, the UCI is multiplexed on different REs across layers of the first TB and the second TB.

In some aspects, the UCI is multiplexed on same REs across layers of the first TB and the second TB.

In some aspects, the UCI is multiplexed on the first TB on a first set of REs; and data in the PUSCH is mapped to REs in the second TB that correspond to the first set of REs.

In some aspects, the UCI is multiplexed on the first TB on a first set of RES; and data in the PUSCH is not mapped to REs in the second TB that correspond to the first set of REs.

In one aspect, method 1600, or any aspect related to it, may be performed by an apparatus, such as communications device 1800 of FIG. 18, which includes various components operable, configured, or adapted to perform the method 1600. Communications device 1800 is described below in further detail.

Note that FIG. 16 is just one example of a method, and other methods including fewer, additional, or alternative steps are possible consistent with this disclosure.

Example Communications Devices

FIG. 17 depicts aspects of an example communications device 1700. In some aspects, communications device 1700 is a user equipment, such as UE 104 described above with respect to FIGS. 1 and 3.

The communications device 1700 includes a processing system 1705 coupled to the transceiver 1755 (e.g., a transmitter and/or a receiver). The transceiver 1755 is configured to transmit and receive signals for the communications device 1700 via the antenna 1760, such as the various signals as described herein. The processing system 1705 may be configured to perform processing functions for the communications device 1700, including processing signals received and/or to be transmitted by the communications device 1700.

The processing system 1705 includes one or more processors 1710. In various aspects, the one or more processors 1710 may be representative of one or more of receive processor 358, transmit processor 364, TX MIMO processor 366, and/or controller/processor 380, as described with respect to FIG. 3. The one or more processors 1710 are coupled to a computer-readable medium/memory 1730 via a bus 1750. In certain aspects, the computer-readable medium/memory 1730 is configured to store instructions (e.g., computer-executable code) that when executed by the one or more processors 1710, cause the one or more processors 1710 to perform the method 1500 described with respect to FIG. 15, or any aspect related to it. Note that reference to a processor performing a function of communications device 1700 may include one or more processors 1710 performing that function of communications device 1700.

In the depicted example, computer-readable medium/memory 1730 stores code (e.g., executable instructions), such as code for receiving 1735, code for determining 1740, and code for transmitting 1745. Processing of the code for receiving 1735, code for determining 1740, and code for transmitting 1745 may cause the communications device 1700 to perform the method 1500 described with respect to FIG. 15, or any aspect related to it.

The one or more processors 1710 include circuitry configured to implement (e.g., execute) the code stored in the computer-readable medium/memory 1730, including circuitry such as circuitry for receiving 1715, circuitry for determining 1720, and circuitry for transmitting 1725. Processing with circuitry for receiving 1715, circuitry for determining 1720, and circuitry for transmitting 1725 may cause the communications device 1700 to perform the method 1500 described with respect to FIG. 15, or any aspect related to it.

Various components of the communications device 1700 may provide means for performing the method 1500 described with respect to FIG. 15, or any aspect related to it. For example, means for transmitting, sending or outputting for transmission may include transceivers 354 and/or antenna(s) 352 of the UE 104 illustrated in FIG. 3 and/or the transceiver 1755 and the antenna 1760 of the communications device 1700 in FIG. 17. Means for receiving or obtaining may include transceivers 354 and/or antenna(s) 352 of the UE 104 illustrated in FIG. 3 and/or the transceiver 1755 and the antenna 1760 of the communications device 1700 in FIG. 17.

FIG. 18 depicts aspects of an example communications device 1800. In some aspects, communications device 1800 is a network entity, such as BS 102 of FIGS. 1 and 3, or a disaggregated base station as discussed with respect to FIG. 2.

The communications device 1800 includes a processing system 1805 coupled to the transceiver 1855 (e.g., a transmitter and/or a receiver) and/or a network interface 1865. The transceiver 1855 is configured to transmit and receive signals for the communications device 1800 via the antenna 1860, such as the various signals as described herein. The network interface 1865 is configured to obtain and send signals for the communications device 1800 via communication link(s), such as a backhaul link, midhaul link, and/or fronthaul link as described herein, such as with respect to FIG. 2. The processing system 1805 may be configured to perform processing functions for the communications device 1800, including processing signals received and/or to be transmitted by the communications device 1800.

The processing system 1805 includes one or more processors 1810. In various aspects, one or more processors 1810 may be representative of one or more of receive processor 338, transmit processor 320, TX MIMO processor 330, and/or controller/processor 340, as described with respect to FIG. 3. The one or more processors 1810 are coupled to a computer-readable medium/memory 1830 via a bus 1850. In certain aspects, the computer-readable medium/memory 1830 is configured to store instructions (e.g., computer-executable code) that when executed by the one or more processors 1810, cause the one or more processors 1810 to perform the method 1600 described with respect to FIG. 16, or any aspect related to it. Note that reference to a processor of communications device 1800 performing a function may include one or more processors 1810 of communications device 1800 performing that function.

In the depicted example, the computer-readable medium/memory 1830 stores code (e.g., executable instructions), such as code for transmitting 1835, code for determining 1840, and code for monitoring 1845. Processing of the code for transmitting 1835, code for determining 1840, and code for monitoring 1845 may cause the communications device 1800 to perform the method 1600 described with respect to FIG. 16, or any aspect related to it.

The one or more processors 1810 include circuitry configured to implement (e.g., execute) the code stored in the computer-readable medium/memory 1830, including circuitry such as circuitry for transmitting 1815, circuitry for determining 1820, and circuitry for monitoring 1825. Processing with circuitry for transmitting 1815, circuitry for determining 1820, and circuitry for monitoring 1825 may cause the communications device 1800 to perform the method 1600 as described with respect to FIG. 16, or any aspect related to it.

Various components of the communications device 1800 may provide means for performing the method 1600 as described with respect to FIG. 16, or any aspect related to it. Means for transmitting, sending or outputting for transmission may include transceivers 332 and/or antenna(s) 334 of the BS 102 illustrated in FIG. 3 and/or the transceiver 1855 and the antenna 1860 of the communications device 1800 in FIG. 18. Means for receiving or obtaining may include transceivers 332 and/or antenna(s) 334 of the BS 102 illustrated in FIG. 3 and/or the transceiver 1855 and the antenna 1860 of the communications device 1800 in FIG. 18.

Example Clauses
Implementation Examples are Described in the Following Numbered Clauses

Clause 1: A method for wireless communication comprising: receiving signaling scheduling a PUSCH with at least a first TB and a second TB, wherein the first and second TBs have separate transmission parameters; determining how to multiplex UCI on the PUSCH; and transmitting the PUSCH with the UCI multiplexed on the PUSCH in accordance with the determination.

Clause 2: The method of Clause 1, wherein the UCI is multiplexed on one of the first TB or the second TB.

Clause 3: The method of Clause 2, wherein the UCI is multiplexed on either: the TB with a higher MCS; or the first TB if the MCS of the first TB and the second TB are the same.

Clause 4: The method of Clause 2, wherein a modulation order of the UCI follows: a modulation order of the first TB based on the UCI being multiplexed on the first TB; or a modulation order of the second TB based on the UCI being multiplexed on the second TB.

Clause 5: The method of any one of Clauses 1-4, wherein: at least a portion of the UCI is multiplexed on each of the first TB and the second TB.

Clause 6: The method of Clause 5, wherein a modulation order of the UCI multiplexed on the first TB follows a modulation order of the first TB, and the UCI multiplexed on the second TB follows a modulation order of the second TB.

Clause 7: The method of Clause 5, wherein coded bits of the UCI multiplexed on the first TB are rate matched separately from coded bits of the UCI multiplexed on the second TB.

Clause 8: The method of Clause 5, wherein: the UCI is multiplexed on same REs across layers of the first TB and the second TB; and the UCI multiplexed on the first TB is a replica of the UCI multiplexed on the second TB.

Clause 9: The method of Clause 5, wherein: a first set of coded bits of the UCI is multiplexed on the first TB; and a second set of coded bits of the UCI is multiplexed on the second TB.

Clause 10: The method of any one of Clauses 1-9, wherein the determination of how to multiplex the UCI on the PUSCH is based on a type of the UCI.

Clause 11: The method of Clause 10, wherein: UCI of a first type is multiplexed on each of the first TB and the second TB; and UCI of a second type is multiplexed on either the first TB or the second TB.

Clause 12: The method of Clause 10, wherein: UCI of a first type is multiplexed on the first TB; and UCI of a second type is multiplexed on the second TB.

Clause 13: The method of Clause 12, wherein the UCI is multiplexed on different REs across layers of the first TB and the second TB.

Clause 14: The method of Clause 12, wherein the UCI is multiplexed on same REs across layers of the first TB and the second TB.