Multiple uplink control information multiplexing in coded physical uplink shared channel transmissions

Abstract

Systems, methods, processors, and circuitries are provided to support multiple UCI multiplexing on coded PUSCH. In one example, a method includes identifying a first scheduled PUSCH transmission that overlaps in a first slot with a first scheduled PUCCH transmission for communicating first UCI and a second scheduled PUSCH transmission that overlaps in a second slot with a second PUCCH transmission for communicating second UCI, wherein the first scheduled PUSCH transmission and the second scheduled PUSCH transmission correspond to respective PUSCH repetitions of a series of PUSCH repetitions that are spread based on a coding scheme; multiplexing at least a portion of the first UCI and at least a portion of the second UCI with data carried by the PUSCH repetitions to generate a multiplexed PUSCH transmission corresponding to one of the series of PUSCH repetitions; and providing the multiplexed PUSCH transmission to RF circuitry for transmission.

Description

MULTIPLE UPLINK CONTROL INFORMATION MULTIPLEXING IN CODED PHYSICAL UPLINK SHARED CHANNEL TRANSMISSIONSFIELD

[0001] This disclosure relates to wireless communication networks including techniques for improving network performance using orthogonal cover codes (OCCs) .BACKGROUND

[0002] As the number of mobile devices within wireless networks, and the demand for mobile data traffic, continue to increase, changes are made to system requirements and architectures to better address current and anticipated demands. For example, some wireless communication networks may be developed to implement fifth generation (5G) or new radio (NR) technology, sixth generation (6G) technology, and so on. An aspect of such technology includes addressing how communication techniques may be extended as radio network components are implemented in non-terrestrial platforms.BRIEF DESCRIPTION OF THE DRAWINGS

[0003] The present disclosure will be readily understood and enabled by the detailed description and accompanying figures of the drawings. Like reference numerals may designate like features and structural elements. Figures and corresponding descriptions are provided as non-limiting examples of aspects, implementations, etc., of the present disclosure, and references to "an" or “one” aspect, implementation, etc., may not necessarily refer to the same aspect, implementation, etc., and may mean at least one, one or more, etc.

[0004] FIG. 1 is a diagram of an example non-terrestrial network (NTN) .

[0005] FIG. 2 is a resource element grid illustrating an example of uplink control information multiplexed in a physical uplink shared channel (PUSCH) transmission.

[0006] FIG. 3 is a flow diagram of an example of PUSCH transmission with repetition.

[0007] FIG. 4 illustrates an example of intra-slot OCC spreading without repetition increase due to OCC coding, in accordance with various aspects disclosed.

[0008] FIGs. 5A, 5B, 5C illustrate examples of intra-slot OCC spreading with repetition increase due to OCC coding, in accordance with various aspects disclosed.

[0009] FIGs. 6A, 6B, 6C, 6D illustrate examples of inter-slot OCC spreading with repetition increase due to OCC coding, in accordance with various aspects disclosed.

[0010] FIG. 7 illustrates two scheduled PUCCH transmissions that overlap with two scheduled OCC-based PUSCH transmissions in a first coding cycle and are multiplexed with two  OCC-based PUSCH transmissions in a next coding cycle, in accordance with various aspects described.

[0011] FIG. 8 illustrates an example of separate encoding of UCI for multiplexing in OCC-based PUSCH transmissions, in accordance with various aspects described.

[0012] FIGs. 9A and 9B are resource element grids illustrating respective examples of two UCI multiplexed in OCC-based PUSCH transmissions, in accordance with various aspects described.

[0013] FIG. 10 illustrates an example of separate encoding of UCI for multiplexing in OCC-based PUSCH transmissions, in accordance with various aspects described.

[0014] FIGs. 11A and 11B illustrate DM-RS positioning constraints in OCC-based PUSCH transmissions.

[0015] FIG. 12 is a flow diagram outlining an example method for multiplexing multiple UCI in OCC-based PUSCH transmissions, in accordance with various aspects described.

[0016] FIG. 13 is a flow diagram outlining an example method for multiplexing multiple UCI in OCC-based PUSCH transmissions, in accordance with various aspects described.

[0017] FIG. 14 is a flow diagram outlining an example method for selecting symbols for carrying DM-RS in OCC-based PUSCH transmissions, in accordance with various aspects described.

[0018] FIG. 15 is a flow diagram outlining an example method for selecting symbols for carrying DM-RS in OCC-based PUSCH transmissions, in accordance with various aspects described.

[0019] FIG. 16 is a flow diagram outlining an example method for configuring a combined coding scheme for OCC-based PUSCH transmissions, in accordance with various aspects described.

[0020] FIG. 17 is a flow diagram outlining an example method for configuring a combined coding scheme for OCC-based PUSCH transmissions, in accordance with various aspects described.

[0021] FIG. 18 is a functional block diagram of a wireless communication network, in accordance with various aspects described.

[0022] FIG. 19 illustrates a simplified block diagram of a user equipment device, in accordance with various aspects described.DETAILED DESCRIPTION

[0023] The following detailed description refers to the accompanying drawings. Like reference numbers in different drawings may identify the same or similar features, elements,  operations, etc. Additionally, the present disclosure is not limited to the following description as other implementations may be utilized, and structural or logical changes made, without departing from the scope of the present disclosure.

[0024] Wireless communication networks may include user equipment (UEs) , base stations, and / or other types of wireless devices capable of communicating with one another. 5G Release 17 established standards for non-terrestrial network (NTN) based communication. FIG. 1 illustrates a wireless network in which multiple UEs 110 located in an NTN cell are served by a satellite 160. CONNECTED UEs 110 communicate control information by way of physical uplink control channel (PUCCH) transmissions and uplink data by way of physical uplink shared channel (PUSCH) transmissions. The area covered by an NTN cell may be on the order of millions of square kilometers and likely will encompass many more UEs than typical land networks. Thus to improve NTN communication enhancements to uplink communication, such as support for code-division multiple access (CDMA) , may be considered to enable multiple UEs to utilize the same or similar time / frequency resources for transmitting PUSCH messages.

[0025] Another potential challenge in NTN networks is that UEs may not be capable of transmitting uplink signals with sufficient strength to be properly received by a satellite-based radio access network (RAN) node. Thus configuration of PUSCH transmission with repetitions may be supported so that received repeated PUSCH transmissions may be aggregated by the RAN node to compensate for reduced uplink signal strength. Of course, such repetitions reduce throughput and increase latency.

[0026] One technique for reducing latency and reliability of uplink communication is to support the multiplexing of uplink control information (UCI) . UCI, which may otherwise be communicated in physical uplink control channel (PUCCH) transmissions, is multiplexed with a PUSCH transmission that overlaps the scheduled PUCCH transmission. In this manner, UCI may be communicated in the overlapping PUSCH transmission rather than transmitting simultaneous PUCCH and PUSCH transmissions.

[0027] UCI Multiplexing on PUSCH Overview

[0028] UCI carries control signals from the UE to the RAN node. Generally the PUCCH carriers UCI and the PUSCH carries uplink user data (UL-SCH data) . However, as noted above, when a PUCCH transmission configured to carry the UCI overlaps a PUSCH transmission, the PUSCH transmission may also carry selected control information from the overlapping PUCCH transmission. The types of UCI that may be multiplexed with PUSCH transmissions include hybrid automatic repeat request acknowledge / non-acknowledge (HARQ-ACK) and channel state information (CSI) report. The CSI report includes two parts CSI Part 1 and CSI Part 2. The RAN node uses information from CSI Part 1 to decode CSI Part 2.

[0029] In the multiplexing process, the UL-SCH data and the UCI values (e.g., HARQ-ACK and / or CSI report) are encoded separately. The encoded UL-SCH data, the encoded HARQ-ACK, and / or the encoded CSI Part 1 and CSI Part 2 are multiplexed according to a UCI multiplexing rule outlined in TS 38.212 Section 6.2.7. An example resource grid 200 for a slot including 14 OFDM symbols is illustrated in FIG. 2, with each box corresponding to a resource element (RE) . The UCI multiplexing rule will not be described in detail, but some relevant steps are as follows. DM-RS RE locations are based on PUSCH DM-RS configuration and no UCI bits may be mapped to symbols that include the DM-RS resource elements. When the UCI includes 1 or 2 HARQ-ACK bits, in a first step a number of HARQ-ACK resource elements are reserved in the symbol after the first symbol containing DM-RS based on the rate matching length of the HARQ-ACK bits being set to 2 and according to the following formula:

[0030] EQUATION 1

[0031] where

[0032] -Ns is the value of numberOfSlots TBoMS in the row indicated by the Time domain resource assignment field in DCI;

[0033] - is the number of subcarriers in OFDM symbol l that carries PTRS, in the PUSCH transmission of TB processing over multiple slots in the slot with the HARQ-ACK transmission;

[0034] - is the number of resource elements that can be used for transmission of UCI in OFDM symbol l, for in the PUSCH transmission of TB processing over multiple slots in the slot with the HARQ-ACK transmission and is the total number of OFDM symbols of the PUSCH in the slot, including all OFDM symbols used for DMRS;

[0035] -l0 is the symbol index of the first OFDM symbol that does not carry DMRS of the PUSCH, after the first DMRS symbol (s) , in the PUSCH transmission of TB processing over multiple slots in the slot with the HARQ-ACK transmission;

[0036] -and all the other notations in the formula are defined the same as for PUSCH not using repetition type B and if numberOfSlotsTBoMS is not present in the resource allocation table.

[0037] In FIG. 2, the calculated REs (shown in grid hashing) are reserved in the fourth symbol, which is the symbol after the symbol that includes the DM-RS. No mapping of the HARQ-ACK bits is performed in this step, these REs are considered as reserved for the purposes of UCI mapping. The first step of reserving REs for HARQ-ACK is only performed when there are 1 or 2 HARQ-ACK bits.

