Technologies for physical uplink shared channel transmissions with orthogonal cover code

Abstract

The present application relates to devices and components including apparatuses, systems, and methods associated with transmission of a physical uplink shared channel (PUSCH) with orthogonal cover code (OCC).

Description

TECHNOLOGIES FOR PHYSICAL UPLINK SHARED CHANNEL TRANSMISSIONS WITH ORTHOGONAL COVER CODETECHNICAL FIELD

[0001] This application relates generally to communication networks and, in particular, to technologies for physical uplink shared channel transmission with orthogonal cover code.BACKGROUND

[0002] Third Generation Partnership Project (3GPP) Technical Specifications (TSs) define standards for wireless networks. These TSs describe aspects related to signaling traffic through systems that incorporate wireless networks.BRIEF DESCRIPTION OF THE DRAWINGS

[0003] FIG. 1 illustrates a network environment in accordance with some embodiments.

[0004] FIG. 2 illustrates an example UE procedure for determining orthogonal cover code (OCC) length and OCC sequence index for dynamic grant physical uplink shared channel (PUSCH) in accordance with some embodiments.

[0005] FIG. 3 illustrates an example of transport block transmitted over multiple slots (TBoMS) with redundancy version (RV) cycling in OCC-based PUSCH transmission, in accordance with some embodiments.

[0006] FIG. 4 illustrates another example of TBoMS with RV cycling in OCC-based PUSCH transmission, in accordance with some embodiments.

[0007] FIG. 5 illustrates another example of TBoMS with RV cycling in OCC-based PUSCH transmission, in accordance with some embodiments.

[0008] FIG. 6A illustrates an example of physical uplink control channel (PUCCH) repetition overlap with OCC-based PUSCH repetition, in accordance with some embodiments.

[0009] FIG. 6B illustrates another example of PUCCH repetition overlap with OCC-based PUSCH repetition, in accordance with some embodiments.

[0010] FIG. 7 illustrates an example of multiplexing uplink control information (UCI) on OCC-based PUSCH repetitions, in accordance with some embodiments.

[0011] FIGS. 8A, 8B, and 8C illustrate other examples of multiplexing UCI on OCC-based PUSCH repetitions, in accordance with some embodiments.

[0012] FIG. 9 illustrates examples of a timeline for channel state information (CSI) processing with OCC-based PUSCH, in accordance with some embodiments.

[0013] FIG. 10 illustrates an example procedure for indicating TBoMS usage with intra-symbol OCC, in accordance with some embodiments.

[0014] FIG. 11 illustrates an example of a system information block 1 (SIB1) monitoring window, in accordance with some embodiments.

[0015] FIG. 12 illustrates an operation flow / algorithmic structure in accordance with some embodiments.

[0016] FIG. 13 illustrates another operation flow / algorithmic structure in accordance with some embodiments.

[0017] FIG. 14 illustrates another operation flow / algorithmic structure in accordance with some embodiments.

[0018] FIG. 15 illustrates a user equipment in accordance with some embodiments.

[0019] FIG. 16 illustrates a network device in accordance with some embodiments.DETAILED DESCRIPTION

[0020] The following detailed description refers to the accompanying drawings. The same reference numbers may be used in different drawings to identify the same or similar elements. In the following description, for purposes of explanation and not limitation, specific details are set forth such as particular structures, architectures, interfaces, techniques, etc. in order to provide a thorough understanding of the various aspects of various embodiments. However, it will be apparent to those skilled in the art having the benefit of the present disclosure that the various aspects of the various embodiments may be practiced in other examples that depart from these specific details. In certain instances, descriptions of well-known devices, circuits, and methods are omitted so as not to obscure the description of the various embodiments with unnecessary detail. For the purposes of the present document, the phrase “A or B” means (A) , (B) , or (A and B) ; and the phrase “based on A” means “based at least in part on A, ” for example, it could be “based solely on A” or it could be “based in part on A. ”

[0021] The following is a glossary of terms that may be used in this disclosure.

[0022] The term “circuitry” as used herein refers to, is part of, or includes hardware components such as an electronic circuit, a logic circuit, a processor (shared, dedicated, or group) or memory (shared, dedicated, or group) , an application specific integrated circuit (ASIC) , a field-programmable device (FPD) (e.g., a field-programmable gate array (FPGA) , a programmable logic device (PLD) , a complex PLD (CPLD) , a high-capacity PLD (HCPLD) , a structured ASIC, or a programmable system-on-a-chip (SoC) ) , digital signal processors (DSPs) , etc., that are configured to provide the described functionality. In some embodiments, the circuitry may execute one or more software or firmware programs to provide at least some of the described functionality. The term “circuitry” may also refer to a combination of one or more hardware elements (or a combination of circuits used in an electrical or electronic system) with the program code used to carry out the functionality of that program code. In these embodiments, the combination of hardware elements and program code may be referred to as a particular type of circuitry.

[0023] The term “processor circuitry” as used herein refers to, is part of, or includes circuitry capable of sequentially and automatically carrying out a sequence of arithmetic or logical operations, or recording, storing, or transferring digital data. The term “processor circuitry” may refer an application processor, baseband processor, a central processing unit (CPU) , a graphics processing unit, a single-core processor, a dual-core processor, a triple-core processor, a quad-core processor, or any other device capable of executing or otherwise operating computer-executable instructions, such as program code, software modules, or functional processes.

[0024] The term “interface circuitry” as used herein refers to, is part of, or includes circuitry that enables the exchange of information between two or more components or devices. The term “interface circuitry” may refer to one or more hardware interfaces, for example, buses, I / O interfaces, peripheral component interfaces, network interface cards, or the like.

[0025] The term “user equipment” or “UE” as used herein refers to a device with radio communication capabilities and may describe a remote user of network resources in a communications network. The term “user equipment” or “UE” may be considered synonymous to, and may be referred to as, client, mobile, mobile device, mobile terminal, user terminal, mobile unit, mobile station, mobile user, subscriber, user, remote station, access agent, user agent, receiver, radio equipment, reconfigurable radio equipment, reconfigurable mobile device, etc. Furthermore, the term “user equipment” or “UE” may include any type of wireless / wired device or any computing device including a wireless communications interface.

[0026] The term “computer system” as used herein refers to any type interconnected electronic devices, computer devices, or components thereof. Additionally, the term “computer system” or “system” may refer to various components of a computer that are communicatively coupled with one another. Furthermore, the term “computer system” or “system” may refer to multiple computer devices or multiple computing systems that are communicatively coupled with one another and configured to share computing or networking resources.

[0027] The term “resource” as used herein refers to a physical or virtual device, a physical or virtual component within a computing environment, or a physical or virtual component within a particular device, such as computer devices, mechanical devices, memory space, processor / CPU time, processor / CPU usage, processor and accelerator loads, hardware time or usage, electrical power, input / output operations, ports or network sockets, channel / link allocation, throughput, memory usage, storage, network, database and applications, workload units, or the like. A “hardware resource” may refer to compute, storage, or network resources provided by physical hardware element (s) . A “virtualized resource” may refer to compute, storage, or network resources provided by virtualization infrastructure to an application, device, system, etc. The term “network resource” or “communication resource” may refer to resources that are accessible by computer devices / systems via a communications network. The term “system resources” may refer to any kind of shared entities to provide services, and may include computing or network resources. System resources may be considered as a set of coherent functions, network data objects or services, accessible through a server where such system resources reside on a single host or multiple hosts and are clearly identifiable.

[0028] The term “channel” as used herein refers to any transmission medium, either tangible or intangible, which is used to communicate data or a data stream. The term “channel” may be synonymous with or equivalent to “communications channel, ” “data communications channel, ” “transmission channel, ” “data transmission channel, ” “access channel, ” “data access channel, ” “link, ” “data link, ” “carrier, ” “radio-frequency carrier, ” or any other like term denoting a pathway or medium through which data is communicated. Additionally, the term “link” as used herein refers to a connection between two devices for the purpose of transmitting and receiving information.

[0029] The terms “instantiate, ” “instantiation, ” and the like as used herein refers to the creation of an instance. An “instance” also refers to a concrete occurrence of an object, which may occur, for example, during execution of program code.

[0030] The term “connected” may mean that two or more elements, at a common communication protocol layer, have an established signaling relationship with one another over a communication channel, link, interface, or reference point.

[0031] The term “network element” as used herein refers to physical or virtualized equipment or infrastructure used to provide wired or wireless communication network services. The term “network element” may be considered synonymous to or referred to as a networked computer, networking hardware, network equipment, network node, virtualized network function, or the like.

[0032] The term “information element” refers to a structural element containing one or more fields. The term “field” refers to individual contents of an information element, or a data element that contains content. An information element may include one or more additional information elements.

[0033] The term “based on” as used herein may indicate that an item is based solely on another item and / or an item is based on another item and one or more additional items. For example, item 1 being determined based on item 2 may indicate that item 1 is determined based solely on item 2 and / or is determined based on item 2 and one or more other items in embodiments.

[0034] FIG. 1 illustrates a network environment 100 in accordance with some embodiments. The network environment 100 may include a user equipment (UE) 104 communicatively coupled with a base station 108 of a radio access network (RAN) 110. The UE 104 and the base station 108 may communicate over air interfaces compatible with 3GPP TSs such as those that define a Fifth Generation (5G) new radio (NR) system or a later system. The base station 108 may provide user plane and control plane protocol terminations toward the UE 104. The UE 104 may access an external data network 120 via the base station 108.

[0035] In some embodiments, the UE 104 and base station 108 may establish data radio bearers (DRBs) to support transmission of data over a wireless link between the two nodes. In one example, these DRBs may be used for traffic from extended reality (XR) applications that contains a large amount of data conveying real and virtual images and audio for presentation to a user.

[0036] The network environment 100 may further include a core network 112. For example, the core network 112 may comprise a 5th Generation Core network (5GC) or later generation core network. The core network 112 may be coupled to the base station 108 via a fiber optic or wireless backhaul. The core network 112 may provide functions for the UE 104 via the base station 108. These functions may include managing subscriber profile information, subscriber location, authentication of services, or switching functions for voice and data sessions.

[0037] In some embodiments, the network environment 100 may also include UE 106. The UE 106 may be coupled with the UE 104 via a sidelink interface. In some embodiments, the UE 106 may act as a relay node to communicatively couple the UE 104 to the RAN 110. In other embodiments, the UE 106 and the UE 104 may represent end nodes of a communication link. For example, the UEs 104 and 106 may exchange data with one another.

[0038] The base station 108 may transmit information (for example, data and control signaling) in the downlink direction by mapping logical channels on the transport channels and transport channels onto physical channels. The logical channels may transfer data between a radio link control (RLC) and medium access control (MAC) layers; the transport channels may transfer data between the MAC and PHY layers; and the physical channels may transfer information across the air interface. The physical channels may include a physical broadcast channel (PBCH) , a physical downlink control channel (PDCCH) , and a physical downlink shared channel (PDSCH) .

[0039] The PBCH may be used to broadcast system information that the UE 104 may use for initial access to a serving cell. The PBCH may be transmitted along with physical synchronization signals (PSS) and secondary synchronization signals (SSS) in a synchronization signal block (SSB) . The SSBs may be used by the UE 104 during a cell search procedure (including cell selection and reselection) and for beam selection.

[0040] The PDSCH may be used to transfer end-user application data, signaling radio bearer (SRB) messages, and / or system information messages (other than, for example, master information block (MIB) ) .

[0041] The PDCCH may transfer downlink control information (DCI) that is used by a scheduler of the base station 108 to allocate both uplink and downlink resources. The DCI may also be used to provide uplink power control commands, configure a slot format, or indicate that preemption has occurred.

[0042] In some embodiments, group scheduling may be used to schedule a transmission for multiple UEs (e.g., in accordance with multicast and broadcast services (MBS) ) . In an example, for point-to-point (PTP) transmission for radio resource control (RRC) connected UEs, a UE-specific PDCCH with cyclic redundancy code (CRC) scrambled by a UE-specific radio network temporary identifier (RNTI) (e.g., cell-specific RNTI (C-RNTI) ) may be used to schedule a UE-specific PDSCH which is scrambled with the same UE-specific RNTI. In a point-to-multipoint (PTM) transmission scheme 1, for RRC connected UEs in a same MBS group, a group-common PDCCH with CRC scrambled by a group-common RNTI may schedule a group-common PDSCH which is scrambled with the same group-common RNTI. This scheme may also be referred to as a group-common PDCCH based group scheduling scheme. In a PTM transmission scheme 2, for RRC connected UEs in the same MBS group, a UE-specific PDCCH with CRC scrambled by a UE-specific RNTI (e.g., C-RNTI) may schedule a group-common PDSCH which is scrambled with a group-common RNTI. This scheme may also be referred to as a UE-specific PDCCH based group scheduling scheme. A “group common” PDCCH or PDSCH may refer to a PDCCH or PDSCH that is transmitted in the same time / frequency resources and is to be received (e.g., can be decoded) by all the UEs in the same MBS group.

[0043] The UE 104 may transmit data and control information to the base station 108 using physical uplink channels. Different types of physical uplink channels are possible including, for instance, a physical uplink control channel (PUCCH) and a physical uplink shared channel (PUSCH) . Whereas the PUCCH carries control information from the UE 104 to the base station 108, such as uplink control information (UCI) , the PUSCH carries data traffic (e.g., end-user application data) , and can carry UCI multiplexed in the PUSCH. The UCI may include, for example, hybrid automatic repeat request (HARQ) feedback (e.g., HARQ-acknowledgement (ACK) feedback) , channel state information (CSI) and / or other control information. The CSI may include, for example, a channel quality indicator (CQI) , precoding matrix indicator (PMI) , a CSI reference signal (CSI-RS) resource indicator (CRI) , a synchronization signal  / physical broadcast channel block resource indicator (SSBRI) , layer indicator (LI) , rank indicator (RI) , layer 1 (L1) reference signal received power (RSRP) , L1 signal-and-interference-to-noise ratio (SINR) , a capability index, and / or time-domain properties. The CSI may be separated into a CSI part 1 and a CSI part 2 that carry different parameters.

[0044] Data transmission on PUSCH can be codebook-based, where the base station 108 indicates precoding weights for the UE 104 to use. For the base station 108 to determine the precoding weights, the base station 108 may have previously configured the UE 104 to transmit sounding reference signal (SRS) and may have triggered the UE 104 to do so. As illustrated in FIG. 1, the base station 108 may communicate with multiple UEs (including the UE 104 and the UE 106) . The base station 108 may configure each of such UEs 104 and 106 to use particular SRS resource sets such that the base station 108 can receive SRSs transmitted by the UEs 104 and 106 to then determine the precoding weights that each UE needs to use for its uplink data transmission.

[0045] The UE 104 and the base station 108 may perform beam management operations to identify and maintain desired beams for transmission in the uplink and downlink directions. The beam management may be applied to both PDSCH and PDCCH in the downlink direction, and PUSCH and PUCCH in the uplink direction.

[0046] In an example, communications with the base station 108 may use channels in the frequency range 1 (FR1) , frequency range 2 (FR2) , and / or a higher frequency range. The FR1 band includes a licensed band and an unlicensed band. The NR unlicensed band (NR-U) includes a frequency spectrum that is shared with other types of radio access technologies (RATs) (e.g., LTE-LAA, WiFi, etc. ) . A listen-before-talk (LBT) procedure can be used to avoid or minimize collision between the different RATs in the NR-U, whereby a device should apply a clear channel assessment (CCA) check before using the channel.

[0047] In an example, the network 110 may include a non-terrestrial network (NTN) . For example, the base station 108 may be implemented in a satellite (e.g., in low-Earth orbit (LEO) ) . NTNs may service a larger geographical area with potentially larger number of UEs than a terrestrial network. Additionally, NTNs have significantly longer uplink and downlink transmission times (e.g., timing advance) , among other challenges (e.g., Doppler effect, time variation, phase distortion, moving base station / coverage area, etc. ) .

[0048] Various uplink capacity / throughput enhancements are being considered for NTNs. The enhancements may be initially implemented for FR1, however, aspects may also be implemented in other frequencies such as FR2. One enhancement being considered is to use orthogonal cover codes (OCCs) to transmit PUSCH. Different UEs may transmit a PUSCH in the same / overlapping resources with different OCCs. The different OCCs enable the network to successfully receive the PUSCHs from the respective UEs in the same / overlapping resources.

[0049] The OCC may correspond to, for example, a Walsh (Hadamard) code or a discrete Fourier transform (DFT) sequence. The Walsh code may include a sequence of values that are either 1 or -1. For example, for a length 2 Walsh code OCC, the OCC may be [1 1] or [1 -1] for respective UEs. For a length 4 Walsh code OCC, the OCC may be, for example [1 1 1 1] , [1 -1 1 -1] , [1 1 -1 -1] , or [1 -1 -1 1] for respective UEs. The DFT sequence for OCC may be a sequence of complex values.

[0050] In an example, the PUSCH may be transmitted on orthogonal frequency division multiplexing (OFDM) symbols, such as DFT-spread (s) -OFDM symbols. The OCC may be applied across symbols, across slots, and / or within individual symbols. For example, some OCC techniques that may be used for PUSCH include: inter-slot time-domain OCC with PUSCH repetition Type A with OCC length 2 or 4; inter-symbol time domain OCC with OCC length 2 or 4; intra-symbol pre-DFT-sOCC (comb-like structure as in PUCCH format 4) with OCC length 2 or 4; and / or a combination of OCC techniques (e.g., to multiplex up to 8 UEs) .

[0051] In 3GPP RAN1 Meeting #119, it was agreed to support inter-slot OCC, including OCC length 2 to multiplex up to two UEs and OCC length 4 to multiplex up to four UEs (e.g., using Hadamard sequences) . Some embodiments herein may be described with reference to inter-slot OCC. However, aspects of various embodiments may also be applied to other OCC schemes.

[0052] The UE may indicate to the network its capability to support OCC for PUSCH. In an example, separate UE capabilities may be defined for OCC length 2 and OCC length 4. In some instances, UE capability for OCC length 2 may be a prerequisite for UE capability for OCC length 4 (e.g., an indication that the UE supports OCC length 4 also means that the UE supports OCC length 2) . The network may group UEs based on carrier frequency offset (CFO) to improve the performance of inter-slot OCC. For example, the network may group UEs so that they have a CFO differential less than a maximum differential (e.g., 50 Hz, 100 Hz, 200 Hz, etc. ) .

[0053] The implementation of PUSCH with OCC may affect other aspects of PUSCH transmission, such as: UCI multiplexing; TB size (TBS) calculation  / rate matching; redundancy version (RV) cycling across repetitions; frequency hopping, e.g., intra-slot or inter-slot; OCC indication / configuration; power control; and / or use of transport block processing over multiple slots (TBoMS) with OCC.

[0054] Embodiments herein relate to technologies associated with OCC-based PUSCH transmission. For example, embodiments herein may relate to indication of OCC length and / or OCC sequence; schemes for TBoMS with RV cycling in OCC-based PUSCH transmission; handling overlap between PUCCH repetition (e.g., with UCI) and OCC-based PUSCH repetition; timeline of CSI processing in OCC-based PUSCH; indication of TBoMS usage with intra-symbol OCC; indication of OCC sequence in combined OCC schemes; and / or an SIB1 monitoring window. The embodiments herein may be used with an NTN and / or a terrestrial network.

[0055] Note that reference herein to a “PUSCH” or a “PUCCH” may refer to a PUSCH transmission or a PUCCH transmission that is transmitted by the UE and / or scheduled to be transmitted by the UE (e.g., based on a corresponding PUSCH configuration or PUCCH configuration) .Indication of OCC length and OCC sequence