[0038] After this optional reservation step, in a second step, the UCI (including HARQ-ACK of more than 2 bits) is mapped to unmapped REs and then the UL-SCH is mapped to remaining REs. In particular, for HARQ-ACK having more than 2 bits, the coded HARQ-ACK  bits are mapped to the first symbol after the first OFDM symbol that contains DM-RS. The coded CSI Part 1 and CSI Part 2 bits are mapped to the starting OFDM symbol that is unused for DM-RS in the shared channel symbol allocation and to consecutive non-DMRS OFDM symbols while avoiding any reserved REs from step 1. The coded UL-SCH data bits are then mapped to all remaining REs, including any reserved HARQ-ACK REs. In the final step, when there are 1 or 2 HARQ-ACK bits, the coded HARQ-ACK bits are mapped to the reserved HARQ-ACK REs, which will result in puncturing the UL-SCH bits previously mapped to the reserved REs. The codeword is formed by reading the bits in a frequency first time second approach at each RE other than DM-RS REs.

[0039] PUSCH Repetition Overview

[0040] In an effort to improve the reliability of PUSCH transmissions, PUSCH repetitions may be configured. Two types of PUSCH repetitions may be configured. In type A PUSCH repetition, the UE repeats the PUSCH transmission in the same time domain resource in a number of immediately subsequent slots. In type B PUSCH repetition, the repetitions may occur with a same slot. In some configurations the repetitions may be encoded according to a different redundancy version (RV) in which bits encoding the PUSCH are placed in a circular buffer and a different starting point in the circular buffer is used to select a sequence of bits for transmission in a given repetition. The different starting points correspond to different RVs. A sequence of RVs (e.g., RV 0, RV 2, RV 3, RV 1, or other pattern) may be preconfigured for use in a cyclic manner in PUSCH repetition.

[0041] FIG. 3 illustrates an overview of PUSCH transmission with repetition. A UE is configured with a repetition number K and a delay time k2 by radio resource control (RRC) signaling. At 320, the RAN node transmits physical downlink control channel (PDCCH) transmission or downlink control information (DCI) that schedules the UE to transmit uplink data. The DCI or previous configuration may also indicate a sequence of redundancy versions for use in the PUSCH repetitions. The PDCCH / DCI may be in response to a scheduling request (SR) from the UE. In some examples, the UE is triggered to transmit uplink data based on configured grant configuration of uplink transmissions that are activated or deactivated by DCI. In some examples, the UE is triggered to transmit uplink data based on a configured grant.

[0042] The UE waits until expiration of the delay time k2 and then at 330 transmits a first redundancy version of the PUSCH. At 340-390, in the next K-1 slots (type A repetition) or K-1 configured transmission times (type B repetition) , the UE transmits a next redundancy version of the PUSCH. The PUSCH repetitions may be aggregated by the RAN node for decoding.

[0043] Orthogonal Cover Code Overview

[0044] Code division multiple access (CDMA) is a technique that is used to allow multiple  UEs to communicate with a base station using the same time / frequency resources. To enable CDMA, an orthogonal cover code (OCC) may be used to “spread” bits encoding transmissions to generate discrete Fourier transform spread orthogonal frequency division multiplexing (DFT-s-OFDM) based waveforms. An OCC is defined by a code length and includes a set of unique code sequences. The code sequences comprise an ordered series of values that are applied to (e.g., multiply) consecutive modulation symbols before DFT operations in the frequency domain (FD-OCC) or (pre-DFT OCC) , consecutive symbols in a slot (intra-slot OCC) , or across multiple consecutive slots (inter-slot OCC) in which all symbols in a slot are coded by the same code value in the sequence of code values. The coding results in a waveform that is orthogonal in either frequency (FD-OCC) or time (intra-slot or inter-slot OCC) to other waveforms generated based on other sequences in the OCC.

[0045] 3GPP TS 38.211 specifies supported OCC sequences in Table 6.3.2.6.3. For example, a supported OCC of length 2 includes sequences [1, 1] and [1, -1] . The number of UEs that may communicate using DFT-s-OFDM waveforms is determined based on the number of code sequences in the OCC. In order to spread a PUSCH transmission, the UE needs to acquire information regarding an OCC sequence (e.g., an OCC sequence index) and length. The length of the OCC sequence is equal to the number of OCC sequences in the OCC and also the number of UEs that may multiplex UL signals using the OCC.

[0046] When OCC spreading is used for PUSCH (with or without repetitions) additional OFDM symbols or resource blocks (RBs) may be added based on the OCC. The OCC configuration by the network may indicate whether or not addition repetitions are to be added due to OCC.

[0047] When additional repetitions are not to be added based on the OCC, the number of RBs or OFDM symbols communicated in a transport block (TB) is reduced based on the length of the OCC sequence. For example, if the length of the OCC sequence is two, then half as many RBs or OFDM symbols may be communicated in a TB due to the coding. FIG. 4 illustrates a slot in which OCC spreading based on an OCC sequence [1, -1] (of length 2) reduces the number of OFDM symbols that could be communicated without coding from 14 to 7. It can be seen that the slot includes, for each original OFDM symbol S (n) , a corresponding –S (n) . S (n) is the result of the first sequence value (1) multiplied by the original OFDM symbol. –S (n) is the result of the second sequence value (-1) multiplied by the original OFDM symbol. S2 and –S2 carry demodulation reference symbols (DMRS) and are placed near the beginning and end of the slot. A similar reduction in RBs occurs in FD-OCC without additional repetitions due to OCC.

[0048] In other examples, the number of OFDM symbols or RBs is increased by a factor of the length of the OCC sequence. The total number of repetitions of the PUSCH is equal to a  number of configured repetitions *the OCC sequence length (e.g., 2 in the illustrated example) .

[0049] FIGs. 5A-5C illustrate various example coding mechanisms or conventions for handling repetitions and RV cycling in intra-slot OCC or FD-OCC, where the sequence values are applied on a per symbol or RB basis as illustrated in FIG. 4. The configured repetition number is 4 and the configured RV cycling sequence is 0, 2, 3, 1. In FIG. 5A, a PUSCH is spread to a sequence of eight (OCC length 2 *configured repetition number 4) OCC coded slots 510 based on repetition first, RV cycling second. In FIG. 5B, a PUSCH is spread to a sequence of eight OCC coded slots 520 based on RV cycling first, repetition second. In FIG. 5C, a PUSCH is spread to a sequence of eight OCC coded slots 530 based on repetition only, without RV cycling.

[0050] FIGs. 6A-6D illustrate various example coding mechanisms or conventions for handling configured repetitions and RV cycling in inter-slot OCC, where the sequence values are applied on a per slot basis (e.g., all symbols in the each slot have the same coding value applied) . The configured repetition is 2 and the configured RV cycling sequence is 0, 2, 3, 1. In FIG. 6A, a PUSCH is spread to a sequence of eight OCC coded slots 610 based on OCC spread first, RV cycling second. In FIG. 6B, a PUSCH is spread to a sequence of eight OCC coded slots 620 based on RV cycling first, OCC spread second. In FIG. 6C, a PUSCH is spread to a sequence of eight OCC coded slots 630 based on no RV cycling, OCC spread first, repetition second. In FIG. 6D, a PUSCH is spread to a sequence of eight OCC coded slots 640 based on no RV cycling, repetition first, OCC spread second.

[0051] Described herein are systems, methods, and circuitries that provide techniques for supporting multiple UCI multiplexing for OCC-based PUSCH transmission with repetitions. Mechanisms are provided for separate and joint processing of UCIs during the encoding process. Solutions regarding alignment of PUSCH DM-RS in multiplexed PUCH transmissions and signaling for configuring two levels of coding in PUSCH are also proposed.

[0052] FIG. 7 is a timing diagram illustrating a scenario where two PUCCH transmissions in different slots overlap two OCC-based PUSCH repetition transmissions. In the illustrated example, the PUSCH repetition number is 4. The PUSCH repetition transmissions are spread on an inter-slot basis with an OCC code having a length of 2 with values [1 -1] . Thus the four OCC-based PUSCH repetition transmissions 720 (1) -720 (4) are spread over two coding cycles. In other examples, different coding schemes and code lengths as well as different repetition numbers may be applied without affecting the disclosed techniques.

[0053] A first scheduled PUCCH transmission 710 that includes first UCI overlaps with a first scheduled OCC-based PUSCH repetition transmission 720 (1) . A second scheduled PUCCH transmission 715 that includes second UCI overlaps with a second scheduled OCC-based  PUSCH repetition transmission 720 (2) . In the disclosed solutions, both UCI 1 and UCI 2 may be multiplexed on one or more of the scheduled OCC-based PUSCH repetition transmissions. In the example illustrated in FIG. 7, UCI 1 and UCI 2 are multiplexed in scheduled OCC-based PUSCH repetition transmissions in a next coding cycle 720 (3) , 720 (4) . However the techniques disclosed herein may be applied regardless of which scheduled OCC-based PUSCH repetition transmissions are selected for multiplexing with UC1 1 and UCI 2. Further, the disclosed solutions may be extended to include multiplexing of more than two UCIs in OCC-based PUSCH repetition transmissions. The disclosed solutions are provided in the context of multiplexing UCI that includes only HARQ-ACK bits. The disclosed solutions may be extended to include multiplexing UCI that includes channel state information (CSI) instead of or in addition to HARQ-ACK bits.

[0054] Multiplexing Two UCIs with Separate Encoding of UCIs

[0055] As illustrated in FIG. 8, each UCI may be separately encoded and processed prior to mapping to the PUSCH transmission. For example, UCI 1 may be processed based on a cyclic redundancy code (CRC) in operation 830, if necessary, then the spreading code (e.g., OCC code) may be applied to the UCI 1 in operation 840 and the resulting coded UCI 1 bits may be modulated in operation 850. UCI 2 may be processed based on a cyclic redundancy code (CRC) in operation 860, if necessary, then the spreading code (e.g., OCC code) may be applied to the UCI 2 in operation 870 and the resulting coded UCI 2 bits may be modulated in operation 880. The resulting encoded UCI 1 bits and UCI 1 bits may then be mapped in operation 890 as described below. Recall from FIG. 2 that in mapping UCI to PUSCH there is an optional first step in which REs are reserved for small (less than 2 bits) HARQ-ACK and there is a second step in which HARQ-ACK greater than 2 bits are mapped prior to the mapping of any UL-SCH data. A codeword is formed from the mapped REs for the multiplexed PUSCH transmission.