[0056] In various embodiments, the OCC length and / or OCC sequence to be applied by a UE may be indicated by a time domain resource allocation (TDRA) . For example, a TDRA table may include the OCC length and / or OCC sequence associated with respective TDRA indexes. The network may indicate a TDRA index for a PUSCH to be transmitted by the UE. For example, the TDRA index may be indicated in a scheduling message (e.g., DCI) that schedules the PUSCH. The indication of the OCC length and / or OCC sequence based on the TDRA may apply to, for example, a PUSCH scheduled by dynamic grant, type 1 configured grant, and / or type 2 configured grant. A dynamic grant PUSCH may be scheduled by DCI, a type 1 configured grant PUSCH may be scheduled by RRC signaling, and a type 2 configured grant PUSCH may be configured by RRC signaling and activated and / or deactivated by DCI.

[0057] The UE may receive a PUSCH configuration (e.g., a UE-specific PUSCH configuration) with an information element (IE) that indicates a list of TDRAs (e.g., IE pusch-TimeDomainAllocationList) . The TDRAs may be associated with respective TDRA indexes to define a TDRA table. Individual TDRAs may include parameters, such as DMRS mapping type, start symbol and length, number of repetitions (e.g., up to 32 repetitions) , and / or number of slots for TBoMS. As discussed above, the individual TDRAs may further include an OCC length and / or an OCC sequence. In an example, the OCC length may be 1 (e.g., no OCC is applied) , 2, or 4.

[0058] The OCC sequence may be indicated by an OCC sequence index. In an example, the OCC sequence may be smaller than the OCC length (e.g., since the OCC sequence index starts at index 0 and the total number of OCC sequences for a given OCC length may be equal to the OCC length) . For example, if OCC length is configured as 2, the OCC sequence index may be 0 or 1. If the OCC length is configured as 4, the OCC sequence index may be 0, 1, 2, or 3.

[0059] Table 1 below illustrates an example of entries of a TDRA table in accordance with some embodiments. Note that the TDRA table may include additional entries and / or parameters not shown in Table 1. Table 1

[0060] The repetition number may correspond to a number of slots allocated for the PUSCH. In some embodiments, the repetition number includes the OCC operation (e.g., the total number of slots allocated for the PUSCH) . In this case, it may be required that the OCC length is equal to or smaller than the repetition number and the repetition number is divisible by OCC length. For example, if the repetition number is 4 or 8, the OCC length may be 1, 2, or 4 (or 8 for repetition number of 8 if OCC length 8 is supported) . If the repetition number is 2, the OCC length may be 1 or 2. If the repetition number is 3, 5, or 7, then only OCC length 1 may be supported.

[0061] In other embodiments, the repetition number may not include the OCC operation. For example, the repetition number may indicate the number of OCC periods allocated for the PUSCH. The total number of slots allocated for the PUSCH transmission may be equal to the repetition number multiplied by the OCC length. For example, if the repetition number is 4 and the OCC length is 2, then the total number of slots allocated to the PUSCH is 8.

[0062] The UE may further receive a scheduling message to schedule the PUSCH transmission with OCC. The scheduling message may include a TDRA index corresponding to an entry of the TDRA table. The TDRA index may indicate an OCC length, an OCC sequence, a repetition number, and / or other parameters for the PUSCH transmission. In embodiments, the scheduling message may include a DCI, an RRC message, and / or a MAC control element (CE) .

[0063] FIG. 2 illustrates an example procedure 200 for determining OCC length and OCC sequence in accordance with some embodiments. The procedure 200 may be performed by a UE (e.g., UE 104) or a portion thereof.

[0064] At 204, the procedure 200 may include receiving a common PUSCH configuration. The common PUSCH configuration may include parameters (or lists of candidate parameters) that are common to a group of UEs.

[0065] At 208, the procedure 200 may include reporting a UE capability of OCC-based PUSCH transmission. For example, the UE capability may indicate whether the UE supports OCC-based PUSCH transmission and / or a supported OCC length (e.g., length 2 or length 4) . In some embodiments, it may be required that a UE that supports length 4 OCC also supports length 2 OCC. Accordingly, a UE capability indicating support for OCC length 4 may also indicate support for OCC length 2.

[0066] At 212, the procedure 200 may include receiving a UE-specific PUSCH configuration. The UE-specific PUSCH configuration may define a TDRA table (e.g., may include a list of TDRAs and associated TDRA indexes) . The individual TDRAs may include an OCC length and / or OCC sequence.

[0067] At 216, the procedure 200 may include receiving a DCI to schedule a PUSCH. The PUSCH may be scheduled based on the common PUSCH configuration and / or the UE-specific PUSCH configuration. For example, the DCI may include a TDRA index.

[0068] At 220, the procedure 200 may include determining an OCC length and / or an OCC sequence for the PUSCH based on the DCI (e.g., based on the TDRA index and the TDRA table defined by the UE-specific PUSCH configuration) .Schemes for TBoMS with RV cycling for OCC-based PUSCH transmission

[0069] Embodiments provide schemes for TBoMS with RV cycling for OCC-based PUSCH transmission. For example, the schemes may include an order in which the TBoMS, RV cycling, and OCC are applied.

[0070] In a first example scheme, the OCC is applied first, the TBoMS is applied second, and the RV cycling is applied third. FIG. 3 illustrates an example of the first scheme with a length 2 OCC (e.g., an OCC of [1 -1] ) , a transport block (TB) transmitted across two slots (e.g., with a first TB part in a first slot and a second TB part in a second slot) , and two repetitions for individual TBs, in accordance with some embodiments. The same RV may be used for individual repetition of the same TB. The RV may be cycled to a next value when the TB is repeated. In an example, the RV may be cycled between four values with an order of RV0, RV2, RV3, RV1. In this scheme, the same RV value is used in N OCC periods / cycles / groups and RV cycling across N OCC groups is supported, where N is the number of slots per TB.

[0071] FIG. 3 illustrates eight slots 304a-h. With the OCC applied first, the first part of a first repetition of a TB (e.g., with RV0) may be transmitted in slot 304a and slot 304b, and the OCC may be applied across slots 304a and 304b. For example, OCC of 1 may be applied to slot 304a and OCC of -1 may be applied to slot 304b. Note that another UE may use a different OCC (e.g., [1 1] ) across the same slots with orthogonality between the transmissions.

[0072] With TBoMS applied second, the second part of the TB (e.g., with RV0) may be transmitted in subsequent slots 304c and 304d. The OCC may be applied across slots 304c and 304d (e.g., with OCC of 1 applied to slot 304c and OCC of -1 applied to slot 304d) .

[0073] With RV cycling applied third, a second repetition of the TB (e.g., with RV2) may then be transmitted in slots 304e-h. Similar to transmission of the TB in slots 304a-d, a first part of the TB repetition may be transmitted in slots 304e and 304f with OCC applied across the slots 304e and 304f. A second part of the TB repetition may be transmitted in slots 304g and 304h with OCC applied across the slots 304g and 304h.

[0074] In a second example scheme, OCC is applied first, RV cycling is applied second, and TBoMS is applied third. FIG. 4 illustrates an example of the second scheme with a length 2 OCC (e.g., an OCC of [1 -1] ) , a TB transmitted across two slots, and two repetitions for individual TBs, in accordance with some embodiments.

[0075] Eight slots 404a-h are illustrated in FIG. 4. With the OCC applied first, the first part of a first repetition of a TB (e.g., with RV0) may be transmitted in slot 404a and slot 404b, and the OCC may be applied across slots 404a and 404b. For example, OCC of 1 may be applied to slot 404a and OCC of -1 may be applied to slot 404b. Note that another UE may use a different OCC (e.g., [1 1] ) across the same slots with orthogonality between the transmissions.

[0076] With RV cycling applied second, a first part of the TB with a second RV (e.g., with RV2) may be transmitted in slots 404c and 404d. The OCC may be applied across slots 404c and 404d.

[0077] With TBoMS applied third, a second part of the TB with the first RV (e.g., with RV0) may be transmitted in slots 404e and 404f, with OCC applied across slots 404e and 404f. A second part of the TB with the second RV (e.g., with RV2) may be transmitted in slots 404g and 404h, with OCC applied across slots 404g and 404h.

[0078] In a third example scheme, TBoMS is applied first, OCC cycling is applied second, and RV cycling is applied third. FIG. 5 illustrates an example of the third scheme with a length 2 OCC (e.g., an OCC of [1 -1] ) , a TB transmitted across two slots, and two repetitions for individual TBs, in accordance with some embodiments.

[0079] Eight slots 504a-h are illustrated in FIG. 5. With TBoMS applied first, a first part of a TB with a first RV (e.g., with RV0) is transmitted in slot 504a and a second part of the TB with the first RV is transmitted in subsequent slot 504b. With OCC cycling second, the first and second parts of the TB with the first RV are also transmitted in respective slots 504c and 504d. The OCC is applied across slots 504a and 504c and across slots 504b and 504d. For example, OCC of 1 may be applied to slots 504a and 504b, and OCC of -1 may be applied to slots 504c and 504d.

[0080] With RV cycling applied third, the TB may be transmitted with the second RV (e.g., with RV2) in slots 504e-h. For example, a first part of the TB with the second RV may be transmitted in slots 504e and 504g and a second part of the TB with the second RV may be transmitted in slots 504f and 504h. The OCC may be applied across slots 504e and 504g and across slots 504f and 504h.

[0081] In some instances, the first example scheme of FIG. 3 may be preferred due to ease of implementation. However, embodiments herein may not be limited to a particular scheme.PUCCH repetition overlap with OCC-based PUSCH repetition

[0082] Embodiments provide techniques to handle overlap between a PUCCH repetition (e.g., with UCI) and an OCC-based PUSCH repetition. In legacy operation (with PUSCH transmitted without OCC) , if a PUCCH repetition overlaps with a PUSCH repetition (type A, type B, or TBoMS) , then the PUSCH repetition is dropped (e.g., as described in 3GPP TS 38.213, Section 9.2.6) . However, the legacy operation does not consider OCC-based PUSCH transmission, in which it may be required to transmit or drop a PUSCH over an entire OCC period in order to maintain orthogonality with another PUSCH transmitted by another UE with a different OCC.