[0056] When the number of HARQ-ACK bits in UCI 1 and UCI 2 is less than 2 bits (e.g., 1 or 2 bits) , an individual payload approach or a total payload approach may be used to multiplexing. In the individual payload approach, the number of reserved HARQ-ACK REs is achieved by calculating the rate-matching length of the HARQ-ACK for both of the UCIs, each with the number of HARQ-ACK bits set to 2. The following formula for determining the number of reserved REs, which is an adaption of Equation 1 above, may be used.

[0057] Equation 2

[0058] In Equation 2, OACK, i is the number of HARQ-ACK bits for the i-th slot for  multiplexing, LACK, i  is the number of CRC bits for the i-th slot for multiplexing,  is the offset for HARQ-ACK for the i-th slot for multiplexing,  is the number of resource elements that can be used for UCI transmission in OFDM symbol l, and α is configured by higher layer parameter “scaling” . An existing configured scaling value may be used or a new scaling value may be configured for multiplexing 2 or more UCIs on OCC-based PUSCH. FIG. 9A illustrates the reserved REs that result from Equation 2.

[0059] After the REs are reserved for UCI 1 and UCI 2, UL-SCH data is mapped followed by mapping of the UCI 1 bits and the UCI 2 bits.

[0060] When the PUSCH does not carry data, the number of coded modulation symbols per layer (where are is the total number of layers) may be calculated based on Equation 3.

[0061] Equation 3

[0062] In another individual payload based approach, when the both UCI 1 and UCI 2 have more than 2 bits carrying HARQ-ACK, then the optional RE reservation step is skipped and the coded UCI 1 bits and coded UCI 2 bits are concatenated in time order and mapped in the first symbol after the symbol carrying the first DM-RS.

[0063] In one total payload based approach, the total number of HARQ-ACK bits in UCI 1 and UCI 2 is used to determine the mapping method. In one example, if the total number of bits is 2 then the same scheme as outlined with reference to FIG. 9A is followed, in which REs are reserved for UCI 1 and UCI 2, prior to mapping of UL-SCH data and coded UCI 1 bits and UCI 2 bits.

[0064] In another total payload based approach, when the total number of HARQ-ACK bits in UCI 1 and UCI 2 is more than 2 bits, then the optional RE reservation step is skipped and the coded UCI 1 bits and coded UCI 2 bits are concatenated in time order and mapped in the first symbol after the symbol carrying the first DM-RS.

[0065] When UCI 1 has 1 or 2 bits carrying HARQ-ACK and UCI 2 has more than 2 bits carrying HARQ-ACK, in one approach the optional RE reservation step is skipped and the coded UCI 1 bits and the coded UCI 2 bits are concatenated in time order and mapped in the first symbol after the symbol carrying the first DM-RS.

[0066] When UCI 1 has 1 or 2 bits carrying HARQ-ACK and UCI 2 has more than 2 bits carrying HARQ-ACK, in another approach, REs are reserved for UCI 1 bits as disclosed above, and the UCI 2 bits are mapped prior to mapping the UL-SCH data. The mapping of the UCI 2 bits avoids the reserved REs for the UCI 1 bits. FIG. 9B illustrates this example case where REs  for UCI 1 bits are reserved and the UCI 2 bits are mapped.

[0067] Multiplexing Two UCIs with Joint Encoding of UCIs

[0068] FIG. 10 illustrates joint encoding and processing of UCI 1 and UCI 2 prior to mapping to the OCC-based PUSCH transmission. In this example, UCI 1 and UCI 2 carry only HARQ-ACK bits. In joint encoding, the UCI 1 and UCI 2 bits are concatenated in time order to form combined UCI bits. The concatenated UCI bits may be processed based on a cyclic redundancy code (CRC) in operation 1060, if necessary, then the spreading code (e.g., OCC code) may be applied to the combined UCI bits in operation 870 and the bits may be modulated in operation 880. The coded combined UCI bits may then be mapped in operation 1090 as described below. A codeword is formed from the mapped REs for the multiplexed PUSCH transmission.

[0069] In one example, if the number of combined UCI bits is 1 or 2 then the two step scheme as is followed, in which REs are reserved for the combined UCI bits, prior to resource mapping of UL-SCH data and the combined UCI bits. When the number of combined UCI bits is more than 2 bits, then the optional RE reservation step is skipped and the coded combined UCI bits are mapped in the first symbol after the symbol carrying the first DM-RS.

[0070] In another approach, regardless of the number of combined UCI bits, the optional RE reservation step is skipped and the coded combined UCI bits are mapped in the first symbol after the symbol carrying the first DM-RS.

[0071] Since the number of HARQ-ACK bits corresponding to each of the UCIs in the combined UCI bits may be different, a dynamic (type 2) codebook may be used for each slot. In one example, the downlink grant downlink control information (DCI) includes a new 1-bit field “carryover from different slot” . When the bit is 0, it indicates that there is no carryover from the previous HARQ-ACK codebook. When the bit is 1, it indicates that there is carryover from the previous HARQ-ACK codebook, or in other words, the HARQ-ACK codebook from the previous slot continues into this HARQ-ACK codebook.

[0072] The uplink (UL) grant DCI may include two UL downlink assignment index (DAI) bit-fields (assuming up to 2 PUCCH with HARQ-ACK can overlap with OCC-based PUSCH repetition transmissions) . In this example, the first UL DAI field corresponds to the first HARQ-ACK codebook and the second UL DAI field corresponds to the second HARQ-ACK codebook.

[0073] In another example, the UL DAI bit field in the UL grant DCI may be applied to all HARQ-ACK bits. For example, if the UE detects a first PUCCH with 2 bits of HARQ-ACK overlapping a first OCC-based PUSCH repetition and a second PUCCH with 3 bits of HARQ-ACK overlapping a second OCC-based PUSCH repetition, the UL DAI in the UL DCI may indicate 3 (the higher number of HARQ-ACK bits) . In this case, 2 bits from the first UCI + 1 bit  NACK (padding to get to 3 bits) + 3 bits from the second UCI are jointly encoded to form the combined UCI bits.

[0074] DM-RS Alignment in OCC-Based PUSCH Repetition Transmissions

[0075] DM-RS symbol alignment as between UEs that are code-division multiplexed in OCC-based PUSCH transmissions may be required in certain coding scenarios. FIG. 11A illustrates a first OCC-based PUSCH transmission 400 transmitted by a first UE and a second OCC-based PUSCH transmission 410 transmitted by a second UE. In this example, when the coding is inter-symbol (as shown) or intra-symbol, the PUSCH DM-RS symbols should be aligned in time among all OCC-based PUSCH transmissions. This may be achieved via network implementation.

[0076] FIG. 11B illustrates a first OCC-based PUSCH transmission 420 transmitted by a first UE and a second OCC-based PUSCH transmission 430 transmitted by a second UE. In this example, when the coding is inter-slot (as shown) , the PUSCH DM-RS symbols should be aligned in time across OCC-based PUSCH transmissions from the same UE. However, the PUSCH DM-RS symbols do not need to be aligned in time across OCC-based PUSCH transmissions from different UEs.

[0077] Signaling of OCC Operations

[0078] It may be desirable to support the combination of OCC schemes. For example, inter-slot OCC and intra-symbol OCC (PreDFT coding) may be combined. In another example, inter-symbol OCC and intra-symbol OCC may be combined. New signaling may be introduced to indicate the length and coding sequence of both OCC schemes to support such combined OCC schemes.

[0079] In one example, in type 1 configured grant for OCC-based PUSCH transmissions, the two OCC schemes are included in a radio resource control (RRC) configuration, such as, for example, ConfiguredGrantConfig as follows:

[0080] In another example, in type 2 configured grant for OCC-based PUSCH transmissions, OCC-Length-TD / OCC-Sequence-TD / OCC-Length-PreDFT / OCC-Sequence-PreDFT may be added to the configured grant configuration. Alternatively, OCC-Length-TD / OCC-Sequence-TD / OCC-Length-PreDFT / OCC-Sequence-PreDFT may be indicated in the activation DCI.

[0081] In another example, in dynamic grant OCC-based PUSCH transmissions, OCC-Length-TD / OCC-Sequence-TD / OCC-Length-PreDFT / OCC-Sequence-PreDFT may be included in grant DCI fields. Alternatively, multiple OCC-Length-TD / OCC-Sequence-TD / OCC-Length-PreDFT / OCC-Sequence-PreDFT configurations may be provided in a dedicated RRC configuration, and a selection of configuration may be provided (aconfiguration may be activated / deactivated) by medium access control element (MAC CE) or indicated in DCI.

[0082] FIG. 12 is a flow diagram outlining a method 1200 for multiplexing multiple UCI in coded PUSCH transmissions (e.g., OCC-based PUSCH transmission) . The method may be performed by a UE 110 of FIG. 1. At 1210, the method includes identifying a first scheduled PUSCH transmission that overlaps in a first slot with a first scheduled PUCCH transmission for communicating first UCI and a second scheduled PUSCH transmission that overlaps in a second slot with a second PUCCH transmission for communicating second UCI, wherein the first scheduled PUSCH transmission and the second scheduled PUSCH transmission correspond to respective PUSCH repetitions of a series of PUSCH repetitions that are spread based on a coding scheme. One example of such a PUCCH / PUSCH overlap scenario is illustrated in FIG. 7.

[0083] At 1220, the method includes multiplexing at least a portion of the first UCI and at least a portion of the second UCI with data carried by the PUSCH repetitions to generate a multiplexed PUSCH transmission corresponding to one of the series of PUSCH repetitions, and, at 1230, providing the multiplexed PUSCH transmission to radio frequency (RF) circuitry for transmission. The PUSCH repetitions may be spread by an OCC and / or on an inter-slot basis.

[0084] In some examples, the method includes separately encoding and processing the first UCI bits and the second UCI bits prior to resource mapping into the PUSCH transmission. Based on a number of HARQ-ACK bits carried by each UCI, a first step of reserving REs for HARQ-ACK may or may not be performed as described above. The determination as to whether the first step of reserving REs for HARQ-ACK bits may be based on the number of HARQ-ACK bits in each UCI or on a total number of bits in both UCI.

[0085] In some examples, the method includes jointly encoding and processing the first UCI bits and the second UCI bits to generate combined UCI bits prior to resource mapping into the PUSCH transmission. Based on a number of HARQ-ACK bits carried by the combined UCI bits, a first step of reserving REs for HARQ-ACK may or may not be performed as described above. In some examples, the method includes decoding downlink control information (DCI) to determine a type 2 HARQ-ACK codebook for the combined UCI bits, wherein the DCI includes at least one bit indicating whether the type 2 HARQ-ACK codebook carries HARQ-ACK bits for PDSCH transmission in a previous slot. In some examples, the method includes decoding DCI to determine a type 2 HARQ-ACK codebook the combined UCI bits, wherein the DCI includes a  first uplink downlink assignment index (DAI) field that indicates a number of bits in the HARQ-ACK codebook for the first UCI and a second uplink DAI field that indicates a number of bits in the HARQ-ACK codebook for the second UCI. In some examples, the method includes decoding DCI to determine a type 2 HARQ-ACK codebook for the combined UCI bits, wherein the DCI includes an uplink DAI field that indicates a number of bits in the HARQ-ACK codebook for each of the first UCI and the second UCI.

[0086] FIG. 13 is a flow diagram outlining a method 1300 for multiplexing multiple UCI in coded PUSCH transmissions (e.g., OCC-based PUSCH transmission) . The method may be performed by a RAN node disposed on a satellite 160 of FIG. 1. At 1310, the method includes identifying a first scheduled PUSCH transmission that overlaps in a first slot with a first scheduled PUCCH transmission for communicating first UCI and a second scheduled PUSCH transmission that overlaps in a second slot with a second PUCCH transmission for communicating second UCI, wherein the first scheduled PUSCH transmission and the second scheduled PUSCH transmission correspond to respective PUSCH repetitions of a series of PUSCH repetitions that are spread based on a coding scheme. One example of such a PUCCH / PUSCH overlap scenario is illustrated in FIG. 7.

[0087] At 1320, the method includes receiving a multiplexed PUSCH transmission that includes at least a portion of the first UCI and at least a portion of the second UCI multiplexed in the PUSCH, wherein the received multiplexed PUSCH transmission corresponds to one of the series of PUSCH repetitions. At 1330, the method includes de-multiplexing the received the multiplexed PUSCH to decode the at least a portion of the first UCI and the at least a portion of the second UCI. The PUSCH repetitions may be spread by an OCC and / or on an inter-slot basis.

[0088] In some examples, the first UCI bits and the second UCI bits are separately encoded and processed prior to resource mapping into the multiplexed PUSCH transmission. Based on a number of HARQ-ACK bits carried by each UCI, a first step of reserving REs for HARQ-ACK may or may not be performed as described above. The determination as to whether the first step of reserving REs for HARQ-ACK bits may be based on the number of HARQ-ACK bits in each UCI or on a total number of bits in both UCI.

[0089] In some examples, the first UCI bits and the second UCI bits are jointly encoded and processed to generate combined UCI bits prior to resource mapping into the multiplexed PUSCH transmission. Based on a number of HARQ-ACK bits carried by the combined UCI bits, a first step of reserving REs for HARQ-ACK may or may not be performed as described above. In some examples, the method includes transmitting downlink control information (DCI) that indicates a type 2 HARQ-ACK codebook for the combined UCI bits, wherein the DCI includes at least one bit indicating whether the type 2 HARQ-ACK codebook carries HARQ-ACK bits for  PDSCH transmission in a previous slot. In some examples, the method includes transmitting DCI that indicates a type 2 HARQ-ACK codebook the combined UCI bits, wherein the DCI includes a first uplink downlink assignment index (DAI) field that indicates a number of bits in the HARQ-ACK codebook for the first UCI and a second uplink DAI field that indicates a number of bits in the HARQ-ACK codebook for the second UCI. In some examples, the method includes transmitting a DCI that indicates a type 2 HARQ-ACK codebook for the combined UCI bits, wherein the DCI includes an uplink DAI field that indicates a number of bits in the HARQ-ACK codebook for each of the first UCI and the second UCI.

[0090] FIG. 14 is a flow diagram outlining a method 1400 for encoding PUSCH transmissions (e.g., OCC-based PUSCH transmissions) with DM-RS in selected symbols based on coding scheme. The method may be performed, for example, by UEs 110 of FIG. 1. The method includes, at 1410, encoding a PUSCH transmission and spreading the PUSCH transmission based on coding scheme. Symbols in the PUSCH transmission carrying demodulation reference signals (DM-RS) are selected based on the coding scheme. The method includes, at 1420, providing the PUSCH transmission to the RF circuitry for transmission.

[0091] When the coding scheme is applied on an inter-symbol or intra-symbol basis, the same symbols are selected for carrying DM-RS as compared to symbols carrying DM-RS in PUSCH transmissions from other UEs. When the coding scheme is applied on inter-slot basis, the symbols are selected for carrying DM-RS independent of symbols carrying DM-RS in PUSCH transmissions from other UEs.

[0092] FIG. 15 is a flow diagram outlining a method 1500 for configuring PUSCH transmissions (e.g., OCC-based PUSCH transmissions) with DM-RS in selected symbols based on coding scheme. The method may be performed by a RAN node disposed on a satellite 160 of FIG. 1. The method includes, at 1510, selecting symbols for carrying DM-RS in PUSCH configuration based on a coding scheme of the PUSCH. The method includes, at 1520, receiving coded PUSCH transmissions according to the PUSCH configuration.

[0093] When the coding scheme is applied on an inter-symbol or intra-symbol basis, the same symbols are selected for carrying DM-RS as compared to symbols carrying DM-RS in PUSCH transmissions from other UEs. When the coding scheme is applied on inter-slot basis, the symbols are selected for carrying DM-RS independent of symbols carrying DM-RS in PUSCH transmissions from other UEs.

[0094] FIG. 16 is a flow diagram outlining a method 1600 for configuring combined coding of PUSCH transmissions. The method may be performed, for example, by UEs 110 of FIG. 1. The method includes, at 1610 receiving configuration of a PUSCH transmission that configures a combined coding scheme including first coding scheme that is applied on an inter-slot basis or  inter-symbol basis and a second coding scheme that is applied on an intra-symbol basis. At 1620, the method includes coding the PUSCH transmission based on the configuration and providing the coded PUSCH transmission to radio frequency circuitry for transmission.

[0095] In some examples, the method includes receiving the configuration in a radio resource control (RRC) type 1 configured grant configuration, type 2 configured grant configuration, or a dedicated configuration for PUSCH transmission with two coding schemes. In some examples, the method includes receiving multiple configurations of the first coding scheme and the second coding scheme; and receiving downlink control information (DCI) that schedules the PUSCH transmission or activates a type 2 configured grant that indicates a selection from among the multiple configurations. In some examples, the method includes receiving the configuration in DCI that schedules the PUSCH transmission.

[0096] FIG. 17 is a flow diagram outlining a method 1700 for configuring combined coding of PUSCH transmissions. The method may be performed by a RAN node disposed on a satellite 160 of FIG. 1. The method includes, at 1710, transmitting configuration of a physical uplink shared channel (PUSCH) transmission that configures a two level coding scheme comprising a first coding scheme that is applied on an inter-slot basis or inter-symbol basis and a second coding scheme that is applied on an intra-symbol basis. At 1720, the method includes decoding a received PUSCH transmission based on the configuration.

[0097] In some examples, the method includes transmitting the configuration in a radio resource control (RRC) type 1 configured grant configuration, type 2 configured grant configuration, or a dedicated configuration for PUSCH transmission with two coding schemes. In some examples, the method includes transmitting multiple configurations of the first coding scheme and the second coding scheme; and transmitting downlink control information (DCI) that schedules the PUSCH transmission or activates a type 2 configured grant that indicates a selection from among the multiple configurations. In some examples, the method includes transmitting the configuration in DCI that schedules the PUSCH transmission.

[0098] Above are several flow diagrams outlining example methods and exchanges of messages. In this description and the appended claims, use of the term “determine” with reference to some entity (e.g., parameter, variable, and so on) in describing a method step or function is to be construed broadly. For example, “determine” is to be construed to encompass, for example, receiving and parsing a communication that encodes the entity or a value of an entity. “Determine” should be construed to encompass accessing and reading memory (e.g., lookup table, register, device memory, remote memory, and so on) that stores the entity or value for the entity. “Determine” should be construed to encompass computing or deriving the entity or value of the entity based on other quantities or entities. “Determine” should be construed to  encompass any manner of deducing or identifying an entity or value of the entity.

[0099] As used herein, the term identify when used with reference to some entity or value of an entity is to be construed broadly as encompassing any manner of determining the entity or value of the entity. For example, the term identify is to be construed to encompass, for example, receiving and parsing a communication that encodes the entity or a value of the entity. The term identify should be construed to encompass accessing and reading memory (e.g., device queue, lookup table, register, device memory, remote memory, and so on) that stores the entity or value for the entity.

[0100] As used herein, the term encode when used with reference to some entity or value of an entity is to be construed broadly as encompassing any manner or technique for generating a data sequence or signal that communicates the entity to another component.