[0083] In a first scheme in accordance with some embodiments, if a PUCCH repetition (e.g., with UCI) overlaps with a PUSCH that is to be transmitted with OCC, the PUSCH may be dropped (not transmitted) in the overlapping slot (s) and in the other slots of one or more OCC periods that encompass the overlapping slot (s) . In some instances, the UE may transmit additional PUCCH repetitions in the other slots of the one or more OCC periods.

[0084] FIGS. 6A and 6B illustrate examples of the first scheme for handling overlap between a PUCCH repetition and an OCC-based PUSCH. As shown, a UE may be scheduled (e.g., triggered) to transmit PUCCH repetitions 604a-b in respective slots. The PUCCH repetitions 604a-b may include UCI in some embodiments. The UE may further be scheduled to transmit PUSCH repetitions 608a-d in respective slots. The PUSCH repetitions 608a-d may be included in a same OCC period 612a (e.g., over which a length 4 OCC is to be applied) . The PUSCH repetitions 608b and 608c may overlap with PUCCH repetitions 604a-b. Based on the overlap, all PUSCH repetitions 608a-d included in the OCC period 612a may be dropped.

[0085] In some embodiments, based on dropping PUSCH repetitions 608a and / or 608d, the UE may transmit additional PUCCH repetitions 616a and / or 616b in the slots in which PUSCH repetitions 608a and 608d, respectively, were to be transmitted. The additional PUCCH repetitions 616a and / or 616b may include the same control information (e.g., UCI) that is included in PUCCH repetitions 604a and / or 604b.

[0086] FIG. 6A further illustrates an OCC period 612b that is subsequent to OCC period 612a. PUSCH repetitions 620a-d may be transmitted in OCC period 612b since there is no overlapping PUCCH transmission.

[0087] FIG. 6B illustrates another example scenario in which PUCCH repetitions 624a and 624b are to be transmitted in different OCC periods 628a-b of an OCC-based PUSCH. For example, as shown, PUSCH repetitions 632a-b are scheduled to be transmitted in OCC period 628a and PUSCH repetitions 636a-b are scheduled to be transmitted in OCC period 628b. PUCCH repetition 624a overlaps with PUSCH repetition 632b and PUCCH repetition 624b overlaps with PUSCH repetition 636a. Based on the overlap with PUSCH repetition 632b, all PUSCH repetitions of OCC period 628a (e.g., including both PUSCH repetition 632b and PUSCH repetition 632a) are dropped. Based on the overlap with PUSCH repetition 636a, all PUSCH repetitions of OCC period 628b (e.g., including both PUSCH repetition 636a and PUSCH repetition 636b) are dropped.

[0088] In some embodiments, the UE may transmit additional PUCCH repetitions 640a-b in the slots in which PUSCH repetition 632a and / or 636b were to be transmitted. The additional PUCCH repetitions 640a and / or 640b may include the same control information (e.g., UCI) that is included in PUCCH repetitions 624a and / or 624b.

[0089] In a second scheme for handling overlap between PUCCH and OCC-based PUSCH in accordance with some embodiments, the UE may multiplex the PUCCH (e.g., UCI) on the OCC-based PUSCH. The UCI may be multiplexed on all PUSCH repetitions of one or more OCC periods (e.g., to maintain orthogonality, which may require that the same content be transmitted in each PUSCH repetition of an OCC period) .

[0090] For example, if all the PUCCH repetitions are within one OCC period of the PUSCH, the UCI may be multiplexed on all of the PUSCH repetitions in that OCC period. If the PUCCH repetitions overlap with two or more OCC periods of the PUSCH, different schemes may be used in accordance with embodiments herein. In a first scheme, the UCI may be multiplexed in all PUSCH repetitions that are included in an OCC period that overlaps with at least one of the PUCCH repetitions. In a second scheme, the UCI may be multiplexed in the PUSCH repetitions of only one of the OCC periods that overlaps with the PUCCH repetitions. For example, the UCI may be multiplexed on the PUSCH repetitions of the earliest OCC period that overlaps with the PUCCH or the latest OCC period that overlaps with the PUCCH repetitions. In some embodiments, the OCC period in which the UCI is multiplexed may be determined based on one or more timeline restrictions. Additionally, it may be required that the total number of PUSCH repetitions in which UCI is multiplexed is equal to or larger than the number of PUCCH repetitions that were to be transmitted (e.g., without multiplexing) .

[0091] In some embodiments, the UE behavior for multiplexing UCI on an OCC-based PUSCH may be configured by the network. For example, the network may indicate one of the schemes described above and / or one or more timeline restrictions used by the UE to determine the PUSCH repetitions on which the UCI is to be multiplexed.

[0092] FIG. 7 illustrates an example of UCI multiplexing on OCC-based PUSCH in accordance with some embodiments. As shown, OCC-based PUSCH repetitions 704a-d may be scheduled in OCC period 708a and OCC-based PUSCH repetitions 712a-d may be scheduled in OCC period 708b. Additionally, the UE may have UCI to report in PUCCH repetitions 716a-b. The PUCCH repetitions 716a-b may overlap with the PUSCH repetitions 704b-c, respectively, of OCC period 708a. Based on the overlap, the UCI may be multiplexed in all of the PUSCH repetitions 704a-d of OCC period 708a (e.g., to maintain orthogonality in the OCC period 708a) . Accordingly, the PUCCH repetitions 716a-b may be dropped (not transmitted) .

[0093] Since there is no PUCCH repetition that overlaps with any of PUSCH repetitions 712a-d of OCC period 708b, the PUSCH repetitions 712a-d may be transmitted without multiplexing UCI.

[0094] FIGS. 8A, 8B, and 8C illustrate examples of UCI multiplexing on OCC-based PUSCH when the PUCCH repetitions overlap with multiple OCC periods, in accordance with some embodiments. In the example of FIG. 8A, the UCI is multiplexed in all PUSCH repetitions of each OCC period that overlaps with at least one PUCCH repetition. In the example of FIG. 8B, the UCI is multiplexed in all PUSCH repetitions of the earliest OCC period that overlaps with at least one of the PUCCH repetitions (and not in the other OCC period (s) that overlap with at least one of the PUCCH repetitions) . In the example of FIG. 8C, the UCI is multiplexed in all PUSCH repetitions of the latest OCC period that overlaps with at least one of the PUCCH repetitions (and not in the other OCC period (s) that overlap with at least one of the PUCCH repetitions) .

[0095] As shown in FIGS. 8A-8C, PUCCH repetitions 804a and 804b are to be transmitted in different OCC periods 808a-b of an OCC-based PUSCH. For example, PUSCH repetitions 812a-b are scheduled to be transmitted in OCC period 808a and PUSCH repetitions 816a-b are scheduled to be transmitted in OCC period 808b. PUCCH repetition 804a overlaps with PUSCH repetition 812b and PUCCH repetition 804b overlaps with PUSCH repetition 816a.

[0096] In the example of FIG. 8A, based on the overlap of PUCCH repetition 804a with PUSCH repetition 812b of OCC period 808a, the UCI is multiplexed in all PUSCH repetitions 812a-b of OCC period 808a. Additionally, based on the overlap of PUCCH repetition 804b with PUSCH repetition 816a, the UCI is multiplexed in all PUSCH repetitions 816a-b of OCC period 808b. The PUCCH repetitions 804a-b may be dropped.

[0097] In the example of FIG. 8B, the UCI is multiplexed in the PUSCH repetitions 812a-b of the earliest OCC period 808a that overlaps with one of the PUCCH repetitions 804a-b. In the example of FIG. 8C, the UCI is multiplexed in the PUSCH repetitions 816a-b of the latest OCC period 808b that overlaps with one of the PUCCH repetitions 804a-b. In some embodiments, the UE may determine the OCC period in which to multiplex the UCI based on one or more timing requirements. For example, the determination may be based on whether the UCI is available to transmit in the earliest PUSCH repetition of the earliest OCC period that overlaps with at least one of the PUCCH repetitions.

[0098] In some embodiments in which the PUCCH repetitions overlap with more than two OCC periods, the UCI may be multiplexed in the second earliest OCC period that overlaps with at least one of the PUCCH repetitions. This may ensure that the UCI is available to transmit while also enabling earlier transmission of the UCI compared with waiting for the last overlapping OCC period.

[0099] In some embodiments, for a PUCCH (with UCI) that overlaps with an OCC-based PUSCH transmission, the UE may determine whether to transmit the PUCCH, drop the PUCCH, or multiplex the UCI on the PUSCH based on a content of the UCI and / or a CSI reporting trigger that triggers the PUCCH. For example, the content of the UCI may include HARQ-ACK feedback, a scheduling request (SR) , and / or CSI (e.g., CSI part 1 and / or CSI part 2) . The CSI reporting trigger may include periodic, semi-persistent, or aperiodic.

[0100] In an example, if the UCI includes HARQ-ACK feedback and / or an SR, the UCI may be transmitted on the PUCCH or multiplexed on the PUSCH. The UCI may additionally include other content, such as CSI. If the UCI includes CSI (e.g., CSI part 1 and / or CSI part 2) without HARQ-ACK feedback or an SR, then the UCI may be dropped.

[0101] In another example, if the UCI corresponds to an aperiodic CSI report, the UCI may be transmitted on PUCCH or multiplexed on PUSCH. Additionally, or alternatively, if the UCI corresponds to a semi-persistent CSI report, the UCI may be multiplexed on the PUSCH. Additionally, or alternatively, if the UCI corresponds to a periodic CSI report, the UCI may be dropped.Timeline of CSI processing with OCC-based PUSCH