[0101] As used herein, the term select when used with reference to some entity or value of an entity is to be construed broadly as encompassing any manner of determining the entity or value of the entity from amongst a plurality or range of possible choices. For example, the term select is to be construed to encompass accessing and reading memory (e.g.,  lookup table, register, device memory, remote memory, and so on) that stores the entities or values for the entity and returning one entity or entity value from amongst those stored. The term select is to be construed as applying one or more constraints or rules to an input set of parameters to determine an appropriate entity or entity value. The term select is to be construed as broadly encompassing any manner of choosing an entity based on one or more parameters or conditions.

[0102] As used herein, the term derive when used with reference to some entity or value of an entity is to be construed broadly. “Derive” should be construed to encompass accessing and reading memory (e.g., lookup table, register, device memory, remote memory, and so on) that stores some initial value or foundational values and performing processing and / or logical / mathematical operations on the value or values to generate the derived entity or value for the entity. The term derive should be construed to encompass computing or calculating the entity or value of the entity based on other quantities or entities. The term derive should be construed to encompass any manner of deducing or identifying an entity or value of the entity.

[0103] As used herein, the term indicate when used with reference to some entity (e.g., parameter or setting) or value of an entity is to be construed broadly as encompassing any manner of communicating the entity or value of the entity either explicitly or implicitly. For example, bits within a transmitted message may be used to explicitly encode an indicated value or may encode an index or other indicator that is mapped to the indicated value by prior configuration. The absence of a field within a message may implicitly indicate a value of an entity based on prior configuration.

[0104] Wireless Network and Device Overview

[0105] FIG. 12 is an example network 1200 according to one or more implementations described herein. Example network 1200 may include UEs 1210-1, 1210-2, etc. (referred to collectively as “UEs 1210” and individually as “UE 1210” ) , a radio access network (RAN) 1220, a core network (CN) 1230, application servers 1240, and external networks 1250. See also UEs 110 of FIG. 1) .

[0106] The systems and devices of example network 1200 may operate in accordance with one or more communication standards, such as 2nd generation (2G) , 3rd generation (3G) , 4th generation (4G) (e.g., long-term evolution (LTE) ) , and / or 5th generation (5G) (e.g., new radio (NR) ) communication standards of the 3rd generation partnership project (3GPP) . Additionally, or alternatively, one or more of the systems and devices of example network 1200 may operate in accordance with other communication standards and protocols discussed herein, including future versions or generations of 3GPP standards (e.g., sixth generation (6G) standards, seventh generation (7G) standards, etc. ) , institute of electrical and electronics engineers (IEEE) standards (e.g., wireless metropolitan area network (WMAN) , worldwide interoperability for microwave access (WiMAX) , etc. ) , and more.

[0107] As shown, UEs 1210 may include smartphones (e.g., handheld touchscreen mobile computing devices connectable to one or more wireless communication networks) . Additionally, or alternatively, UEs 1210 may include other types of mobile or non-mobile computing devices capable of wireless communications, such as personal data assistants (PDAs) , pagers, laptop computers, desktop computers, wireless handsets, watches etc. In some implementations, UEs 1210 may include internet of things (IoT) devices (or IoT UEs) that may comprise a network access layer designed for low-power IoT applications utilizing short-lived UE connections. Additionally, or alternatively, an IoT UE may utilize one or more types of technologies, such as machine-to-machine (M2M) communications or machine-type communications (MTC) (e.g., to exchanging data with an MTC server or other device via a public land mobile network (PLMN) ) , proximity-based service (ProSe) or device-to-device (D2D) communications, sensor networks, IoT networks, and more. Depending on the scenario, an M2M or MTC exchange of data may be a machine-initiated exchange, and an IoT network may include interconnecting IoT UEs (which may include uniquely identifiable embedded computing devices within an Internet infrastructure) with short-lived connections. In some scenarios, IoT UEs may execute background applications (e.g., keep-alive messages, status updates, etc. ) to facilitate the connections of the IoT network.

[0108] UEs 1210 may communicate with one another via one or more wireless channels 1212, each of which may comprise a physical communications interface  / layer. The connection may include an M2M connection, MTC connection, D2D connection, SL connection, etc. The  connection may involve a PC5 interface. In some implementations, UEs 1210 may be configured to discover one another, negotiate wireless resources between one another, and establish connections between one another, without intervention or communications involving RAN node 1222 or another type of network node. In some implementations, discovery, authentication, resource negotiation, registration, etc., may involve communications with RAN node 1222 or another type of network node.

[0109] UEs 1210 may communicate and establish a connection with (e.g., be communicatively coupled) with RAN 1220, which may involve one or more wireless channels 1214-1 and 1214-2, each of which may comprise a physical communications interface  / layer. UEs 1210 may use stored instructions and information that enable the UE 1210 to encode and transmit multiple UCI-multiplexed OCC-based PUSCH repetition transmissions as described above with reference to FIGs. 1-17.

[0110] As shown, UE 1210 may also, or alternatively, connect to access point (AP) 1216 via connection interface 1218, which may include an air interface enabling UE 1210 to communicatively couple with AP 1216. AP 1216 may comprise a wireless local area network (WLAN) , WLAN node, WLAN termination point, etc. The connection 1218 may comprise a local wireless connection, such as a connection consistent with any IEEE 702.11 protocol, and AP 1216 may comprise a wireless fidelity  router or other AP. While not explicitly depicted in FIG. 12, AP 1216 may be connected to another network (e.g., the Internet) without connecting to RAN 1220 or CN 1230.

[0111] RAN 1220 may include one or more RAN nodes 1222-1 and 1222-2 (referred to collectively as RAN nodes 1222, and individually as RAN node 1222-see also BS 120, 220, and 720 of FIGs 1, 2A, and 7A, respectively) that enable channels 1214-1 and 1214-2 to be established between UEs 1210 and RAN 1220. RAN nodes 1222 may include network access points configured to provide radio baseband functions for data and / or voice connectivity between users and the network based on one or more of the communication technologies described herein (e.g., 2G, 3G, 4G, 5G, WiFi, etc. ) . As examples therefore, a RAN node may be an E-UTRAN Node B (e.g., an enhanced Node B, eNodeB, eNB, 4G base station, etc. ) , a next generation base station (e.g., a 5G base station, NR base station, next generation eNBs (gNB) , etc. ) . RAN nodes 1222 may include a roadside unit (RSU) , a transmission reception point (TRxP or TRP) , and one or more other types of ground stations (e.g., terrestrial access points) . In some scenarios, RAN node 1222 may be a dedicated physical device, such as a macrocell base station, and / or a low power (LP) base station for providing femtocells, picocells or the like having smaller coverage areas, smaller user capacity, or higher bandwidth compared to macrocells.

[0112] RAN nodes can comprise ground stations (e.g., terrestrial access points) or satellite  stations providing coverage within a geographic area (e.g., a cell) . As described above, in some implementations, satellites 1260 may operate as bases stations with respect to UEs. As such, references herein to a base station, RAN node, etc., may involve implementations where the base station, RAN node, etc., is a terrestrial network node and also to implementation where the base station, RAN node, etc., is a non-terrestrial network node (e.g., satellite 1260) .

[0113] As described herein, a RAN node (e.g., base station) 1222 may store instructions and information that enable the RAN node to receive and decode multiple UCI-multiplexed OCC-based PUSCH repetition transmissions as described above with reference to FIGs. 1-17.

[0114] In some implementations, a downlink resource grid may be used for downlink transmissions from any of the RAN nodes 1222 to UEs 1210, and uplink transmissions may utilize similar techniques. The grid may be a time-frequency grid (e.g., a resource grid or time-frequency resource grid) that represents the physical resource for downlink in each slot. Such a time-frequency plane representation is a common practice for OFDM systems, which makes it intuitive for radio resource allocation. Each column and each row of the resource grid corresponds to one OFDM symbol and one OFDM subcarrier, respectively. The duration of the resource grid in the time domain corresponds to one slot in a radio frame. The smallest time-frequency unit in a resource grid is denoted as a resource element. Each resource grid comprises resource blocks, which describe the mapping of certain physical channels to resource elements. Each resource block may comprise a collection of resource elements (REs) ; in the frequency domain, this may represent the smallest quantity of resources that currently may be allocated. There are several different physical downlink channels that are conveyed using such resource blocks.

[0115] The RAN nodes 1222 may be configured to communicate with one another via interface 1223. In implementations where the system is an LTE system, interface 1223 may be an X2 interface. In NR systems, interface 1223 may be an Xn interface. The X2 interface may be defined between two or more RAN nodes 1222 (e.g., two or more eNBs  / gNBs or a combination thereof) that connect to evolved packet core (EPC) or CN 1230, or between two eNBs connecting to an EPC.

[0116] As shown, RAN 1220 may be connected (e.g., communicatively coupled) to CN 1230. CN 1230 may comprise a plurality of network elements 1232, which are configured to offer various data and telecommunications services to customers / subscribers (e.g., users of UEs 1210) who are connected to the CN 1230 via the RAN 1220. In some implementations, CN 1230 may include an evolved packet core (EPC) , a 5G CN, and / or one or more additional or alternative types of CNs. The components of the CN 1230 may be implemented in one physical node or separate physical nodes including components to read and execute instructions from a  machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) . As described herein, the CN may store instructions and information that enable the CN to configure multiple UCI-multiplexed OCC-based PUSCH repetition transmissions as described above with reference to FIGs. 1-17. As shown, CN 1230, application servers 1240, and external networks 1250 may be connected to one another via interfaces 1234, 1236, and 1038, which may include IP network interfaces.

[0117] FIG. 13 is a diagram of an example of components of a network device according to one or more implementations described herein. In some implementations, the device 1300 can include application circuitry 1302, baseband circuitry 1304, RF circuitry 1306, front-end module (FEM) circuitry 1308, one or more antennas 1310, and power management circuitry (PMC) 1312 coupled together at least as shown. The components of the illustrated device 1300 can be included in a UE or a RAN node. In some implementations, the device 1300 can include fewer elements (e.g., a RAN node may not utilize application circuitry 1302, and instead include a processor / controller to process IP data received from a CN or an Evolved Packet Core (EPC) ) . In some implementations, the device 1300 can include additional elements such as, for example, memory / storage, display, camera, sensor (including one or more temperature sensors, such as a single temperature sensor, a plurality of temperature sensors at different locations in device 1300, etc. ) , or input / output (I / O) interface. In other implementations, the components described below can be included in more than one device (e.g., said circuitries can be separately included in more than one device for Cloud-RAN (C-RAN) implementations) .