[0102] According to 3GPP TS 38.214, Section 5.4, V18.5.0, when CSI request field in DCI triggers aperiodic CSI reports, the UE shall provide a valid report: -If the first uplink symbol to carry CSI report including TA [ (timing advance) ] , starts  no earlier than symbol Zref, where Zref is the next uplink symbol with its CP [ (cyclic prefix) ] starting Tproc, CSI= (Z) (2048+144) ·k·2-μ·Tc·Tswitch after the end of the last symbol of the PDCCH triggering the CSI report. -If the PUSCH indicated by the DCI is overlapping with another PUCCH or PUSCH,  then the CSI report (s) are multiplexed. -If the first uplink symbol to carry CSI report including TA, starts no earlier than  symbol Zref, then UE may ignore the scheduling DCI if no HARQ-ACK or TB is multiplexed on the PUSCH.

[0103] The existing timeline requirements do not take into account OCC-based PUSCH transmissions. Embodiments herein provide timeline definition for CSI processing and reporting with OCC-based PUSCH.

[0104] In various embodiments, according to a scheduling requirement, if the PUCCH indicated by DCI overlaps with OCC-based PUSCH repetitions, and if the first symbol of the PUSCH repetitions in the corresponding OCC period starts no earlier than symbol Zref, then UE shall provide valid reports on all PUSCH repetitions in this OCC period. The symbol Zref may correspond to the next symbol (e.g., based on a start of the associated CP) that is at least a processing time (Tproc, CSI) after the PDCCH that triggers the CSI report (e.g., after the last symbol of the PDCCH) .

[0105] In some embodiments, if the scheduling requirement is not met, the UE may ignore the scheduling DCI. For example, the UE may not transmit the CSI report triggered by the DCI.

[0106] FIG. 9 illustrates an example of this scheduling scheme in accordance with some embodiments. As shown, the UE may receive a DCI 904 that schedules a PUCCH 908 (e.g., for a CSI report such as an aperiodic CSI report) . The UE is also scheduled to transmit PUSCH repetitions 912a-b in a first OCC period 916a and PUSCH repetitions 920a-b in a second OCC period 916b. FIG. 9 further illustrates symbol Zref 924 (which may be a processing time (Tproc, CSI) after the DCI 904) . The PUCCH 908 overlaps with PUSCH repetition 912b and the symbol Zref 924 overlaps with PUSCH repetition 912a.

[0107] The scheduling requirement applies since the PUCCH 908 overlaps with one of the PUSCH repetitions 912a-b of the first OCC period 916a. If the earliest PUSCH repetition 912a of the first OCC period 916a started no earlier than symbol Zref 924, then the CSI would be multiplexed in the PUSCH repetitions 912a-b. However, since the PUSCH repetition 912a starts before the symbol Zref 924, the PUCCH 908 (or corresponding UCI) is dropped (not transmitted) , or alternatively, PUSCH repetitions 912a and 912b in the overlapping OCC period are dropped and PUCCH is transmitted.

[0108] In other embodiments, if the scheduling requirement is not met, the UE may report the CSI in all PUSCH repetitions of the subsequent OCC period. For example, referring again to FIG. 9, the PUCCH 908 may be multiplexed in PUSCH repetitions 920a-b of the second OCC period 916b that is subsequent to OCC period 916a. In some instances, the CSI may be multiplexed in the subsequent OCC period if the first symbol of the PUSCH repetitions in the subsequent OCC period starts no earlier than symbol Zref. Otherwise, the CSI may be dropped.

[0109] In another example, if a PUCCH without repetition overlaps with PUSCH repetitions of an OCC-based PUSCH, the UCI (e.g., CSI) may be multiplexed with the PUSCH repetitions if the first uplink symbol of the PUSCH repetitions is at least after the end of the last symbol of the triggering PDCCH (e.g., corresponding to the symbol Zref when processing time is added) . Otherwise, if there is a subsequent OCC group, the UCI may be multiplexed on the subsequent OCC group (e.g., the PUCCH 908 may be multiplexed in PUSCH repetitions 920a-b of FIG. 9) . If there is no subsequent OCC group, the UCI may be dropped or the UCI may be transmitted in the PUCCH and all of the PUSCH repetitions within the OCC group overlapping with the PUCCH are dropped.Indication of TBoMS usage with intra-symbol OCC

[0110] Various embodiments further provide mechanisms to indicate to the UE whether to use TBoMS with intra-symbol OCC. In some embodiments, when intra-symbol OCC is applied, TMoMS is always used (e.g., according to a pre-defined rule) .

[0111] In other embodiments, the UE may receive an indication from the network of whether to use TBoMS when intra-symbol OCC is scheduled. For example, the indication may be included in an SIB, an RRC message, a MAC CE, and / or a DCI. In an example, the RRC message may configure a type 1 or type 2 configured grant PUSCH, and the configuration may indicate whether TBoMS is applied for OCC-based PUSCH. For example, the indication may be included in information element “ConfiguredGrantConfig” such as represented by a single bit. In another example, the UE may receive a DCI format 0_1 or 0_2 to schedule the OCC-based PUSCH and the DCI may include a field (e.g., a single bit) to indicate whether TBoMS is used when intra-symbol OCC is applied. In some embodiments, the UE may provide UE capability information to the network to indicate whether the UE supports PUSCH transmission with intra-symbol OCC and / or TBoMS.

[0112] FIG. 10 illustrates an example procedure 1000 in accordance with some embodiments. The procedure 1000 may be performed by a network device, such as base station 108 and / or another device of RAN 110, or components thereof.

[0113] At 1004, the procedure 1000 may include receiving UE capability information to indicate a UE capability of intra-symbol OCC-based PUSCH transmission and TBoMS.

[0114] At 1008, the procedure 1000 may include, generating, for transmission to the UE (e.g., based on the UE capability information) , an indication of whether TBoMS is to be applied for an intra-symbol OCC-based PUSCH transmission. For example, the indication may be included in a message that schedules the intra-symbol OCC-based PUSCH transmission.

[0115] At 1012, the procedure 1000 may further include receiving the intra-symbol OCC-based PUSCH transmission based on whether TBoMS is to be applied.Indication of OCC sequence in combined OCC schemes

[0116] Various embodiments provide mechanisms for the network to indicate, to the UE, OCC sequences to apply for different OCC schemes (e.g., intra-symbol OCC and / or inter-slot OCC) . In some embodiments, the network may transmit separate indications to the UE to indicate the OCC sequences for different OCC schemes. For example, the UE may receive a first indication of a first OCC sequence for inter-slot OCC (e.g., [1 1] or another suitable sequence) and a second indication of a second OCC sequence for intra-symbol OCC (e.g., [1 -1] or another suitable sequence) . In another example, the UE may receive an OCC table with multiple OCC sequences and associated OCC indexes (e.g., [1 1; 1 -1] ) . A first OCC index (e.g., OCC index 0) may correspond to inter-slot OCC and a second OCC index (e.g., OCC index 1) may correspond to intra-symbol OCC.

[0117] In other embodiments, the network may provide the UE a joint indication of the OCC sequences for different OCC schemes. For example, the UE may receive an OCC table that indicates sets of OCC sequences, with individual OCC sequences of a set corresponding to a respective OCC scheme and a respective OCC index associated with each set. Accordingly, the UE may receive a single OCC index to indicate the OCC sequences to use for the different OCC schemes.

[0118] To illustrate, an example OCC table may include:

[0119] The first two columns of the OCC table may be used for inter-slot OCC and the last two columns of the OCC table may be used for intra-symbol OCC. Each row of the OCC table may correspond to a set of OCC sequences associated with a respective OCC index. The UE may receive a single OCC index to indicate a respective set of OCC sequences (e.g., a respective row of the OCC table) .SIB1 monitoring window

[0120] In various embodiments, an SIB1 monitoring window may be defined in which the contents of Type 0 common search space (CSS) PDCCH and / or SIB1 PDSCH do not change. The type 0 CSS PDCCH may be used to transmit the PDCCH for SIB1 (e.g., including DCI to schedule the SIB1) . The use of the SIB1 monitoring window may allow the combination of multiple PDCCHs for decoding, which may provide coverage enhancement.

[0121] For example, FIG. 11 illustrates an example of an SIB1 monitoring window 1104, in accordance with some embodiments. As shown, the SIB1 monitoring window 1104 may span a plurality of radio frames 1108a-h. Type 0 CSS PDCCHs 1112a-d may be transmitted periodically according to a PDCCH monitoring periodicity (e.g., 20 ms) . Within the SIB1 monitoring window 1104, the type 0 CSS PDCCHs 1112a-d may have the same content.

[0122] In an example, the SIB1 monitoring window may be 20 milliseconds (ms) to 160 ms, such as 20, 40, 80, or 160 ms. In some embodiments, the usage and / or length of the SIB1 monitoring window may be indicated by PBCH and / or master information block (MIB) . For example, the indication may include a single bit to indicate whether or not the SIB1 monitoring window is activated (e.g., with a predefined length) . In another example, the indication may include two or more bits to indicate a length of the SIB1 monitoring window (e.g., two bits, where (0, 0) indicates no SIB1 monitoring window; (0, 1) indicates an SIB1 monitoring window of length 40 ms; (1, 0) indicates an SIB1 monitoring window of length 80 ms;and / or (1, 1) indicates an SIB1 monitoring window of length 160 ms) .Example operation flows / algorithmic structures

[0123] FIG. 12 illustrates an operation flow / algorithmic structure 1200 in accordance with some embodiments. The operation flow / algorithmic structure 1200 may be performed by a UE, such as UE 104, UE 106, or components therein, for example, baseband processor 1504A.

[0124] The operation flow / algorithmic structure 1200 may include, at 1204, receiving a message to schedule a PUSCH, wherein the message includes a TDRA index. For example, the message may include a DCI.

[0125] The operation flow / algorithmic structure 1200 may further include, at 1208, determining, based on the TDRA index, an OCC length or an OCC sequence for the PUSCH. For example, the OCC length and / or the OCC sequence may be determined based on a TDRA table that includes entries corresponding to respective TDRA indexes. In some embodiments, the UE may further determine a repetition number based on the TDRA index. In an example, the repetition number includes application of OCC, wherein the OCC length is equal to or smaller than the repetition number and the repetition number is divisible by the OCC length. In another example, a number of slots allocated for the PUSCH is equal to the repetition number multiplied by the OCC length.