[0118] The application circuitry 1302 can include one or more application processors. For example, the application circuitry 1302 can include circuitry such as, but not limited to, one or more single-core or multi-core processors. The processor (s) can include any combination of general-purpose processors and dedicated processors (e.g., graphics processors, application processors, etc. ) . The processors can be coupled with or can include memory / storage and can be configured to execute instructions stored in the memory / storage to enable various applications or operating systems to run on the device 1300. In some implementations, processors of application circuitry 1302 can process IP data packets received from an EPC.

[0119] The baseband circuitry 1304 can include circuitry such as, but not limited to, one or more single-core or multi-core processors. The baseband circuitry 1304 can include one or more baseband processors or control logic to process baseband signals received from a receive signal path of the RF circuitry 1306 and to generate baseband signals for a transmit signal path of the RF circuitry 1306. Baseband circuity 1304 can interface with the application circuitry 1302 for generation and processing of the baseband signals and for controlling operations of the RF circuitry 1306. For example, in some implementations, the baseband circuitry 1304 can include a  3G baseband processor 1304A, a 4G baseband processor 1304B, a 5G baseband processor 1304C, or other baseband processor (s) 1304D for other existing generations, generations in development or to be developed in the future (e.g., 5G, 6G, etc. ) .

[0120] The baseband circuitry 1304 (e.g., one or more of baseband processors 1304A-D) can handle various radio control functions that enable communication with one or more radio networks via the RF circuitry 1306. In other implementations, some or all of the functionality of baseband processors 1304A-D can be included in modules stored in the memory 1304G and executed via a Central Processing Unit (CPU) 1304E. In some implementations, the baseband circuitry 1304 can include one or more audio digital signal processor (s) (DSP) 1304F.

[0121] In some implementations, memory 1304G may store instructions and information that enable the device 1300 to transmit or receive multiple UCI-multiplexed OCC-based PUSCH repetition transmissions as described above with reference to FIGs. 1-17.

[0122] RF circuitry 1306 can enable communication with wireless networks using modulated electromagnetic radiation through a non-solid medium. In various implementations, the RF circuitry 1306 can include switches, filters, amplifiers, etc. to facilitate the communication with the wireless network. RF circuitry 1306 can include a receive signal path which can include circuitry to down-convert RF signals received from the FEM circuitry 1308 and provide baseband signals to the baseband circuitry 1304. RF circuitry 1306 can also include a transmit signal path which can include circuitry to up-convert baseband signals provided by the baseband circuitry 1304 and provide RF output signals to the FEM circuitry 1308 for transmission.

[0123] In some implementations, the receive signal path of the RF circuitry 1306 can include mixer circuitry 1306A, amplifier circuitry 1306B and filter circuitry 1306C. In some implementations, the transmit signal path of the RF circuitry 1306 can include filter circuitry 1306C and mixer circuitry 1306A. RF circuitry 1306 can also include synthesizer circuitry 1306D for synthesizing a frequency for use by the mixer circuitry 1306A of the receive signal path and the transmit signal path.

[0124] Examples herein can include subject matter such as a method, means for performing acts or blocks of the method, at least one machine-readable medium including executable instructions that, when performed by a machine or circuitry (e.g., a processor (e.g., processor , etc. ) with memory, an application-specific integrated circuit (ASIC) , a field programmable gate array (FPGA) , or the like) cause the machine to perform acts of the method or of an apparatus or system for concurrent communication using multiple communication technologies according to implementations and examples described.

[0125] Examples

[0126] Example 1 is a baseband processor, including a memory configured to store instructions and a processing circuitry coupled to the memory and, when executing instructions, configured to identify a first scheduled physical uplink shared channel (PUSCH) transmission that overlaps in a first slot with a first scheduled physical uplink control channel (PUCCH) transmission for communicating first uplink control information (UCI) and a second scheduled PUSCH transmission that overlaps in a second slot with a second PUCCH transmission for communicating second UCI, wherein the first scheduled PUSCH transmission and the second scheduled PUSCH transmission correspond to respective PUSCH repetitions of a series of PUSCH repetitions that are spread based on a coding scheme; and multiplex at least a portion of the first UCI and at least a portion of the second UCI with data carried by the PUSCH repetitions to generate a multiplexed PUSCH transmission corresponding to one of the series of PUSCH repetitions; and provide the multiplexed PUSCH transmission to radio frequency (RF) circuitry for transmission.

[0127] Example 2 includes the subject matter of example 2, including or omitting optional subject matter, wherein the PUSCH repetitions are spread by an orthogonal cover code (OCC) or on an inter-slot basis.

[0128] Example 3 includes the subject matter of any of examples 1-2, including or omitting optional subject matter, wherein the processing circuitry is configured to  encode bits of the first UCI to generate a first UCI bits; encode the second UCI to generate second UCI bits; encode uplink data, if present in the PUSCH repetitions, to generate uplink data bits; and multiplex the first UCI bits, the second UCI bits, and the uplink data bits to generate the multiplexed PUSCH transmission.

[0129] Example 4 includes the subject matter of example 3, including or omitting optional subject matter, wherein when the first UCI bits and the second UCI bits each include 1 or 2 bits carrying hybrid automatic repeat request acknowledgement (HARQ-ACK) , the processing circuitry is configured to calculate a number of reserved resource elements (REs) based on a rate-matching length of the HARQ-ACK for the first UCI bits and the second UCI bits assuming two HARQ-ACK bits for the first UCI bits and the second UCI bits; reserve the calculated number of REs in a first orthogonal division multiplexed (OFDM) symbol after an OFDM symbol that includes a demodulation reference signal (DM-RS) ; map the uplink data bits to unmapped and reserved REs; map the first UCI bits and the second UCI bits to the reserved REs; and form a codeword for the multiplexed PUSCH transmission from the mapped REs.

[0130] Example 5 includes the subject matter of example 3, including or omitting optional subject matter, wherein when a total number of first UCI bits carrying HARQ-ACK and second UCI bits carrying HARQ-ACK is 2 bits, the processing circuitry is configured to calculate a  number of reserved REs based on a rate-matching length of the HARQ-ACK for the first UCI bits and the second UCI bits assuming two HARQ-ACK bits for the first UCI bits and the second UCI bits; reserve the calculated number of REs in a first OFDM symbol after an OFDM symbol that includes a DM-RS; map the uplink data bits to unmapped and reserved REs; map the first UCI bits and the second UCI bits to the reserved REs; and form a codeword for the multiplexed PUSCH transmission from the mapped REs.

[0131] Example 6 includes the subject matter of example 3, including or omitting optional subject matter, wherein when a total number of first UCI bits carrying HARQ-ACK and second UCI bits carrying HARQ-ACK is more than two bits, the processing circuitry is configured to map the first UCI bits and the second UCI bits to a OFDM symbol after an OFDM symbol that includes a DM-RS, wherein the first UCI bits and second UCI bits are concatenated in time order; map the uplink data bits to unmapped REs; and form a codeword for the multiplexed PUSCH transmission from the mapped REs.

[0132] Example 7 includes the subject matter of example 3, including or omitting optional subject matter, wherein when the first UCI bits and the second UCI bits each include more than two bits, the processing circuitry is configured to map the first UCI bits and the second UCI bits to a OFDM symbol after an OFDM symbol that includes a DM-RS, wherein the first UCI bits and the second UCI bits are concatenated in time order; map the uplink data bits to unmapped REs; and form a codeword for the multiplexed PUSCH transmission from the mapped REs.

[0133] Example 8 includes the subject matter of example 3, including or omitting optional subject matter, wherein when the first UCI bits or the second UCI bits include 1 or 2 bits carrying HARQ-ACK and the other of the first UCI bits or the second UCI bits include more than 2 bits carrying HARQ-ACK the processing circuitry is configured to map the first UCI bits and the second UCI bits to a OFDM symbol after an OFDM symbol that includes a DM-RS, wherein the first UCI bits are concatenated in time order; map the uplink data bits to unmapped REs; and form a codeword for the multiplexed PUSCH transmission from the mapped REs.

[0134] Example 9 includes the subject matter of example 3, including or omitting optional subject matter, wherein when the first UCI bits include 1 or 2 bits carrying HARQ-ACK and the second UCI bits include more than 2 bits carrying HARQ-ACK, the processing circuitry is configured to calculate a number of reserved resource elements (REs) based on a rate-matching length of the HARQ-ACK for the first UCI bits assuming two HARQ-ACK bits for the first UCI bits; reserve the calculated number of REs in a first orthogonal division multiplexed (OFDM) symbol after an OFDM symbol that includes a demodulation reference signal (DM-RS) ; map the second UCI bits to the first OFDM symbol after the OFDM symbol that includes a DM-RS without mapping second UCI bits to the reserved REs; map the uplink data bits to unmapped and  reserved REs; map the first UCI to the reserved REs; and form a codeword for the multiplexed PUSCH transmission from the mapped REs from the mapped REs.

[0135] Example 10 includes the subject matter of any of examples 1-2, including or omitting optional subject matter, wherein the processing circuitry is configured to  concatenate first UCI bits and second UCI bits; encode the concatenated first UCI bits and second UCI bits to generate combined UCI bits; encode uplink data, if present in the PUSCH repetitions, to generate uplink data bits; and multiplex the combined UCI bits and the uplink data bits to generate the multiplexed PUSCH transmission.