[0126] The operation flow / algorithmic structure 1200 may further include, at 1212, generating the PUSCH for transmission with an OCC based on the OCC length or the OCC sequence. For example, generating the PUSCH for transmission may include applying OCC cycling, TBoMS processing, and / or RV cycling in a defined order. In some embodiments, generating the PUSCH for transmission may include applying OCC cycling to the PUSCH, applying TBoMS to the PUSCH after applying OCC cycling, and applying RV cycling to the PUSCH after applying OCC cycling and TBoMS. In other embodiments, generating the PUSCH for transmission may include applying OCC cycling to the PUSCH, applying RV cycling to the PUSCH after applying OCC cycling, and applying TBoMS to the PUSCH after applying OCC cycling and RV cycling. In other embodiments, generating the PUSCH for transmission may include applying TBoMS to the PUSCH, applying OCC cycling to the PUSCH after applying the OCC cycling, and applying RV cycling to the PUSCH after applying the TBoMS and the OCC cycling.

[0127] FIG. 13 illustrates another operation flow / algorithmic structure 1300 in accordance with some embodiments. The operation flow / algorithmic structure 1300 may be performed by a UE, such as UE 104, UE 106, or components therein, for example, baseband processor 1504A.

[0128] The operation flow / algorithmic structure 1300 may include, at 1304, identifying that a PUCCH with UCI overlaps with a PUSCH to be transmitted with an OCC in an OCC period.

[0129] The operation flow / algorithmic structure 1300 may further include, at 1308, based on the identification: dropping all PUSCH repetitions in the OCC period and outputting the PUCCH for transmission; or multiplexing the UCI for transmission in all PUSCH repetitions in the OCC period. In an example, the PUCCH may be scheduled with a number of PUCCH repetitions that is less than a number of slots in the OCC period, and the UE may drop all the PUSCH repetitions in the OCC period and output the PUCCH for transmission in all the slots in the OCC period (e.g., with additional PUCCH repetitions in slots that were not initially scheduled) .

[0130] In another example, the PUCCH may include PUCCH repetitions in first and second OCC periods. The UE may multiplex the UCI in all of the PUSCH repetitions of the first OCC period only, the second OCC period only, or both the first and second OCC periods. In some embodiments, the multiplexing may be based on one or more timing requirements. For example, the UE may multiplex the UCI in all the PUSCH repetitions of the second OCC period based on an earliest second PUSCH repetition of the first OCC period being after a reference symbol. The reference symbol may be a processing time after a message (e.g., DCI) that schedules the PUCCH. In some embodiments, the multiplexing may additionally or alternatively be based on a content of the UCI and / or a triggering mechanism that triggered reporting of the UCI (e.g., dynamic, semi-persistent, or periodic) .

[0131] FIG. 14 illustrates another operation flow / algorithmic structure 1400 in accordance with some embodiments. The operation flow / algorithmic structure 1400 may be performed by a network device, such as base station 108, or components therein, for example, baseband processor 1604A.

[0132] The operation flow / algorithmic structure 1400 may include, at 1404, generating, for transmission to a UE, a PUSCH configuration to configure a TDRA table, wherein individual entries of the TDRA table are associated with respective TDRA indexes and indicate an OCC length or an OCC sequence. In an example, the PUSCH configuration may be transmitted via RRC signaling.

[0133] The operation flow / algorithmic structure 1400 may further include, at 1408, generating, for transmission to the UE, a message to schedule an OCC-based PUSCH, wherein the message includes a first TDRA index to indicate the OCC length or the OCC sequence for the OCC-based PUSCH based on the TDRA table. In an example, the message may include a DCI. In some embodiments, the first TDRA index may further indicate a repetition number for the PUSCH based on the TDRA table. The repetition number may or may not include the application of OCC.

[0134] The operation flow / algorithmic structure 1400 may further include, at 1412, receiving the OCC-based PUSCH from the UE. In an example, the OCC-based PUSCH may be received / decoded based on a defined order of applying OCC cycling, TBoMS, and / or RV cycling. In some embodiments, the network device may further receive UCI that is multiplexed in all PUSCH repetitions of the OCC-based PUSCH. The UCI may be multiplexed in the PUSCH repetitions based on one or more timing requirements, a content of the UCI, and / or a triggering mechanism that triggered reporting of the UCI (e.g., dynamic, semi-persistent, or periodic) .Example Devices

[0135] FIG. 15 illustrates a UE 1500 in accordance with some embodiments. The UE 1500 may be similar to and substantially interchangeable with UE 104 or 106.

[0136] The UE 1500 may be any mobile or non-mobile computing device, such as, for example, mobile phones, computers, tablets, industrial wireless sensors (for example, microphones, carbon dioxide sensors, pressure sensors, humidity sensors, thermometers, motion sensors, accelerometers, laser scanners, fluid level sensors, inventory sensors, electric voltage / current meters, or actuators) , video surveillance / monitoring devices (for example, cameras or video cameras) , wearable devices (for example, a smart watch) , or Internet-of-things devices.

[0137] The UE 1500 may include processors 1504, RF interface circuitry 1508, memory / storage 1512, user interface 1516, sensors 1520, driver circuitry 1522, power management integrated circuit (PMIC) 1524, antenna 1526, and battery 1528. The components of the UE 1500 may be implemented as integrated circuits (ICs) , portions thereof, discrete electronic devices, or other modules, logic, hardware, software, firmware, or a combination thereof. The block diagram of FIG. 15 is intended to show a high-level view of some of the components of the UE 1500. However, some of the components shown may be omitted, additional components may be present, and different arrangement of the components shown may occur in other implementations.

[0138] The components of the UE 1500 may be coupled with various other components over one or more interconnects 1532, which may represent any type of interface, input / output, bus (local, system, or expansion) , transmission line, trace, or optical connection that allows various circuit components (on common or different chips or chipsets) to interact with one another.

[0139] The processors 1504 may include processor circuitry such as, for example, baseband processor circuitry (BB) 1504A, central processor unit circuitry (CPU) 1504B, and graphics processor unit circuitry (GPU) 1504C. The processors 1504 may include any type of circuitry or processor circuitry that executes or otherwise operates computer-executable instructions, such as program code, software modules, or functional processes from memory / storage 1512 to cause the UE 1500 to perform operations associated with OCC-based PUSCH transmission as described herein. The processors 1504 may also include interface circuitry 1504D to enable communication by, for example, communicatively coupling the processor circuitry with one or more other components of the UE 1500.

[0140] In some embodiments, the baseband processor circuitry 1504A may access a communication protocol stack 1536 in the memory / storage 1512 to communicate over a 3GPP compatible network. In general, the baseband processor circuitry 1504A may access the communication protocol stack 1536 to: perform user plane functions at a PHY layer, MAC layer, RLC layer, PDCP layer, SDAP layer, and PDU layer; and perform control plane functions at a PHY layer, MAC layer, RLC layer, PDCP layer, RRC layer, and a NAS layer. In some embodiments, the PHY layer operations may additionally / alternatively be performed by the components of the RF interface circuitry 1508.

[0141] The baseband processor circuitry 1504A may generate or process baseband signals or waveforms that carry information in 3GPP-compatible networks. In some embodiments, the waveforms for NR may be based on cyclic prefix OFDM (CP-OFDM) in the uplink or downlink, and discrete Fourier transform spread OFDM (DFT-S-OFDM) in the uplink.

[0142] The memory / storage 1512 may include one or more non-transitory, computer-readable media that includes instructions (for example, communication protocol stack 1536) that may be executed by one or more of the processors 1504 to cause the UE 1500 to perform various operations associated with OCC-based PUSCH transmission described herein.

[0143] The memory / storage 1512 includes any type of volatile or non-volatile memory that may be distributed throughout the UE 1500. In some embodiments, some of the memory / storage 1512 may be located on the processors 1504 themselves (for example, memory / storage 1512 may be part of a chipset that corresponds to the baseband processor circuitry 1504A) , while other memory / storage 1512 is external to the processors 1504 but accessible thereto via a memory interface. The memory / storage 1512 may include any suitable volatile or non-volatile memory such as, but not limited to, dynamic random access memory (DRAM) , static random access memory (SRAM) , erasable programmable read only memory (EPROM) , electrically erasable programmable read only memory (EEPROM) , Flash memory, solid-state memory, or any other type of memory device technology.

[0144] The RF interface circuitry 1508 may include transceiver circuitry and a radio frequency front module (RFEM) that allows the UE 1500 to communicate with other devices over a radio access network. The RF interface circuitry 1508 may include various elements arranged in transmit or receive paths. These elements may include, for example, switches, mixers, amplifiers, filters, synthesizer circuitry, and control circuitry.

[0145] In the receive path, the RFEM may receive a radiated signal from an air interface via antenna 1526 and proceed to filter and amplify (with a low-noise amplifier) the signal. The signal may be provided to a receiver of the transceiver that down-converts the RF signal into a baseband signal that is provided to the baseband processor of the processors 1504.

[0146] In the transmit path, the transmitter of the transceiver up-converts the baseband signal received from the baseband processor and provides the RF signal to the RFEM. The RFEM may amplify the RF signal through a power amplifier prior to the signal being radiated across the air interface via the antenna 1526.

[0147] In various embodiments, the RF interface circuitry 1508 may be configured to transmit / receive signals in a manner compatible with NR access technologies.

[0148] The antenna 1526 may include antenna elements to convert electrical signals into radio waves to travel through the air and to convert received radio waves into electrical signals. The antenna elements may be arranged into one or more antenna panels. The antenna 1526 may have antenna panels that are omnidirectional, directional, or a combination thereof to enable beamforming and multiple input, multiple output communications. The antenna 1526 may include microstrip antennas, printed antennas fabricated on the surface of one or more printed circuit boards, patch antennas, or phased array antennas. The antenna 1526 may have one or more panels designed for specific frequency bands including bands in FR1 or FR2.

[0149] The user interface 1516 includes various input / output (I / O) devices designed to enable user interaction with the UE 1500. The user interface 1516 includes input device circuitry and output device circuitry. Input device circuitry includes any physical or virtual means for accepting an input including, inter alia, one or more physical or virtual buttons (for example, a reset button) , a physical keyboard, keypad, mouse, touchpad, touchscreen, microphones, scanner, headset, or the like. The output device circuitry includes any physical or virtual means for showing information or otherwise conveying information, such as sensor readings, actuator position (s) , or other like information. Output device circuitry may include any number or combinations of audio or visual display, including, inter alia, one or more simple visual outputs / indicators (for example, binary status indicators such as light emitting diodes (LEDs) and multi-character visual outputs, or more complex outputs such as display devices or touchscreens (for example, liquid crystal displays (LCDs) , LED displays, quantum dot displays, and projectors) , with the output of characters, graphics, multimedia objects, and the like being generated or produced from the operation of the UE 1500.

[0150] The sensors 1520 may include devices, modules, or subsystems whose purpose is to detect events or changes in their environment and send the information (sensor data) about the detected events to some other device, module, or subsystem. Examples of such sensors include inertia measurement units comprising accelerometers, gyroscopes, or magnetometers; microelectromechanical systems or nanoelectromechanical systems comprising 3-axis accelerometers, 3-axis gyroscopes, or magnetometers; level sensors; flow sensors; temperature sensors (for example, thermistors) ; pressure sensors; barometric pressure sensors; gravimeters; altimeters; image capture devices (for example, cameras or lensless apertures) ; light detection and ranging sensors; proximity sensors (for example, infrared radiation detector and the like) ; depth sensors; ambient light sensors; ultrasonic transceivers; and microphones or other like audio capture devices.

[0151] The driver circuitry 1522 may include software and hardware elements that operate to control particular devices that are embedded in the UE 1500, attached to the UE 1500, or otherwise communicatively coupled with the UE 1500. The driver circuitry 1522 may include individual drivers allowing other components to interact with or control various input / output (I / O) devices that may be present within, or connected to, the UE 1500. For example, driver circuitry 1522 may include a display driver to control and allow access to a display device, a touchscreen driver to control and allow access to a touchscreen interface, sensor drivers to obtain sensor readings of sensors 1520 and control and allow access to sensors 1520, drivers to obtain actuator positions of electro-mechanic components or control and allow access to the electro-mechanic components, a camera driver to control and allow access to an embedded image capture device, audio drivers to control and allow access to one or more audio devices.

[0152] The PMIC 1524 may manage power provided to various components of the UE 1500. In particular, with respect to the processors 1504, the PMIC 1524 may control power-source selection, voltage scaling, battery charging, or DC-to-DC conversion.

[0153] A battery 1528 may power the UE 1500, although in some examples the UE 1500 may be mounted deployed in a fixed location and may have a power supply coupled to an electrical grid. The battery 1528 may be a lithium ion battery, a metal-air battery, such as a zinc-air battery, an aluminum-air battery, a lithium-air battery, and the like. In some implementations, such as in vehicle-based applications, the battery 1528 may be a typical lead-acid automotive battery.

[0154] FIG. 16 illustrates a network device 1600 in accordance with some embodiments. The network device 1600 may be similar to and substantially interchangeable with base station 108 or a device of the core network 112 or external data network 120.

[0155] The network device 1600 may include processors 1604, RF interface circuitry 1608 (if implemented as a base station) , core network (CN) interface circuitry 1614, memory / storage circuitry 1612, and antenna structure 1626.

[0156] The components of the network device 1600 may be coupled with various other components over one or more interconnects 1628.

[0157] The processors 1604, RF interface circuitry 1608, memory / storage circuitry 1612 (including communication protocol stack 1610) , antenna structure 1626, and interconnects 1628 may be similar to like-named elements shown and described with respect to FIG. 15.

[0158] The processors 1604 may include processor circuitry such as, for example, baseband processor circuitry (BB) 1604A, central processor unit circuitry (CPU) 1604B, and graphics processor unit circuitry (GPU) 1604C. The processors 1604 may include any type of circuitry or processor circuitry that executes or otherwise operates computer-executable instructions, such as program code, software modules, or functional processes from memory / storage circuitry 1612 to cause the network device 1600 to perform operations associated with OCC-based PUSCH transmission described herein. The processors 1604 may also include interface circuitry 1604D to communicatively couple the processor circuitry with one or more other components of the network device 1600.

[0159] The CN interface circuitry 1614 may provide connectivity to a core network, for example, a 5th Generation Core network (5GC) using a 5GC-compatible network interface protocol such as carrier Ethernet protocols, or some other suitable protocol. Network connectivity may be provided to / from the network device 1600 via a fiber optic or wireless backhaul. The CN interface circuitry 1614 may include one or more dedicated processors or FPGAs to communicate using one or more of the aforementioned protocols. In some implementations, the CN interface circuitry 1614 may include multiple controllers to provide connectivity to other networks using the same or different protocols.

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

[0161] For one or more embodiments, at least one of the components set forth in one or more of the preceding figures may be configured to perform one or more operations, techniques, processes, or methods as set forth in the example section below. For example, the baseband circuitry as described above in connection with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples set forth below. For another example, circuitry associated with a UE, base station, network element, etc. as described above in connection with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples set forth below in the example section.Examples

[0162] Further exemplary embodiments are provided below.

[0163] Example 1 may include a method comprising: receiving a message to schedule a physical uplink shared channel (PUSCH) , wherein the message includes a time domain resource allocation (TDRA) index; determining, based on the TDRA index, an orthogonal cover code (OCC) length or an OCC sequence for the PUSCH; and generating the PUSCH for transmission with an OCC based on the OCC length or the OCC sequence.

[0164] Example 2 may include the method of example 1 or some other example herein, further comprising determining, based on the TDRA index, a repetition number that indicates a number of slots allocated for the PUSCH, wherein the repetition number includes application of OCC, wherein the OCC length is equal to or smaller than the repetition number and the repetition number is divisible by the OCC length.

[0165] Example 3 may include the method of example 1 or some other example herein, further comprising determining, based on the TDRA index, a repetition number for the PUSCH, wherein a number of slots allocated for the PUSCH is equal to the repetition number multiplied by the OCC length.

[0166] Example 4 may include the method of example 1 or some other example herein, wherein determining the OCC length or the OCC sequence includes determining an OCC sequence index based on the TDRA index and determining the OCC sequence based on the OCC sequence index.

[0167] Example 5 may include the method of example 1 or some other example herein, further comprising receiving a user equipment (UE) -specific PUSCH configuration to configure a TDRA table, wherein the TDRA index corresponds to an entry of the TDRA table that indicates the OCC length or the OCC sequence.

[0168] Example 6 may include the method of example 1 or some other example herein, wherein generating the PUSCH for transmission includes: applying OCC cycling to the PUSCH; applying transport block processing over multiple slots (TBoMS) to the PUSCH after applying the OCC cycling; and applying redundancy version (RV) cycling to the PUSCH after applying the OCC cycling and the TBoMS.

[0169] Example 7 may include the method of example 1 or some other example herein, wherein generating the PUSCH for transmission includes: applying OCC cycling to the PUSCH; applying redundancy version (RV) cycling to the PUSCH after applying the OCC cycling; and applying transport block processing over multiple slots (TBoMS) to the PUSCH after applying the OCC cycling and the RV cycling.

[0170] Example 8 may include the method of example 1 or some other example herein, wherein generating the PUSCH for transmission includes: applying transport block processing over multiple slots (TBoMS) to the PUSCH; applying OCC cycling to the PUSCH after applying the OCC cycling; and applying redundancy version (RV) cycling to the PUSCH after applying the TBoMS and the OCC cycling.

[0171] Example 9 may include an apparatus comprising processing circuitry to identify that a physical uplink control channel (PUCCH) with uplink control information (UCI) overlaps with a physical uplink shared channel (PUSCH) to be transmitted with an orthogonal cover code (OCC) in an OCC period; and based on the identification: drop all PUSCH repetitions in the OCC period and output the PUCCH for transmission; or multiplex the UCI for transmission in all PUSCH repetitions in the OCC period. The apparatus of example 9 may further comprise interface circuitry coupled to the processing circuitry to enable communication.

[0172] Example 10 may include the apparatus of example 9 or some other example herein, wherein the PUCCH is scheduled with a number of PUCCH repetitions that is less than a number of slots in the OCC period, wherein the processing circuitry is to drop all the PUSCH repetitions in the OCC period and output the PUCCH for transmission in all the slots in the OCC period.

[0173] Example 11 may include the apparatus of example 9 or some other example herein, wherein the OCC period is a first OCC period, wherein the PUCCH includes PUCCH repetitions in the first OCC period and a second OCC period, and wherein the processing circuitry is to multiplex the UCI in all the PUSCH repetitions of the first OCC period.

[0174] Example 12 may include the apparatus of example 11 or some other example herein, wherein the PUSCH repetitions are first PUSCH repetitions, and wherein the processing circuitry is to output second PUSCH repetitions in the second OCC period without multiplexing the UCI in the second PUSCH repetitions.

[0175] Example 13 may include the apparatus of example 11 or some other example herein, wherein the PUSCH repetitions are first PUSCH repetitions, and wherein the processing circuitry is further to multiplex the UCI in second PUSCH repetitions for transmission in the second OCC period.

[0176] Example 14 may include the apparatus of example 11 or some other example herein, wherein the PUSCH repetitions are first PUSCH repetitions, wherein the second OCC period is before the first OCC period, and wherein the processing circuitry is to multiplex the UCI in all the PUSCH repetitions of the first OCC period based on an earliest second PUSCH repetition of the second OCC period being after a reference symbol, wherein the reference symbol is a processing time after a downlink control information (DCI) that schedules the PUCCH.

[0177] Example 15 may include the apparatus of example 9 or some other example herein, wherein the processing circuitry is to drop all the PUSCH repetitions in the OCC period or multiplex the UCI in all the PUSCH repetitions in the OCC period based further on a content of the UCI or a channel state information (CSI) reporting trigger that triggered reporting of the UCI.

[0178] Example 16 may include a method comprising: generating, for transmission to a user equipment (UE) , a physical uplink shared channel (PUSCH) configuration to configure a time domain resource allocation (TDRA) table, wherein individual entries of the TDRA table are associated with respective TDRA indexes and indicate an orthogonal cover code (OCC) length or an OCC sequence; generating, for transmission to the UE, a message to schedule an OCC-based PUSCH, wherein the message includes a first TDRA index to indicate the OCC length or the OCC sequence for the OCC-based PUSCH based on the TDRA table; and receiving the OCC-based PUSCH from the UE.

[0179] Example 17 may include the method of example 16 or some other example herein, wherein the TDRA index is to indicate the OCC length and the OCC sequence for the OCC-based PUSCH based on the TDRA table.

[0180] Example 18 may include the method of example 16 or some other example herein, wherein receiving the OCC-based PUSCH includes decoding the OCC-based PUSCH based on: transport block processing over multiple slots (TBoMS) applied to the PUSCH after OCC cycling is applied to the PUSCH; and redundancy version (RV) cycling applied to the PUSCH after the OCC cycling and the TBoMS are applied.

[0181] Example 19 may include the method of example 16 or some other example herein, further comprising receiving uplink control information (UCI) that is multiplexed in all PUSCH repetitions of an OCC period of the OCC-based PUSCH.

[0182] Example 20 may include the method of example 19 or some other example herein, wherein the UCI is multiplexed in all the PUSCH repetitions of the OCC period based on a content of the UCI or a channel state information (CSI) reporting trigger that triggered reporting of the UCI.

[0183] Another example may include an apparatus comprising means to perform one or more elements of a method described in or related to any of examples 1–20, or any other method or process described herein.

[0184] Another example may include one or more non-transitory computer-readable media comprising instructions to cause an electronic device, upon execution of the instructions by one or more processors of the electronic device, to perform one or more elements of a method described in or related to any of examples 1–20, or any other method or process described herein.

[0185] Another example may include an apparatus comprising logic, modules, or circuitry to perform one or more elements of a method described in or related to any of examples 1–20, or any other method or process described herein.

[0186] Another example may include a method, technique, or process as described in or related to any of examples 1–20, or portions or parts thereof.

[0187] Another example may include an apparatus comprising: one or more processors and one or more computer-readable media comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform the method, techniques, or process as described in or related to any of examples 1–20, or portions thereof.

[0188] Another example may include a signal as described in or related to any of examples 1–20, or portions or parts thereof.

[0189] Another example may include a datagram, information element, packet, frame, segment, PDU, or message as described in or related to any of examples 1–20, or portions or parts thereof, or otherwise described in the present disclosure.

[0190] Another example may include a signal encoded with data as described in or related to any of examples 1–20, or portions or parts thereof, or otherwise described in the present disclosure.

[0191] Another example may include a signal encoded with a datagram, IE, packet, frame, segment, PDU, or message as described in or related to any of examples 1–20, or portions or parts thereof, or otherwise described in the present disclosure.

[0192] Another example may include an electromagnetic signal carrying computer-readable instructions, wherein execution of the computer-readable instructions by one or more processors is to cause the one or more processors to perform the method, techniques, or process as described in or related to any of examples 1–20, or portions thereof.

[0193] Another example may include a computer program comprising instructions, wherein execution of the program by a processing element is to cause the processing element to carry out the method, techniques, or process as described in or related to any of examples 1–20, or portions thereof.

[0194] Another example may include a signal in a wireless network as shown and described herein.

[0195] Another example may include a method of communicating in a wireless network as shown and described herein.

[0196] Another example may include a system for providing wireless communication as shown and described herein.

[0197] Another example may include a device for providing wireless communication as shown and described herein.

[0198] Any of the above-described examples may be combined with any other example (or combination of examples) , unless explicitly stated otherwise. The foregoing description of one or more implementations provides illustration and description, but is not intended to be exhaustive or to limit the scope of embodiments to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of various embodiments.

[0199] Although the embodiments above have been described in considerable detail, numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications.

Claims

1.A method comprising:receiving a message to schedule a physical uplink shared channel (PUSCH) , wherein the message includes a time domain resource allocation (TDRA) index;determining, based on the TDRA index, an orthogonal cover code (OCC) length or an OCC sequence for the PUSCH; andgenerating the PUSCH for transmission with an OCC based on the OCC length or the OCC sequence.2.The method of claim 1, further comprising determining, based on the TDRA index, a repetition number that indicates a number of slots allocated for the PUSCH, wherein the repetition number includes application of OCC, wherein the OCC length is equal to or smaller than the repetition number and the repetition number is divisible by the OCC length.3.The method of claim 1, further comprising determining, based on the TDRA index, a repetition number for the PUSCH, wherein a number of slots allocated for the PUSCH is equal to the repetition number multiplied by the OCC length.4.The method of claim 1, wherein determining the OCC length or the OCC sequence includes determining an OCC sequence index based on the TDRA index and determining the OCC sequence based on the OCC sequence index.5.The method of claim 1, further comprising receiving a user equipment (UE) -specific PUSCH configuration to configure a TDRA table, wherein the TDRA index corresponds to an entry of the TDRA table that indicates the OCC length or the OCC sequence.6.The method of claim 1, wherein generating the PUSCH for transmission includes:applying OCC cycling to the PUSCH;applying transport block processing over multiple slots (TBoMS) to the PUSCH after applying the OCC cycling; andapplying redundancy version (RV) cycling to the PUSCH after applying the OCC cycling and the TBoMS.7.The method of claim 1, wherein generating the PUSCH for transmission includes:applying OCC cycling to the PUSCH;applying redundancy version (RV) cycling to the PUSCH after applying the OCC cycling; andapplying transport block processing over multiple slots (TBoMS) to the PUSCH after applying the OCC cycling and the RV cycling.8.The method of claim 1, wherein generating the PUSCH for transmission includes:applying transport block processing over multiple slots (TBoMS) to the PUSCH;applying OCC cycling to the PUSCH after applying the OCC cycling; andapplying redundancy version (RV) cycling to the PUSCH after applying the TBoMS and the OCC cycling.9.An apparatus comprising:processing circuitry to:identify that a physical uplink control channel (PUCCH) with uplink control information (UCI) overlaps with a physical uplink shared channel (PUSCH) to be transmitted with an orthogonal cover code (OCC) in an OCC period; andbased on the identification:drop all PUSCH repetitions in the OCC period and output the PUCCH for transmission; ormultiplex the UCI for transmission in all PUSCH repetitions in the OCC period; andinterface circuitry coupled to the processing circuitry to enable communication.10.The apparatus of claim 9, wherein the PUCCH is scheduled with a number of PUCCH repetitions that is less than a number of slots in the OCC period, wherein the processing circuitry is to drop all the PUSCH repetitions in the OCC period and output the PUCCH for transmission in all the slots in the OCC period.11.The apparatus of claim 9, wherein the OCC period is a first OCC period, wherein the PUCCH includes PUCCH repetitions in the first OCC period and a second OCC period, and wherein the processing circuitry is to multiplex the UCI in all the PUSCH repetitions of the first OCC period.12.The apparatus of claim 11, wherein the PUSCH repetitions are first PUSCH repetitions, and wherein the processing circuitry is to output second PUSCH repetitions in the second OCC period without multiplexing the UCI in the second PUSCH repetitions.13.The apparatus of claim 11, wherein the PUSCH repetitions are first PUSCH repetitions, and wherein the processing circuitry is further to multiplex the UCI in second PUSCH repetitions for transmission in the second OCC period.14.The apparatus of claim 11, wherein the PUSCH repetitions are first PUSCH repetitions, wherein the second OCC period is before the first OCC period, and wherein the processing circuitry is to multiplex the UCI in all the PUSCH repetitions of the first OCC period based on an earliest second PUSCH repetition of the second OCC period being after a reference symbol, wherein the reference symbol is a processing time after a downlink control information (DCI) that schedules the PUCCH.15.The apparatus of claim 9, wherein the processing circuitry is to drop all the PUSCH repetitions in the OCC period or multiplex the UCI in all the PUSCH repetitions in the OCC period based further on a content of the UCI or a channel state information (CSI) reporting trigger that triggered reporting of the UCI.16.A method comprising:generating, for transmission to a user equipment (UE) , a physical uplink shared channel (PUSCH) configuration to configure a time domain resource allocation (TDRA) table, wherein individual entries of the TDRA table are associated with respective TDRA indexes and indicate an orthogonal cover code (OCC) length or an OCC sequence;generating, for transmission to the UE, a message to schedule an OCC-based PUSCH, wherein the message includes a first TDRA index to indicate the OCC length or the OCC sequence for the OCC-based PUSCH based on the TDRA table; andreceiving the OCC-based PUSCH from the UE.17.The method of claim 16, wherein the TDRA index is to indicate the OCC length and the OCC sequence for the OCC-based PUSCH based on the TDRA table.18.The method of claim 16, wherein receiving the OCC-based PUSCH includes decoding the OCC-based PUSCH based on:transport block processing over multiple slots (TBoMS) applied to the PUSCH after OCC cycling is applied to the PUSCH; andredundancy version (RV) cycling applied to the PUSCH after the OCC cycling and the TBoMS are applied.19.The method of claim 16, further comprising receiving uplink control information (UCI) that is multiplexed in all PUSCH repetitions of an OCC period of the OCC-based PUSCH.20.The method of claim 19, wherein the UCI is multiplexed in all the PUSCH repetitions of the OCC period based on a content of the UCI or a channel state information (CSI) reporting trigger that triggered reporting of the UCI.

Images