[0136] Example 11 includes the subject matter of example 10, including or omitting optional subject matter, wherein the processing circuitry is configured to decode downlink control information (DCI) to determine a type 2 HARQ-ACK codebook for the combined UCI bits, wherein the DCI includes at least one bit indicating whether the type 2 HARQ-ACK codebook carries HARQ-ACK bits for PDSCH transmission in a previous slot.

[0137] Example 12 includes the subject matter of example 10, including or omitting optional subject matter, wherein the processing circuitry is configured to decode DCI to determine a type 2 HARQ-ACK codebook the combined UCI bits, wherein the DCI includes a first uplink downlink assignment index (DAI) field that indicates a number of bits in the HARQ-ACK codebook for the first UCI and a second uplink DAI field that indicates a number of bits in the HARQ-ACK codebook for the second UCI.

[0138] Example 13 includes the subject matter of example 10, including or omitting optional subject matter, wherein the processing circuitry is configured to decode DCI to determine a type 2 HARQ-ACK codebook for the combined UCI bits, wherein the DCI includes an uplink DAI field that indicates a number of bits in the HARQ-ACK codebook for each of the first UCI and the second UCI.

[0139] Example 14 includes the subject matter of example 10, including or omitting optional subject matter, wherein when the number of combined UCI bits carrying HARQ-ACK is 1 or 2, the processing circuitry is configured to calculate a number of reserved REs based on a rate-matching length of the HARQ-ACK for the combined UCI bits assuming two HARQ-ACK bits for the combined UCI bits; reserve the calculated number of REs in a first orthogonal division multiplexed (OFDM) symbol after an OFDM symbol that includes a demodulation reference signal (DM-RS) ; map the uplink data bits to unmapped and reserved REs; map the combined UCI bits to the reserved REs; and form a codeword for the multiplexed PUSCH transmission from the mapped REs from the mapped REs.

[0140] Example 15 includes the subject matter of example 10, including or omitting optional subject matter, wherein when the number of combined UCI bits carrying HARQ-ACK is more  than 2 bits, the processing circuitry is configured to map the combined UCI bits to a OFDM symbol after an OFDM symbol that includes a DM-RS; map the uplink data bits to unmapped REs and form a codeword for the multiplexed PUSCH transmission from the mapped REs from the mapped REs.

[0141] Example 16 includes the subject matter of example 10, including or omitting optional subject matter, wherein when the number of combined UCI bits carrying HARQ-ACK is less than or equal to 2, the processing circuitry is configured to map the combined UCI bits to a OFDM symbol after an OFDM symbol that includes a DM-RS; map the uplink data bits to unmapped REs; and form a codeword for the multiplexed PUSCH transmission from the mapped REs from the mapped REs.

[0142] Example 17 is user equipment (UE) , including radio frequency (RF) circuitry and baseband processing circuitry configured to, when executing instructions stored in a memory, encode a physical uplink shared channel (PUSCH) transmission; spread the PUSCH transmission based on coding scheme; wherein symbols in the PUSCH transmission carrying demodulation reference signals (DM-RS) are selected based on the coding scheme; and provide the PUSCH transmission to the RF circuitry for transmission.

[0143] Example 18 includes the subject matter of example 17, including or omitting optional subject matter, wherein when the coding scheme is applied on an inter-symbol or intra-symbol basis, the same symbols are selected for carrying DM-RS as compared to symbols carrying DM-RS in PUSCH transmissions from other UEs.

[0144] Example 19 includes the subject matter of example 17, including or omitting optional subject matter, wherein when the coding scheme is applied on inter-slot basis, the symbols are selected for carrying DM-RS independent of symbols carrying DM-RS in PUSCH transmissions from other UEs.

[0145] Example 20 is a baseband processor, including a memory configured to store instructions and a processing circuitry coupled to the memory and, when executing instructions, configured to receive configuration of a physical uplink shared channel (PUSCH) transmission that configures a combined coding scheme including first coding scheme that is applied on an inter-slot basis or inter-symbol basis and a second coding scheme that is applied on an intra-symbol basis; code the PUSCH transmission based on the configuration; and provide the coded PUSCH transmission to radio frequency circuitry for transmission.

[0146] Example 21 includes the subject matter of example 20, including or omitting optional subject matter, wherein the configuration is received in a radio resource control (RRC) type 1 configured grant configuration, type 2 configured grant configuration, or a dedicated configuration for PUSCH transmission with two coding schemes.

[0147] Example 22 includes the subject matter of example 20, including or omitting optional subject matter, wherein the baseband processor is configured to receive multiple configurations of the first coding scheme and the second coding scheme; and receive downlink control information (DCI) that schedules the PUSCH transmission or activates a type 2 configured grant that indicates a selection from among the multiple configurations.

[0148] Example 23 includes the subject matter of example 20, including or omitting optional subject matter, wherein the configuration is received in DCI that schedules the PUSCH transmission.

[0149] Example 24 is a baseband processor, including a memory configured to store instructions and a processing circuitry coupled to the memory and, when executing instructions, configured to identify a first scheduled physical uplink shared channel (PUSCH) transmission that overlaps in a first slot with a first scheduled physical uplink control channel (PUCCH) transmission for communicating first uplink control information (UCI) and a second scheduled PUSCH transmission that overlaps in a second slot with a second PUCCH transmission for communicating second UCI, wherein the first scheduled PUSCH transmission and the second scheduled PUSCH transmission correspond to respective PUSCH repetitions of a series of PUSCH repetitions that are spread based on a coding scheme; receive a multiplexed PUSCH transmission that includes at least a portion of the first UCI and at least a portion of the second UCI multiplexed in the PUSCH, wherein the received multiplexed PUSCH transmission corresponds to one of the series of PUSCH repetitions; and de-multiplexing the received the multiplexed PUSCH to decode the at least a portion of the first UCI and the at least a portion of the second UCI.

[0150] Example 25 is a base station, including baseband processing circuitry configured to, when executing instructions stored in a memory, select symbols in a physical uplink shared channel (PUSCH) configuration for carrying demodulation reference signals (DM-RS) based on a coding scheme of the PUSCH; and radio frequency (RF) circuitry configured to receive coded PUSCH transmissions according to the PUSCH configuration.

[0151] Example 26 is a baseband processor, including a memory configured to store instructions and a processing circuitry coupled to the memory and, when executing instructions, configured to transmit configuration of a physical uplink shared channel (PUSCH) transmission that configures a two level coding scheme including a first coding scheme that is applied on an inter-slot basis or inter-symbol basis and a second coding scheme that is applied on an intra-symbol basis; and decode a received PUSCH transmission based on the configuration.

[0152] Example 27 is a method that includes functions corresponding to the operations performed by the baseband processor or one or more processors of examples 1-26.

[0153] Example 28 is an apparatus that includes means for performing functions corresponding to the operations performed by the baseband processor or one or more processors of examples 1-26.

[0154] Example 29 is a UE including the baseband processor of examples 1-20.

[0155] The above description of illustrated examples, implementations, aspects, etc., of the subject disclosure, including what is described in the Abstract, is not intended to be exhaustive or to limit the disclosed aspects to the precise forms disclosed. While specific examples, implementations, aspects, etc., are described herein for illustrative purposes, various modifications are possible that are considered within the scope of such examples, implementations, aspects, etc., as those skilled in the relevant art can recognize.

[0156] While the methods are illustrated and described above as a series of acts or events, it will be appreciated that the illustrated ordering of such acts or events are not to be interpreted in a limiting sense. For example, some acts may occur in different orders and / or concurrently with other acts or events apart from those illustrated and / or described herein. In addition, not all illustrated acts may be required to implement one or more aspects or embodiments of the disclosure herein. Also, one or more of the acts depicted herein may be carried out in one or more separate acts and / or phases. In some embodiments, the methods illustrated above may be implemented in a computer readable medium using instructions stored in a memory. Many other embodiments and variations are possible within the scope of the claimed disclosure.

[0157] The term “couple” is used throughout the specification. The term may cover connections, communications, or signal paths that enable a functional relationship consistent with the description of the present disclosure. For example, if device A generates a signal to control device B to perform an action, in a first example device A is coupled to device B, or in a second example device A is coupled to device B through intervening component C if intervening component C does not substantially alter the functional relationship between device A and device B such that device B is controlled by device A via the control signal generated by device A.

[0158] It is well understood that the use of personally identifiable information should follow privacy policies and practices that are generally recognized as meeting or exceeding industry or governmental requirements for maintaining the privacy of users. In particular, personally identifiable information data should be managed and handled so as to minimize risks of unintentional or unauthorized access or use, and the nature of authorized use should be clearly indicated to users.

Claims

1.A baseband processor, comprising a memory configured to store instructions and a processing circuitry coupled to the memory and, when executing instructions, configured to:identify a first scheduled physical uplink shared channel (PUSCH) transmission that overlaps in a first slot with a first scheduled physical uplink control channel (PUCCH) transmission for communicating first uplink control information (UCI) and a second scheduled PUSCH transmission that overlaps in a second slot with a second PUCCH transmission for communicating second UCI, wherein the first scheduled PUSCH transmission and the second scheduled PUSCH transmission correspond to respective PUSCH repetitions of a series of PUSCH repetitions that are spread based on a coding scheme; andmultiplex at least a portion of the first UCI and at least a portion of the second UCI with data carried by the PUSCH repetitions to generate a multiplexed PUSCH transmission corresponding to one of the series of PUSCH repetitions; andprovide the multiplexed PUSCH transmission to radio frequency (RF) circuitry for transmission.2.The baseband processor of claim 1, wherein the PUSCH repetitions are spread by an orthogonal cover code (OCC) or on an inter-slot basis.3.The baseband processor of any of claims 1-2, wherein the processing circuitry is configured to encode bits of the first UCI to generate a first UCI bits;encode the second UCI to generate second UCI bits;encode uplink data, if present in the PUSCH repetitions, to generate uplink data bits; andmultiplex the first UCI bits, the second UCI bits, and the uplink data bits to generate the multiplexed PUSCH transmission.4.The baseband processor of claim 3 wherein when the first UCI bits and the second UCI bits each comprise 1 or 2 bits carrying hybrid automatic repeat request acknowledgement (HARQ-ACK) , the processing circuitry is configured tocalculate a number of reserved resource elements (REs) based on a rate-matching length of the HARQ-ACK for the first UCI bits and the second UCI bits assuming two HARQ-ACK bits for the first UCI bits and the second UCI bits;reserve the calculated number of REs in a first orthogonal division multiplexed (OFDM) symbol after an OFDM symbol that includes a demodulation reference signal (DM-RS) ;map the uplink data bits to unmapped and reserved REs;map the first UCI bits and the second UCI bits to the reserved REs; andform a codeword for the multiplexed PUSCH transmission from the mapped REs.5.The baseband processor of claim 3 wherein when a total number of first UCI bits carrying HARQ-ACK and second UCI bits carrying HARQ-ACK is 2 bits, the processing circuitry is configured tocalculate a number of reserved REs based on a rate-matching length of the HARQ-ACK for the first UCI bits and the second UCI bits assuming two HARQ-ACK bits for the first UCI bits and the second UCI bits;reserve the calculated number of REs in a first OFDM symbol after an OFDM symbol that includes a DM-RS;map the uplink data bits to unmapped and reserved REs;map the first UCI bits and the second UCI bits to the reserved REs; andform a codeword for the multiplexed PUSCH transmission from the mapped REs.6.The baseband processor of claim 3 wherein when a total number of first UCI bits carrying HARQ-ACK and second UCI bits carrying HARQ-ACK is more than two bits, the processing circuitry is configured tomap the first UCI bits and the second UCI bits to a OFDM symbol after an OFDM symbol that includes a DM-RS, wherein the first UCI bits and second UCI bits are concatenated in time order;map the uplink data bits to unmapped REs; andform a codeword for the multiplexed PUSCH transmission from the mapped REs.7.The baseband processor of claim 3 wherein when the first UCI bits and the second UCI bits each comprise more than two bits, the processing circuitry is configured tomap the first UCI bits and the second UCI bits to a OFDM symbol after an OFDM symbol that includes a DM-RS, wherein the first UCI bits and the second UCI bits are concatenated in time order;map the uplink data bits to unmapped REs; andform a codeword for the multiplexed PUSCH transmission from the mapped REs.8.The baseband processor of claim 3 wherein when the first UCI bits or the second UCI bits  comprise 1 or 2 bits carrying HARQ-ACK and the other of the first UCI bits or the second UCI bits comprise more than 2 bits carrying HARQ-ACK the processing circuitry is configured tomap the first UCI bits and the second UCI bits to a OFDM symbol after an OFDM symbol that includes a DM-RS, wherein the first UCI bits are concatenated in time order;map the uplink data bits to unmapped REs; andform a codeword for the multiplexed PUSCH transmission from the mapped REs.9.The baseband processor of claim 3 wherein when the first UCI bits comprise 1 or 2 bits carrying HARQ-ACK and the second UCI bits comprise more than 2 bits carrying HARQ-ACK, the processing circuitry is configured tocalculate a number of reserved resource elements (REs) based on a rate-matching length of the HARQ-ACK for the first UCI bits assuming two HARQ-ACK bits for the first UCI bits;reserve the calculated number of REs in a first orthogonal division multiplexed (OFDM) symbol after an OFDM symbol that includes a demodulation reference signal (DM-RS) ;map the second UCI bits to the first OFDM symbol after the OFDM symbol that includes a DM-RS without mapping second UCI bits to the reserved REs;map the uplink data bits to unmapped and reserved REs;map the first UCI to the reserved REs; andform a codeword for the multiplexed PUSCH transmission from the mapped REs from the mapped REs.10.The baseband processor of any of claims 1-2, wherein the processing circuitry is configured to concatenate first UCI bits and second UCI bits;encode the concatenated first UCI bits and second UCI bits to generate combined UCI bits;encode uplink data, if present in the PUSCH repetitions, to generate uplink data bits; andmultiplex the combined UCI bits and the uplink data bits to generate the multiplexed PUSCH transmission.11.The baseband processor of claim 10, wherein the processing circuitry is configured to decode downlink control information (DCI) to determine a type 2 HARQ-ACK codebook for the combined UCI bits, wherein the DCI includes at least one bit indicating whether the type 2 HARQ-ACK codebook carries HARQ-ACK bits for PDSCH transmission in a previous slot.12.The baseband processor of claim 10, wherein the processing circuitry is configured to decode DCI to determine a type 2 HARQ-ACK codebook the combined UCI bits, wherein the DCI  includes a first uplink downlink assignment index (DAI) field that indicates a number of bits in the HARQ-ACK codebook for the first UCI and a second uplink DAI field that indicates a number of bits in the HARQ-ACK codebook for the second UCI.13.The baseband processor of claim 10, wherein the processing circuitry is configured to decode DCI to determine a type 2 HARQ-ACK codebook for the combined UCI bits, wherein the DCI includes an uplink DAI field that indicates a number of bits in the HARQ-ACK codebook for each of the first UCI and the second UCI.14.The baseband processor of claim 10 wherein when the number of combined UCI bits carrying HARQ-ACK is 1 or 2, the processing circuitry is configured tocalculate a number of reserved REs based on a rate-matching length of the HARQ-ACK for the combined UCI bits assuming two HARQ-ACK bits for the combined UCI bits;reserve the calculated number of REs in a first orthogonal division multiplexed (OFDM) symbol after an OFDM symbol that includes a demodulation reference signal (DM-RS) ;map the uplink data bits to unmapped and reserved REs;map the combined UCI bits to the reserved REs; andform a codeword for the multiplexed PUSCH transmission from the mapped REs from the mapped REs.15.The baseband processor of claim 10 wherein when the number of combined UCI bits carrying HARQ-ACK is more than 2 bits, the processing circuitry is configured tomap the combined UCI bits to a OFDM symbol after an OFDM symbol that includes a DM-RS;map the uplink data bits to unmapped REs andform a codeword for the multiplexed PUSCH transmission from the mapped REs from the mapped REs.16.The baseband processor of claim 10, wherein when the number of combined UCI bits carrying HARQ-ACK is less than or equal to 2, the processing circuitry is configured tomap the combined UCI bits to a OFDM symbol after an OFDM symbol that includes a DM-RS;map the uplink data bits to unmapped REs; andform a codeword for the multiplexed PUSCH transmission from the mapped REs from the mapped REs.17.A user equipment (UE) , comprising:radio frequency (RF) circuitry; andbaseband processing circuitry configured to, when executing instructions stored in a memory, encode a physical uplink shared channel (PUSCH) transmission;spread the PUSCH transmission based on coding scheme;wherein symbols in the PUSCH transmission carrying demodulation reference signals (DM-RS) are selected based on the coding scheme; andprovide the PUSCH transmission to the RF circuitry for transmission.18.The user equipment of claim 17, wherein when the coding scheme is applied on an inter-symbol or intra-symbol basis, the same symbols are selected for carrying DM-RS as compared to symbols carrying DM-RS in PUSCH transmissions from other UEs.19.The user equipment of claim 17, wherein when the coding scheme is applied on inter-slot basis, the symbols are selected for carrying DM-RS independent of symbols carrying DM-RS in PUSCH transmissions from other UEs.20.A baseband processor, comprising a memory configured to store instructions and a processing circuitry coupled to the memory and, when executing instructions, configured to:receive configuration of a physical uplink shared channel (PUSCH) transmission that configures a combined coding scheme including first coding scheme that is applied on an inter-slot basis or inter-symbol basis and a second coding scheme that is applied on an intra-symbol basis;code the PUSCH transmission based on the configuration; andprovide the coded PUSCH transmission to radio frequency circuitry for transmission.21.The baseband processor of claim 20, wherein the configuration is received in a radio resource control (RRC) type 1 configured grant configuration, type 2 configured grant configuration, or a dedicated configuration for PUSCH transmission with two coding schemes.22.The baseband processor of claim 20, configured toreceive multiple configurations of the first coding scheme and the second coding scheme; andreceive downlink control information (DCI) that schedules the PUSCH transmission or activates a type 2 configured grant that indicates a selection from among the multiple configurations.23.The baseband processor of claim 21, wherein the configuration is received in DCI that schedules the PUSCH transmission.24.A baseband processor, comprising a memory configured to store instructions and a processing circuitry coupled to the memory and, when executing instructions, configured to:identify a first scheduled physical uplink shared channel (PUSCH) transmission that overlaps in a first slot with a first scheduled physical uplink control channel (PUCCH) transmission for communicating first uplink control information (UCI) and a second scheduled PUSCH transmission that overlaps in a second slot with a second PUCCH transmission for communicating second UCI, wherein the first scheduled PUSCH transmission and the second scheduled PUSCH transmission correspond to respective PUSCH repetitions of a series of PUSCH repetitions that are spread based on a coding scheme;receive a multiplexed PUSCH transmission that includes at least a portion of the first UCI and at least a portion of the second UCI multiplexed in the PUSCH, wherein the received multiplexed PUSCH transmission corresponds to one of the series of PUSCH repetitions; andde-multiplexing the received the multiplexed PUSCH to decode the at least a portion of the first UCI and the at least a portion of the second UCI.25.A base station, comprising:baseband processing circuitry configured to, when executing instructions stored in a memory, select symbols in a physical uplink shared channel (PUSCH) configuration for carrying demodulation reference signals (DM-RS) based on a coding scheme of the PUSCH; andradio frequency (RF) circuitry configured to receive coded PUSCH transmissions according to the PUSCH configuration.26.A baseband processor, comprising a memory configured to store instructions and a processing circuitry coupled to the memory and, when executing instructions, configured to:transmit configuration of a physical uplink shared channel (PUSCH) transmission that configures a two level coding scheme comprising a first coding scheme that is applied on an inter-slot basis or inter-symbol basis and a second coding scheme that is applied on an intra-symbol basis; anddecode a received PUSCH transmission based on the configuration.

Images