Multiplexing physical uplink shared channel with orthogonal cover code for new radio non-terrestrial networks

Abstract

An apparatus configured to process configuration information for transmitting physical uplink shared channel (PUSCH) with a type of orthogonal cover code (OCC) in a terrestrial network (TN) or a non-terrestrial network (NTN), process scheduling information for a PUSCH transmission and generate, for transmission, PUSCH based on the scheduling information, wherein transmitting the PUSCH includes applying the type of OCC.

Description

Multiplexing Physical Uplink Shared Channel with Orthogonal Cover Code for New Radio Non-Terrestrial NetworksTechnical Field

[0001] The present disclosure generally relates to wireless communication, and in particular, to multiplexing physical uplink shared channel with orthogonal cover code for new radio non-terrestrial networks.Background

[0002] A user equipment (UE) may establish a connection to at least one of multiple different networks or types of networks, e.g., a public land mobile network (PLMN) operating a radio access network (RAN) . A non-terrestrial network (NTN) refers to a network utilizing non-terrestrial components, e.g., one or more satellites, to provide UE access to a PLMN. There is a need for uplink capacity and throughput enhancements for New Radio (NR) NTN and it has been identified that it may be beneficial to implement physical uplink shared channel (PUSCH) enhancements via orthogonal cover codes (OCC) for NR NTN.SUMMARY

[0003] Some example embodiments are related to an apparatus having processing circuitry configured to process configuration information for transmitting physical uplink shared channel (PUSCH) with a type of orthogonal cover code (OCC) in a terrestrial network (TN) or a non-terrestrial network (NTN) , process scheduling information for a PUSCH transmission and generate, for transmission, PUSCH based on the scheduling information, wherein transmitting the PUSCH includes applying the type of OCC.Brief Description of the Drawings

[0004] Fig. 1 shows an example network arrangement according to various example embodiments.

[0005] Fig. 2 shows an example user equipment (UE) according to various example embodiments.

[0006] Fig. 3 shows an example base station according to various example embodiments.

[0007] Fig. 4 shows an example non-terrestrial network (NTN) architecture according to various example embodiments.

[0008] Fig. 5 shows a method for multiplexing physical uplink shared channel (PUSCH) with orthogonal cover code (OCC) according to various example embodiments.

[0009] Fig. 6 shows examples for cross-symbol OCC demodulation reference signal (DMRS) handling according to various example embodiments.

[0010] Fig. 7 shows examples for cross-symbol OCC when the number of PUSCH symbols is not divisible by the OCC size according to various example embodiments.

[0011] Fig. 8 shows examples for cross-symbol OCC DMRS handling according to various example embodiments.

[0012] Fig. 9 shows examples for cross-symbol OCC when the number of PUSCH symbols over multiple slots is not divisible by the OCC size according to various example embodiments.

[0013] Fig. 10 shows examples of multi-slot PUSCH with cross-symbol OCC and redundancy version cycling according to various example embodiments.

[0014] Fig. 11 shows examples of intra-symbol resource element (RE) -based OCC according to various example embodiments.

[0015] Fig. 12 shows an example of intra-symbol OCC with multiple resource blocks (RBs) according to various example embodiments.

[0016] Fig. 13 shows an example of intra-symbol OCC with multiple RBs according to various example embodiments.

[0017] Fig. 14 shows an example of intra-symbol RB-based OCC according to various example embodiments.

[0018] Fig. 15 shows a method for PUSCH transmission with cross-slot OCC according to various example embodiments.

[0019] Fig. 16 shows a method for multiplexing PUSCH with OCC spreading according to various example embodiments.Detailed Description

[0020] The example embodiments may be further understood with reference to the following description and the related appended drawings, wherein like elements are provided with the same reference numerals. The example embodiments introduce physical uplink shared channel (PUSCH) enhancements via orthogonal cover code (OCC) for New Radio (NR) non-terrestrial network (NTN) .

[0021] The example embodiments are described with regard to a user equipment (UE) . However, reference to a UE is merely provided for illustrative purposes. The example embodiments may be utilized with any electronic component that may establish a connection to a network and is configured with the hardware, software, and / or firmware to exchange information and data with the network. Therefore, the UE as described herein is used to represent any appropriate electronic component.

[0022] The example embodiments are also described with regard to a 5G New Radio (NR) network. However, reference to a 5G NR network is merely provided for illustrative purposes. The example embodiments may be utilized with any network that may establish a connection to a UE and exchange information and data with the UE (e.g., 5G-Advanced networks, 6G networks, etc. ) .

[0023] The example embodiments are further described with regard to a 5G NR network integrated with a non-terrestrial-network (NTN) utilizing one or more satellites to provide UE access to the 5G NR radio access network (RAN) . A satellite-based NTN may be deployed by a public land mobile network (PLMN) and may be further integrated with a terrestrial network (TN) of the PLMN. Throughout this description, the non-terrestrial component is generally described as a satellite. However, any reference to a satellite is only for illustrative purposes and the example embodiments may apply to other types of non-terrestrial components, e.g., airplanes, unmanned aerial vehicles (UAVs) , etc.

[0024] For 5G NR NTN, it has been identified that there is a need for OCC based enhancements for PUSCH multiplexing. OCC generally refers to a technique for encoding transmitted data  that may be used to mitigate interference and improve system performance, e.g., the same frequency and / or time resources may be used by the different transmitting devices. The example embodiments are described with regard to a mechanism for multiplexing PUSCH with OCC. Example embodiments for cross-symbol OCC, intra-symbol OCC and cross-slot OCC will be described in more detail below. Each of the example embodiments may be used independently from one another, in combination with currently implemented mechanisms for multiplexing PUSCH with OCC, future implementations of mechanisms for multiplexing PUSCH with OCC or independently from other mechanisms for multiplexing PUSCH with OCC.

[0025] Fig. 1 shows an example network arrangement 100 according to various example embodiments. The example network arrangement 100 includes a UE 110. The UE 110 may be any type of electronic component that is configured to communicate via a network, e.g., mobile phones, tablet computers, desktop computers, smartphones, phablets, embedded devices, wearables, Internet of Things (IoT) devices, etc. the example of a single UE 110 is merely provided for illustrative purposes. An actual network arrangement may include any number of UEs being used by any number of users.

[0026] The UE 110 may be configured to communicate with one or more networks. In the example of the network arrangement 100, the network with which the UE 110 may wirelessly communicate is a 5G NR radio access network (RAN) 120. However, the UE 110 may also communicate with other types of networks (e.g., 5G cloud RAN, a next generation RAN (NG-RAN) , a long-term evolution (LTE) RAN, a legacy cellular network, a wireless local area network (WLAN) , etc. ) and the UE 110 may also communicate  with networks over a wired connection. With regard to the example embodiments, the UE 110 may establish a connection with the 5G NR RAN 120. Therefore, the UE 110 may have a 5G NR chipset to communicate with the NR RAN 120.

[0027] The 5G NR RAN 120 may be a portion of a public land mobile network (PLMN) that may be deployed by a network carrier (e.g., Verizon, AT&T, T-Mobile, etc. ) . The 5G NR RAN 120 may include, for example, nodes or base stations (Node Bs, eNodeBs, HeNBs, eNBS, gNBs, gNodeBs, macrocells, microcells, small cells, femtocells, etc. ) that are configured to send and receive traffic from UEs that are equipped with the appropriate cellular chip set.

[0028] In the network arrangement 100, the 5G NR RAN 120 includes a base station (e.g., gNB 120A) that may be in a terrestrial network (TN) deployment or a non-terrestrial network (NTN) deployment. For example, a satellite-based system may be integrated with the 5G NR RAN 120 to provide network access to the UE 110 in the NTN deployment and the base station may, in some cases, be located on a non-terrestrial component, e.g., a satellite. An example NTN network architecture will be described in greater detail below with reference to Fig. 4.

[0029] Returning to the network arrangement 100 of Fig. 1, the gNB 120A may include one or more communication interfaces to exchange data and / or information with the UE 110, the corresponding 5G NR RAN 120, the cellular core network 130, the internet 140, etc.

[0030] The UE 110 may connect to the 5G NR-RAN 120 via the gNB 120A. Any association procedure may be performed for the UE 110 to connect to the 5G NR-RAN 120. For example, as discussed  above, the 5G NR-RAN 120 may be associated with a particular cellular provider where the UE 110 and / or the user thereof has a contract and credential information (e.g., stored on a SIM card) . Upon detecting the presence of the 5G NR-RAN 120, the UE 110 may transmit the corresponding credential information to associate with the 5G NR-RAN 120. More specifically, the UE 110 may associate with a specific cell (e.g., the gNB 120A) . However, as mentioned above, reference to the 5G NR-RAN 120 is merely for illustrative purposes and any appropriate type of RAN may be used.

[0031] In addition to the 5G NR RAN 120, the network arrangement 100 also includes a cellular core network 130, the Internet 140, an IP Multimedia Subsystem (IMS) 150, and a network services backbone 160. The cellular core network 130 may be considered to be the interconnected set of components that manages the operation and traffic of the cellular network. The cellular core network 130 also manages the traffic that flows between the cellular network and the Internet 140.

[0032] The IMS 150 may be generally described as an architecture for delivering multimedia services to the UE 110 using the IP protocol. The IMS 150 may communicate with the cellular core network 130 and the Internet 140 to provide the multimedia services to the UE 110. The network services backbone 160 is in communication either directly or indirectly with the Internet 140 and the cellular core network 130. The network services backbone 160 may be generally described as a set of components (e.g., servers, network storage arrangements, etc. ) that implement a suite of services that may be used to extend the functionalities of the UE 110 in communication with the various networks.

[0033] Fig. 2 shows an example UE 110 according to various example embodiments. The UE 110 will be described with regard to the network arrangement 100 of Fig. 1. The UE 110 may include a processor 205, a memory arrangement 210, a display device 215, an input / output (I / O) device 220, a transceiver 225 and other components 230. The other components 230 may include, for example, an audio input device, an audio output device, a power supply, a data acquisition device, ports to electrically connect the UE 110 to other electronic devices, etc.

[0034] The processor 205 may be configured to execute a plurality of engines of the UE 110. For example, the engines may include a PUSCH Multiplexing engine 235. The PUSCH Multiplexing engine 235 may perform various operations related to PUSCH multiplexing including, but not limited to, cross-symbol OCC, intra-symbol OCC and cross-slot OCC.

[0035] The above referenced engine 235 being an application (e.g., a program) executed by the processor 205 is merely provided for illustrative purposes. The functionality associated with the engine 235 may also be represented as a separate incorporated component of the UE 110 or may be a modular component coupled to the UE 110, e.g., an integrated circuit with or without firmware. For example, the integrated circuit may include input circuitry to receive signals and processing circuitry to process the signals and other information. The engine 235 may also be embodied as one application or separate applications. In addition, in some UEs, the functionality described for the processor 205 is split among two or more processors such as a baseband processor and an applications  processor. The example embodiments may be implemented in any of these or other configurations of a UE.

[0036] The memory arrangement 210 may be a hardware component configured to store data related to operations performed by the UE 110. The display device 215 may be a hardware component configured to show data to a user while the I / O device 220 may be a hardware component that enables the user to enter inputs. The display device 215 and the I / O device 220 may be separate components or integrated together such as a touchscreen.

[0037] The transceiver 225 may be a hardware component configured to establish a connection with the 5G NR-RAN 120, an LTE-RAN (not pictured) , a legacy RAN (not pictured) , a WLAN (not pictured) , etc. Accordingly, the transceiver 225 may operate on a variety of different frequencies or channels (e.g., set of consecutive frequencies) . The transceiver 225 includes circuitry configured to transmit and / or receive signals (e.g., control signals, data signals) . Such signals may be encoded with information implementing any one of the methods described herein. The processor 205 may be operably coupled to the transceiver 225 and configured to receive from and / or transmit signals to the transceiver 225. The processor 205 may be configured to encode and / or decode signals (e.g., signaling from a base station of a network) for implementing any one of the methods described herein.

[0038] Fig. 3 shows an example base station 300 according to various example embodiments. The base station 300 may represent the gNB 120A or any other type of access node through which the UE 110 may establish a connection and manage network operations.

[0039] The base station 300 may include a processor 305, a memory arrangement 310, an input / output (I / O) device 315, a transceiver 320, and other components 325. The other components 325 may include, for example, an audio input device, an audio output device, a battery, a data acquisition device, ports to electrically connect the base station 300 to other electronic devices and / or power sources, antenna elements, antenna panels, etc.

[0040] The processor 305 may be configured to execute a plurality of engines for the base station 300. For example, the engines may include a PUSCH multiplexing engine 330. The PUSCH multiplexing engine 330 may perform various operations related to configuring PUSCH multiplexing for NR NTN.

[0041] The above noted engine 330 being an application (e.g., a program) executed by the processor 305 is only an example. The functionality associated with the engine 330 may also be represented as a separate incorporated component of the base station 300 or may be a modular component coupled to the base station 300, e.g., an integrated circuit with or without firmware. For example, the integrated circuit may include input circuitry to receive signals and processing circuitry to process the signals and other information. In addition, in some base stations, the functionality described for the processor 305 is split among a plurality of processors (e.g., a baseband processor, an applications processor, etc. ) . The example embodiments may be implemented in any of these or other configurations of a base station.

[0042] The memory arrangement 310 may be a hardware component configured to store data related to operations performed by the base station 300. The I / O device 315 may be a hardware component or ports that enable a user to interact with the base station 300.

[0043] The transceiver 320 may be a hardware component configured to exchange data with the UE 110 and any other UEs in the network arrangement 100. The transceiver 320 may operate on a variety of different frequencies or channels (e.g., set of consecutive frequencies) . Therefore, the transceiver 320 may include one or more components to enable the data exchange with the various networks and UEs. The transceiver 320 includes circuitry configured to transmit and / or receive signals (e.g., control signals, data signals) . Such signals may be encoded with information implementing any one of the methods described herein. The processor 305 may be operably coupled to the transceiver 320 and configured to receive from and / or transmit signals to the transceiver 320. The processor 305 may be configured to encode and / or decode signals (e.g., signaling from a UE) for implementing any one of the methods described herein.

[0044] Fig. 4 shows an example non-terrestrial network (NTN) architecture 400 according to various example embodiments. An NTN may relate to any network using non-terrestrial components, such as satellites, airplanes, unmanned aerial vehicles (UAVs) , etc., to provide network services to a user terminal.

[0045] The NTN architecture 400 represents a network arrangement including one or more satellites, which in this example shows two satellite 410 and 420 that are integrated with a radio access network (RAN) 440. The RAN 440 may be, for  example, the 5G NR RAN 120 described above with respect to Fig. 1. The NTN architecture 400 includes a gateway 430 connecting the RAN 440 with the NTN components. In the NTN architecture 400 of Fig. 4, the gateway 430 and the satellites 410 and 420 communicate via feeder links 412, 422. In some NTN deployments, satellites may be served by several gateways simultaneously.

[0046] The satellites 410 and 420 provide network services to a UE 110 via a service link (not shown) . The satellites 410 and RAN 420 may implement either a transparent payload or a regenerative payload. A transparent payload refers to an arrangement where the satellites 410 and 420 receive signals and transmit an amplified version of the signal, with a frequency conversion. For example, the satellite 410 may receive uplink communications from the UE 110 on service link frequencies and transmit an amplified version of the signal to the gateway 430 on feeder link frequencies or may receive downlink communications via the gateway 430 on feeder link frequencies and transmit an amplified version of the signal to the UE 110 on service link frequencies. A regenerative payload refers to an arrangement where the satellites 410 and 420 act as a distributed unit (DU) or a base station (e.g., a gNB) , wherein received signals are regenerated with signal-processing techniques (e.g., demodulation, decoding, switching, encoding, modulation, etc. ) before being re-transmitted.

[0047] The example NTN architecture 400 shown in Fig. 4 is not intended to limit the example embodiments in any way. NTNs may be integrated with the 5G NR RAN and / or other networks in any one of a variety of manners. For example, a typical satellite-based NTN may comprise a low earth orbit (LEO) constellation including an array of satellites and gateways with  broad interconnectivity via ground-to-ground station (G2G) links, satellite-to-satellite (S2 S) links, ground-to-satellite (G2S) links, and satellite-to-ground (S2G) links. Other types of satellite-based NTNs include geostationary-orbiting (GEO) satellites or medium-earth-orbiting (MEO) satellites.

[0048] The different types of NTNs each have respective strengths and weaknesses and may be deployed in a variety of scenarios, depending on the goal to be achieved, e.g., broad coverage across a large region, concentrated coverage in an urban environment or along a highly trafficked route, etc. Thus, the NTN architecture 400 described in Fig. 4 is merely provided for illustrative purposes.

[0049] Fig. 5 shows a method 500 for multiplexing PUSCH with OCC according to various example embodiments. The method 500 is described from the perspective of the UE 110 and provides a general overview of how the UE 110 may multiplex PUSCH. Specific example embodiments for cross-symbol OCC, intra-symbol OCC and cross-slot OCC will be described in detail below after the method 500.

[0050] In 505, the UE 110 receives configuration information for multiplexing PUSCH with OCC. The configuration information may be preconfigured at the UE 110 and / or provided to the UE 110 in system information, radio resource control (RRC) messages, control information or in any other appropriate manner.

[0051] In 510, a PUSCH transmission is scheduled to be performed by the UE 110. In some examples, the PUSCH transmission may be scheduled by downlink control information (DCI) . In other examples, the PUSCH transmission may be  scheduled by a configured grant. The configured grant may be provided to the UE 110 via RRC or in any other appropriate manner. The above examples are merely provided for illustrative purposes, the example embodiments may apply to a PUSCH transmission scheduled in any appropriate manner.

[0052] In 515, the UE 110 performs the PUSCH transmission with OCC. As mentioned above, OCC refers to a coding technique that is used to mitigate interference and improve system performance. For example, the UE 110 may be assigned a code sequence (e.g., [1, 1] , [1, -1] , etc. ) and when the UE 110 transmits the PUSCH using the assigned code sequence, the network decodes the signals using the code sequence assigned to the UE 110. The orthogonality of the code ensures that interference from other signals is minimized which allows for simultaneous transmission by multiple users. OCC may also mitigate the negative effects of multipath fading. Accordingly, it may be beneficial to implement OCC based PUSCH enhancements to improve NR NTN performance.

[0053] The example embodiments are also described with regard to a 5G NR resource grid. However, reference to a 5G NR resource grid is merely provided for illustrative purposes. The example embodiments may be utilized with any network and any appropriate corresponding resource grid structure.

[0054] A 5G NR frame may have a 10 millisecond (ms) duration and may include 10 subframes that are each 1 ms. Each subframe may be further divided into one or more slots and the number of slots may vary based on the configured subcarrier spacing (SCS) . Thus, the duration of the frame and subframes are fixed but the number of slots may vary. To provide an example, a 15 kilohertz  (kHz) subcarrier spacing (SCS) may have 1 slot per subframe with up to 14 orthogonal frequency division multiplexing (OFDM) symbols within each slot. In another example, a 30 kHz SCS may have 2 slots per subframe with up to 14 OFDM symbols within each slot. In a further example, a 60 kHz SCS may have 4 slots per subframe with up to 14 symbols in each slot. The above examples are not intended to limit the example embodiments in any way and are merely provided to illustrate the relationship between frames, subframes, slots and symbols.

[0055] The frequency domain may be divided into subcarriers. In 5G NR, 12 consecutive subcarriers may be referred to as a resource block (RB) . The smallest unit of the resource grid may be referred to as a resource element (RE) which is made up of one subcarrier in the frequency domain and one symbol in the time domain. The above examples are not intended to limit the example embodiments in any way and are merely provided to illustrate the relationship between subcarriers, RBs, and REs.

[0056] The example embodiments introduce enhancements to support PUSCH multiplexing for NR NTN. The embodiments include mechanisms for cross-symbol OCC, intra-symbol OCC and cross-slot OCC. Each of these example embodiments will be described in more detail below.

[0057] In one aspect, the example embodiments introduce enhancements to support PUSCH multiplexing with cross-symbol OCC for NR NTN. In some examples, cross-symbol OCC may be used with single slot PUSCH. For single slot PUSCH with cross-symbol OCC, each PUSCH symbol may be OCC spread across (X) symbols where (X) is the OCC size.

[0058] The example embodiments include techniques for demodulation reference signal (DMRS) symbol handling for single slot PUSCH scheduling with cross-symbol OCC. Fig. 6 shows examples 610-640 for cross-symbol OCC DMRS handling according to various example embodiments. Examples 610-640 are described with regard to OCC code sequence [1, -1] . However, reference to [1, -1] is merely provided for illustrative purposes. The example embodiments may be used with any appropriate type of OCC code sequence.

[0059] Example 610 shows a slot 612 comprising 14 symbols where 2 of the 14 symbols are DMRS symbols. In this example, there is no OCC spreading on the DMRS symbols. Therefore, neither DMRS symbols S2 or S 7 are spread over the time domain using the OCC code sequence [1, -1] while the other symbols S1, S3, 4, S5, S6 and S8 are spread over the time domain using the OCC code sequence [1, -1] . In some example embodiments, the PUSCH DMRS symbols may not carry data REs. In these examples, some REs on the PUSCH DMRS symbols may be DMRS REs, while the other REs on the PUSCH DMRS symbols may be empty.

[0060] Example 620 shows a slot 622 comprising 14 symbols where 2 of the 14 symbols are DMRS symbols. In this example, there is OCC spreading to the next DMRS symbol in the slot. Therefore, DMRS symbol S2 is spread to the next DMRS symbol using the OCC code sequence [1, -1] which is shown in example 620 as -S2. The other symbols S1, S3, S4, S5, S6 and S7 are also spread over the time domain using the OCC code sequence [1, -1] .

[0061] Example 630 shows a slot 632 comprising 14 symbols where 3 of the 14 symbols are DMRS symbols. In this example, there is OCC spreading to the next DMRS symbol in the slot.  Therefore, DMRS symbol S2 is spread to the next DMRS symbols using the OCC code sequence [1, -1] which is shown in example 630 as -S2. The other DMRS symbol S7 is not OCC spread to the next DMRS symbol because there is not a subsequent DMRS symbol in this slot.

[0062] Example 640 shows a slot 642 comprising 14 symbols were 4 of the 14 symbols are DMRS symbols. In this example, DMRS symbol location spreads to the next OFDM symbols but uses a DMRS pattern with 2 pairs of consecutive DMRS symbols. Therefore, DMRS symbol S2 is spread to the next DMRS symbols using the OCC code sequence [1, -1] which is shown in example 640 as –S2 and DMRS symbol S7 is spread to the next DMRS symbol using the OCC code sequence [1, -1] which is shown in example 640 as -S7.

[0063] A scenario may occur where the number of PUSCH symbols is not divisible by the OCC size for single slot PUSCH with cross-symbol OCC. Fig. 7 shows examples 710-720 for cross-symbol OCC when the number of PUSCH symbols is not divisible by the OCC size according to various example embodiments. Examples 710-720 are described with regard to OCC code sequence [1, -1] . However, reference to [1, -1] is merely provided for illustrative purposes. The example embodiments may be used with any appropriate type of OCC code sequence.

[0064] Example 710 shows a slot 712 comprising 13 symbols where 2 of the 13 symbols are DMRS symbols. In this example, there is OCC spreading to the next DMRS symbol in the slot. Therefore, DMRS symbol S2 is spread to the next DMRS symbol using the OCC code sequence [1, -1] which is shown in example 710 as –S2. In one embodiment, the remaining 13th symbol may be used to carry a copy of a previously used symbol. To illustrate  this technique example 710 shows 2 instances of S6 instead of the next symbol S7. However, carrying 2 copies of S6 is merely provided for illustrative purposes and any of the other non-DMRS symbols (S1, S3, S4, S5) may be repeated in the remaining symbol.

[0065] Example 720 shows a slot 722 comprising 13 symbols where 2 of the 13 symbols are DMRS symbols. In this example, there is OCC spreading to the next DMRS symbol in the slot. Therefore, DMRS symbol S2 is spread to the next DMRS symbols using the OCC code sequence [1, -1] which is shown in example 720 as –S2. In another embodiment, the remaining 13th symbol may be used to carry a new symbol. To illustrate this technique example 720 shows 1 instances of S 7 and since this is the last available symbol, S7 is not OCC spread within the slot 722.

[0066] The example embodiments also introduce techniques for determining a transport block (TB) size for single slot PUSCH with cross-symbol OCC. The UE 110 may determine the number of resource elements (REs) allocated for PUSCH within a physical resource block (PRB) based on the equation:  where represents a number of subcarriers in a resource block,  represents a number of symbols for PUSCH transmissions before spreading,  represents a number of REs for DMRS per PRB in the allocated duration and represents the overhead configured by a parameter provided via higher layer signaling. The parameter may be provided in PUSCH-ServingCellConfig or in any other appropriate manner.

[0067] may depend on L which represents the total number of PUSCH symbol allocation, Osize which represents the OCC size  which may be indicated in DCI or in configured grant configuration information and which represents a number of DMRS symbols in the PUSCH. In some examples,  The ceiling function or floor funct ion may be used but is not required. In other examples,  The ceiling function or floor function may be used but is not required.

[0068] In addition, the UE 110 may determine the total number of REs allocated for PUSCH based on the equation: NRE=min (156 / Osize, N′RE) ·nPRB

[0069] Cross-symbol OCC may also be used for multi-slot PUSCH. In some examples, a single TB may be scheduled over multiple slots. For instance, PUSCH time domain resource allocation (TDRA) may be configured with a number of slots for transport block on multiple slots (TBoMS) parameter “numberOfSlotsTBoMS” set to greater than 1. However, reference to numberOfSlotsTBoMS is provide for illustrative purposes, the example embodiments may apply to multi-slot PUSCH scheduled in any appropriate manner.

[0070] The example embodiments introduce techniques for DMRS symbol handling for multi-slot PUSCH scheduling with cross-symbol OCC. Fig. 8 shows examples 810-820 for cross-symbol OCC DMRS handling according to various example embodiments. Examples 810-820 are described with regard to OCC code sequence [1, -1] . However, reference to [1, -1] is merely provided for illustrative purposes. The example embodiments may be used with any appropriate type of OCC code sequence.

[0071] Examples 810-820 show OCC on PUSCH DMRS symbols where PUSCH DMRS time locations remain unchanged. Example 810 shows consecutive slots 812-814 each comprising 14 symbols where 2 of the 14 symbols are DMRS symbols. In this example, DMRS symbols may be OCC spread to the next PUSCH DMRS symbol location in the same slot. Therefore, DMRS symbol S2 is spread to the next DMRS symbol in slot 812 using the OCC code sequence [1, -1] which is shown in example 810 as -S2 and DMRS symbol S 9 is spread to the next DMRS symbol in slot 814 using the OCC code sequence [1, -1] which is shown in example 810 as -S9.

[0072] Example 820 shows consecutive slots 822-824 each comprising 14 symbols where 2 of the 14 symbols are DMRS symbols. In this example, DMRS symbols may be OCC spread across slots. Therefore, the DMRS symbol in slot 822 is spread with 1 and the DMRS symbol in slot 824 is spread with -1. For instance, in example 820, symbol S2 in slot 822 is spread to the next slot 824 which is shown in example 820 as -S2 in slot 824 and DMRS symbol S 7 is spread to the next slot 824 which is shown in example 820 as -S7 in slot 824. The network may configure this mechanism using RRC, dynamic indication via DCI or in any other appropriate manner.

[0073] The example embodiments introduce techniques for handling a scenario in which the number of PUSCH symbols is not divisible by the OCC size for multi-slot PUSCH with cross-symbol OCC. Fig. 9 shows examples 910-920 for cross-symbol OCC when the number of PUSCH symbols over multiple slots is not divisible by the OCC size. Examples 910-920 are described with regard to OCC code sequence [1, -1] . However, reference to [1, -1] is merely provided for illustrative purposes. The example embodiments may be used with any appropriate type of OCC code sequence.

[0074] Example 910 shows slot 912 comprising 14 symbols where 2 of the 14 symbols are DMRS symbols and slot 914 comprising 13 symbols where 2 of the 13 symbols are DMRS symbols. In this example, the DMRS is handled in the same manner as example 810. Therefore, DMRS symbol S2 is spread to the next DMRS symbol in slot 912 which is shown in example 910 as –S2 and DMRS symbol S9 is spread to the next DMRS symbol in slot 914 which is shown in example 910 as -S9. In this example, the remaining symbol may be used to carry a copy of a previously used symbol. Therefore, in this example there are two instances of S13 and no instance of S14. However, carrying two copies of S13 is merely provided for illustrative purposes and any of the other non-DMRS symbols in slots 912-914 may be repeated.

[0075] Example 920 shows slot 922 comprising 14 symbols where 2 of the 14 symbols are DMRS symbols and slot 924 comprising 13 symbols where 2 of the 13 symbols are DMRS symbols. In this example, the DMRS is handled in the same manner as examples 810, 910. Therefore, DMRS symbol S2 is spread to the next DMRS symbol in slot 922 which is shown in example 920 as –S2 and DMRS symbol S9 is spread to the next DMRS symbol in slot 924 which is shown in example 920 as -S9. In this example, the remaining symbol may be used to carry a new symbol. Therefore, in this example symbol S14 is included in the last symbol and there is no instance of -S14.

[0076] Multi-slot PUSCH scheduling for cross-symbol OCC may be used with TB repetition over multiple slots. For instance, PUSCH TDRA may be configured with a number of repetitions parameter “numberofRepetitions” set to greater than 1 for PUSCH repetition type A or type B or configured with a parameter  “numberofRepetitionsExt” set to greater than 1. However, reference to numberofRepetitions and numberofRepetitionsExt is provided for illustrative purposes, the example embodiments may apply to multi-slot PUSCH with TB repetition scheduled in any appropriate manner.

[0077] For multi-slot PUSCH with TB repetition over multiple slots, when cross-symbol OCC is applied, redundancy version (RV) cycling may be used. RV may be used to determine which bits are selected for transmission and different RVs will result in different bits being transmitted. RVs may be differentiated from one another by an RV ID (e.g., 0, 1, 2, 3, etc. ) .

[0078] Fig. 10 shows examples 1010-1040 of multi-slot PUSCH with cross-symbol OCC and redundancy version cycling according to various example embodiments.

[0079] In some examples, redundancy version cycling is applied over different slots. In one approach, a same OCC sequence is applied over multiple slots. Example 1010 shows a slot 1012 comprising 14 symbols where 2 of the 14 symbols are DMRS symbols. The OCC sequence code for slot 1012 is [1, -1] and RV 0 is applied to [S1, …, S7] . Slot 1014 comprises 14 symbols where 2 of the 14 symbols are DMRS symbols. The OCC sequence code for slot 1014 is [1, -1] and RV 2 is applied to [S1’, …, S7’] .

[0080] In another approach, different OCC sequences are applied over multiple slots. For example, the UE 110 may be configured with an ordered list of OCC sequences (e.g., [1, 1] , [1, -1] , etc. ) where a first OCC code (e.g., [1, 1] may be used  for a first slot and a second OCC code (e.g., [1, -1] may be used for a second slot.

[0081] In some examples, redundancy version cycling may stop over different slots with the OCC size as indicated. In one approach, the same OCC sequence may be applied over multiple slots.

[0082] In another approach, different OCC sequences may be applied over multiple slots. For example, the UE 110 may be configured with an ordered list of OCC sequences (e.g., [1, 1] , [1, -1] , etc. ) where s first OCC code (e.g., [1, 1] may be used for a first slot and a second OCC code (e.g., [1, -1] may be used for a second slot. Example 1020 shows a slot 1022 comprising 14 symbols where 2 of the 14 symbols are DMRS symbols. The OCC sequence code for slot 1022 is [1, 1] and RV 0 is applied to [S1, …, S7] . Slot 1024 comprises 14 symbols where 2 of the 14 symbols are DMRS symbols. The OCC sequence code for slot 1024 is [1, -1] and RV 0 is applied to [S1, …, S7] .

[0083] In some embodiments, RV cycling stops over different slots with a larger OCC size. With this approach, a new OCC size may be based on the indicated OCC size multiplied by the number of repetitions. For example, the UE 110 may receive the OCC size indication and indication of a repetition type (e.g., PUSCH repetition type A, etc. ) . The UE 110 may determine the new OCC based on these parameters. Example 1030 shows a slot 1032 comprising 14 symbols where 2 of the 14 symbols are DMRS symbols. The OCC sequence code for slot 1032 is [1, -1, 1, -1] and RV 0 is applied to [S1, …, S7] . Slot 1034 comprises 14 symbols where 2 of the 14 symbols are DMRS symbols. The OCC sequence  code for slot 1034 is [1, -1, 1, -1] and RV 0 is applied to [S1, …, S7] .

[0084] In some embodiments, redundancy version cycling applies over different slots and the total number of repetitions is equal to numberOfRepetitons times OCC size. Example 1040 shows a slot 1042 comprising 14 symbols where 2 of the 14 symbols are DMRS symbols and a slot 1044 comprising 14 symbols where 2 of the 14 symbols are DMRS symbols. The OCC sequence code for slots 1042-1044 is [1, -1] and RV 0 is applied to [S1, …, S14] . Slot 1046 also comprises 14 symbols where 2 of the 14 symbols are DMRS symbols and slot 1048 comprises 14 symbols where 2 of the 14 symbols are DMRS symbols. The OCC sequence code for slots 1046-1048 is [1, -1] and RV 2 is applied to [S1’, …, S14’] .

[0085] Multi-slot PUSCH scheduling with cross-symbol OCC may be used for multiple PUSCH TB transmissions. In some examples, a same OCC sequences may be applied over multiple PUSCH. In other examples, a different OCC sequence may be applied over multiple PUSCH. For example, the UE 110 may be configured with an ordered list of OCC sequences (e.g., [1, 1] , [1, -1] , etc. ) where s first OCC code (e.g., [1, 1] may be used for a first TB and a second OCC code (e.g., [1, -1] may be used for a second TB.

[0086] In one aspect, the example embodiments introduce enhancements to support PUSCH multiplexing with intra-symbol OCC for NR NTN. As will be described in more detail below the example embodiments include a RE-based OCC approach and an RB-based OCC approach.

[0087] Fig. 11 shows examples 1110-1140 of intra-symbol RE-based OCC according to various example embodiments. Example 1110 shows a RB 1112 on a symbol without DMRS and includes the RB 1112 comprising 12 subcarriers 1114 with symbols [S1, …, S6] OCC spread within the RB 1112 using OCC sequence [1, -1] . However, reference to [1, -1] is merely provided for illustrative purposes. The example embodiments may be used with any appropriate type of OCC code sequence.

[0088] Example 1120 shows a RB 1122 on a symbol with type 1 DMRS and includes the RB 1122 comprising 12 subcarriers 1124 with symbols [S1, …, S3] OCC spread within the RB 1122 using OCC sequence [1, -1] . In this example, the DRMS symbols 1126 are not subject to OCC spreading. The example embodiments are not limited to OCC sequence [1, -1] may be used with any appropriate type of OCC code sequence.

[0089] Example 1130 shows a RB 1132 on a symbol with type 2 DMRS and includes the RB 1132 comprising 12 subcarriers 1134 with symbols [S1, …, S4] OCC spread within the RB 1132 using OCC sequence [1, -1] . In this example, the DRMS symbols 1136 are not subject to OCC spreading. The example embodiments are not limited to OCC sequence [1, -1] may be used with any appropriate type of OCC code sequence.

[0090] Example 1140 relates to length 5 OCC which may be represented as

[0091] Example 1140 shows a RB 1142 on a symbol comprising 12 subcarriers 1144 with symbols [S1, …, S3] OCC spread within the RB 1142 using the length 5 OCC. Each RE within the RB 1142 may be  multiplied by an OCC value. This is shown in the example 1140 where S1 is multiplied by OCC value 1 (O1) to OCC value 5 (O5) of the length 5 OCC and S2 also is multiplied by O1 to O5. Since there are only two remaining REs, S3 is multiplied by O1 and O2 of the length 5 OCC.

[0092] In some embodiments, to determine the TB size, the UE 110 may perform a 2-step calculation. First, the UE 110 may determine the number of REs allocated for PUSCH within a PRB using the following equation:

[0093] may represent the number of symbols for PUSCH transmission which may depend on the total number of PUSCH symbol allocation (e.g., TDRA) .  may represent the number of REs for DMRS per PRB in the allocated duration.  may represent the overhead configured by higher layer parameter “xoverhead” in PUSCH-ServingCellConfig information element (IE) .

[0094] may represent the number of sub-carrier per RB before spreading (e.g., 12) . Since OCC spreading may decrease the number of symbols, the parameter may be configured to consider the OCC size Osize. In one example,  In another example,  and if Osize is not divisible by 12, then the remaining REs may be filled with new modulation symbols. In another example,  and if Osize is not divisible by 12, then the remaining REs may be filled with copies of modulation symbols already included in the RB.

[0095] In the second step, the UE 110 may determine the total number of REs allocated for PUSCH using the following equation:  where nPRB represents the number of RBs on a symbol for PUSCH.

[0096] Fig. 12 shows an example 1210 of intra-symbol OCC with multiple RBs according to various example embodiments. For this example, consider a scenario where 12 is not divisible by the OCC size and the number of RBs for PUSCH on a same symbol is greater than 1. When using the 2-step TB size determination described above, the modulation symbol will not be across RBs.

[0097] Example 1210 includes RB 1212 and RB 1214 on a same symbol. As mentioned above, when using the 2-step TB size determination described above, the modulation symbol will not be across RBs. Therefore, even though there are only 2 instances of S3 at the end of RB 1212, RB 1214 starts with S4 and does not continue with S3 because the modulation symbol will not be across RBs.

[0098] In other examples, to determine the TB size, the UE 110 may determine the total number of REs allocated for PUSCH using the following equation:

[0099] may represent the number of symbols for PUSCH transmission which may depend on the total number of PUSCH symbol allocation (e.g., TDRA) .  may represent the number of REs for DMRS per PRB in the allocated duration.  may represent the overhead configured by a higher layer parameter “xoverhead” in a PUSCH-ServingCellConfig IE.

[0100] may represent the number of subcarriers per PUSCH before spreading. In one example,  In another example,  and if Osize is not divisible by 12*nPRB, then the remaining REs may be filled with new modulation symbol. In another example,  and if Osize is not divisible by 12*nPRB, then the remaining REs may be filled with copies of previously used modulation symbols.

[0101] Fig. 13 shows an example 1310 of intra-symbol OCC with multiple RBs according to various example embodiments. For this example, consider a scenario where 12 is not divisible by the OCC size and the number of RBs for PUSCH on a same symbol is greater than 1.

[0102] Example 1310 includes RB 1312 and RB 1314 on a same symbol. When using the 1-step TB size determination described above, the modulation symbol may be across RBs. This is shown in Fig. 13 where S3 starts in RB 1312 and continues on RB 1314.

[0103] For RB-based OCC, every (X) consecutive RBs in a PUSCH frequency resource consists of an OCC group. Each RB in the group is multiplied by a single OCC value.

[0104] Fig. 14 shows an example 1410 of intra-symbol RB-based OCC according to various example embodiments. The example 1410 shows RBs 1412, 1414 on a same symbol without DMRS. RB 1412 comprises symbols [S1, …, S12] which are OCC spread to RB 1414.

[0105] For TB size determination, the UE 110 may determine the number of REs allocated for PUSCH within a RB based on the following equation:

[0106] In one example, the UE 110 may determine the total number of REs allocated for PUSCH based on NRE=min (156, N′RE) * (nPRB / Osize) . In another example, the UE 110 may determine the total number of REs allocated for PUSCH based on In another example, the UE 110 may determine the total number of REs allocated for PUSCH based on

[0107] The network may use DCI to indicate which patter is to be used within intra-symbol OCC. In another example, the configuration may indicate which pattern is used within intra-symbol OCC.

[0108] In one aspect, the example embodiments introduce enhancements to support PUSCH multiplexing with cross-slot OCC for NR NTN. As will be descried in more detail below, various PUSCH scheduling may be used with cross-slot OCC.

[0109] In one example, a single TB over 1 slot may be used with cross-slot OCC. For instance, PUSCH TDRA may be configured with the parameter numberOfSlotsTBoMS set to 1 and the parameter numberofRepetitions set to 1. The PUSCH transmission may use (X) slots for transmission where X is the OCC size. PUSCH on each slot may be based on the same slot of legacy PUSCH transmission multiplied by the corresponding OCC value in the OCC sequence.

[0110] In another example, a single TB over multiple slots may be used with cross-slot OCC. For instance, PUSCH TDRA may be configured with the parameter numberOfSlotsTBoMS set to greater than 1. For OCC spreading, a total of M*X slots may be  allocated for PUSCH transmissions where M = numberOfSlotsTBoMS and (X) is the OCC size. It may be assumed that [A1, ... AM] are the original TBoMS slots and [O1, ..., OX] are the OCC sequence.

[0111] In one approach, PUSCH transmission over M*X slots may use OCC spreading first and TBoMS second, e.g., [A1*O1, A1*O2, ..., A1*Ox, A2*O1, ..., A2*Ox, ..., AM*O1, ..., AM*Ox]

[0112] In one approach, PUSCH transmission over M*X slots may use TBoMS first and OCC spreading section, e.g., [A1*O1, A2*O1, ..., AM*O1, A1*O2, ..., AM*O2, ..., A1*Ox, ..., AM*Ox]

[0113] In another example, single TB repetition may be used with cross-slot OCC. For instance, PUSCH TDRA may be configured with the parameter numberofRepetitions set to greater than 1 (e.g., PUSCH repetition type A or type B) or the parameter numberOfRepetitionsExt set to greater than 1. For OCC spreading, a total of M*X slots may be allocated for PUSCH transmissions where M = number of repetitions and (X) is the OCC size. [A1, ..., AM] may represent the PUSCH repetition and [O1, ... OX] may represent the OCC sequence.

[0114] In one approach, the PUSCH transmissions over M*X slots may use OCC spreading first and PUSCH repetition RV second, e.g., [A1*O1, A1*O2, ..., A1*Ox, A2*O1, ..., A2*Ox, ..., AM*O1, ..., AM*Ox]

[0115] In another approach, the PUSCH transmissions over M*X slots may use PUSCH repetition RV first and OCC spreading second, e.g., [A1*O1, A2*O1, ..., AM*O1, A1*O2, ..., AM*O2, ..., A1*Ox, ..., AM*Ox]

[0116] In other embodiments, a total of M slots may be allocated for PUSCH transmission where M is the number of repetitions. [A1, ..., AM] may represent the PUSCH repeititon and {O1, ... OX] may represent the OCC sequence. PUSCH transmissions over M slots are RV cycling with OCC where only RV version is transmitted.

[0117] In one approach, the PUSCH transmissions over M*X slots may use OCC spreading first and PUSCH repetition RV second, e.g.,

[0118] In another approach, the PUSCH transmissions over M*X slots may use PUSCH repetition RV first and OCC spreading second, e.g.,

[0119] Cross-slot OCC may minimize the impact on the transmission on each slot. However, it may be difficult to perform channel estimation because the combining is over consecutive slots. It has been identified that DMRS bundling (e.g., joint channel estimation over multiple slots) may address this issue.

[0120] In some examples, cross-slot OCC may be used when DMRS bundling is applied. Fig. 15 shows a method 1500 for PUSCH transmission with cross-slot OCC according to various example embodiments. The method 1500 is described from the perspective of the UE 110.

[0121] In 1510, the UE 110 reports DMRS bundling capability information to the network. In 1520, the UE 110 receives PUSCH scheduling information for PUSCH with cross-slot OCC. The network may schedule this type of transmission for the UE 110 based on the capability information provided in 1510. In some examples, the OCC size may depend on the UE 110 reported DMRS bundling size. However, the network may configure a DMRS bundling size that is less than the OCC size, equal to the OCC size or greater than the OCC size. In 1530, the UE 110 applies the cross-slot OCC and DMRS bundling to the scheduled PUSCH transmission.

[0122] The UE 110 may also use PUSCH DMRS scrambling for cross-slot OCC. For discrete Fourier transform (DFT) -spread (s) -OFDM, PUSCH scrambling sequence initiation value may be based on the following equation:

[0123] In the above equation,  may represent the slot number with a frame and l may represent the OFDM symbol index within the slot. For different slots, the used PUSCH DMRS sequence is different.

[0124] To support cross-slot OCC, the initiation value of PUSCH DMRS sequence for all the slots with PUSCH uses a common  (e.g., set to be the in the first slot carrying PUSCH with OCC) . The same schemed may be applicable to message A (MsgA) PUSCH, message 3 (Msg3) PUSCH, dynamic grant PUSCH and configured grant PUSCH.

[0125] According to some aspects, the example embodiments introduce signaling techniques for the example OCC schemes described above. Fig. 16 shows a method 1600 for performing PUSCH transmission with OCC spreading according to various example embodiments.

[0126] In 1610, the UE 110 receives OCC configuration information for multiplexing PUSCH. This information may be provided via RRC or in any other appropriate manner. For example, the network may indicate which OCC scheme is to be used, e.g., cross-symbol OCC, cross-symbol OCC with OCC spread on PUSCH DMRS symbols cross slot, cross-symbol OCC with OCC spread on PUSCH DMRS symbols across slots, cross-symbol OCC with OCC spread on PUSCH DMRS symbols that does not cross slots, cross slot intra-symbol OCC, RE-based intra-symbol OCC where modulation symbols across RBs, RE-based intra-symbol OCC where modulation symbols do not cross RBs, RB-based intra-symbol OCC, cross-slot OCC, etc.

[0127] In 1620, the UE 110 may receive an indication of which OCC configuration is to be used for a particular PUSCH transmission. For example, the UE 110 may receive configuration information for multiple different OCC schemes in 1610 via RRC. The UE 110 may then be dynamically configured to use a particular OCC scheme via DCI or in any other appropriate manner.

[0128] In some embodiments, for dynamic PUSCH scheduling, PUSCH-Config may include the configured OCC schemes (e.g., cross-symbol OCC, intra-symbol OCC, cross-slot OCC, etc. ) . If one scheme is configured, then it may be used by the UE 110 without any further signaling. However, as mentioned above, if  more than one scheme is configured, the particular OCC scheme that is to be used may be indicated in DCI. The DCI may include a field for this purpose, or an existing DCI field may be configured to provide this functionality.

[0129] In 1630, the UE 110 applies the indicated OCC scheme for PUSCH transmission and TB size determination. In some embodiments, for type 1 configured PUSCH scheduling, the parameter ConfiguredGrantConfig may include a single configured OCC scheme. For type 2 configured PUSCH scheduling, the parameter ConfiguredGrantConfig may include the configured OCC scheme. If one scheme is configured, then it may be used by the UE 110 without any further signaling. However, if more than one scheme is configured, the particular OCC scheme that is to be used may be indicated in DCI or in any other appropriate manner. The DCI may include a field for this purpose, or an existing DCI field may be configured to provide this functionality.

[0130] Examples

[0131] In a first example, a method comprising processing configuration information for transmitting physical uplink shared channel (PUSCH) with a type of orthogonal cover code (OCC) in a terrestrial network (TN) or a non-terrestrial network (NTN) , processing scheduling information for a PUSCH transmission and generating, for transmission, PUSCH based on the scheduling information, wherein transmitting the PUSCH includes applying the type of OCC.

[0132] In a second example, the method of the first example, wherein the type of OCC is cross-symbol OCC.

[0133] In a third example, the method of the second example, wherein the PUSCH transmission is over a single slot.

[0134] In a fourth example, the method of the third example, wherein the single slot includes two or more demodulation reference signal (DMRS) symbols and applying the type of OCC includes no OCC spreading on the two or more symbols or no data transmissions on the DMRS symbols.

[0135] In a fifth example, the method of the third example, wherein the single slot includes two or more demodulation reference signal (DMRS) symbols and applying the type of OCC includes OCC spreading to a next DMRS symbol in the single slot.

[0136] In a sixth example, the method of the third example, wherein the single slot includes two sets of demodulation reference signal (DMRS) symbols comprising a first set of consecutive DMRS symbols with OCC spreading and a second set of consecutive DMRS symbols with OCC spreading.

[0137] In a seventh example, the method of the third example, wherein a number of PUSCH symbols in the slot is not divisible by an OCC size and wherein a remaining symbol carries a new PUSCH symbol.

[0138] In an eighth example, the method of the third example, wherein a number of PUSCH symbols in the slot is not divisible by an OCC size and wherein a remaining symbol carries a copy of a PUSCH symbol included in the slot.

[0139] In a ninth example, the method of the third example, further comprising determining a transport block (TB) size for  the single slot PUSCH based on at least a first parameter indicting a number of symbols for the PUSCH transmission before OCC spreading, wherein the first parameter is based on at least a second parameter indicating a total number of PUSCH symbol allocation for the single slot and a third parameter indicating an OCC size.

[0140] In a tenth example, the method of the third example, further comprising determining a transport block (TB) size for the single slot PUSCH based on at least a first parameter indicting a number of symbols for the PUSCH transmission before OCC spreading, wherein the first parameter is based on at least a second parameter indicating a total number of PUSCH symbol allocation for the single slot, a third parameter indicting a number of demodulation reference symbols (DMRS) in the single slot and a fourth parameter indicating an OCC size.

[0141] In an eleventh example, the method of the second example, wherein the PUSCH transmission is over multiple slots.

[0142] In a twelfth example, the method of the eleventh example, wherein the multiple slots include a first slot comprising multiple demodulation reference signals (DMRS) and a second slot comprising multiple DMRS, wherein a first DMRS symbol in the first slot is OCC spread to a next DMRS symbol in the first slot and the first DMRS symbol in the second slot is OCC spread to a next DMRS symbol in the second slot.

[0143] In a thirteenth example, the method of the eleventh example, wherein the multiple slots include a first slot comprising multiple demodulation reference signals (DMRS) and a second slot comprising multiple DMRS, wherein a first DMRS  symbol in the first slot is OCC spread to a first DMRS symbol in the second slot and the second DMRS slot in the first symbol is OCC spread to the second DMRS in the second slot.

[0144] In a fourteenth example, the method of the eleventh example, wherein a number of PUSCH symbols over the multiple slots is not divisible by an OCC size and wherein a remaining symbol carries a new PUSCH symbol.

[0145] In a fifteenth example, the method of the eleventh example, wherein a number of PUSCH symbols over the multiples slots is not divisible by an OCC size and wherein a remaining symbol carries a copy of a PUSCH symbol included in the multiple slots.

[0146] In a sixteenth example, the method of the eleventh example, wherein redundancy version (RV) cycling is applied over the multiple slots.

[0147] In a seventeenth example, the method of the sixteenth example, wherein a same OCC sequence is applied over the multiple slots.

[0148] In an eighteenth example, the method of the sixteenth example, wherein a different OCC sequence is applied over the multiple slots.

[0149] In a nineteenth example, the method of the eleventh example, wherein redundancy version (RV) cycling stops over different slots of the multiple slots.

[0150] In a twentieth example, the method of the nineteenth example, wherein a same OCC sequence is applied over the multiple slots.

[0151] In a twenty first example, the method of the nineteenth example, wherein a different OCC sequence is applied over the multiple slots.

[0152] In a twenty second example, the method of the nineteenth example, further comprising determining an OCC size for the multiple slots based on a network indicated OCC size and a number of repetitions.

[0153] In a twenty third example, the method of the eleventh example, wherein redundancy version (RV) cycling applies over different slots of the multiple slots and a total number of repetitions is equal to a network indicated number of repetitions multiplied by an OCC size.

[0154] In a twenty fourth example, the method of the eleventh example, wherein a same OCC sequence is applied to multiple PUSCH transmissions.

[0155] In a twenty fifth example, the method of the eleventh example, wherein a different OCC sequence is applied over multiple PUSCH transmissions.

[0156] In a twenty sixth example, the method of the first example, wherein the type of OCC is intra-symbol OCC.

[0157] In a twenty seventh example, the method of the twenty sixth example, wherein each resource element (RE) in a resource block (RB) is multiplied by an OCC value.

[0158] In a twenty eighth example, the method of the twenty seventh example, further comprising determining a transport block (TB) size based on a number of REs allocated for PUSCH within an RB and determining a total number of REs allocated for PUSCH based on at least the number of REs allocated for PUSCH within the RB.

[0159] In a twenty ninth example, the method of the twenty eighth example, wherein intra-symbol OCC is applied to multiple RBs on a same symbol and wherein a modulation symbol is not spread across RBs.

[0160] In a thirtieth example, the method of the twenty eighth example, wherein the number of REs allocated for PUSCH within the RB is based on a parameter indicating a number of subcarriers per RB before OCC spreading.

[0161] In a thirty first example, the method of the thirtieth example, wherein the number of subcarriers per RB before OCC spreading equals 12 divided by an OCC size.

[0162] In a thirty second example, the method of the thirty first example, wherein the number of subcarriers per RB before OCC spreading is further based on a floor or ceiling function.

[0163] In a thirty third example, the method of the twenty seventh example, further comprising determining a total number  of REs allocated for PUSCH based on at least the number of REs allocated for PUSCH.

[0164] In a thirty fourth example, the method of the thirty third example, wherein intra-symbol OCC is applied to multiple RBs on a same symbol and wherein a modulation symbols is spread across RBs.

[0165] In a thirty fifth example, the method of the thirty third example, wherein total number of REs allocated for PUSCH is based on a parameter indicating a number of subcarriers per PUSCH before OCC spreading.

[0166] In a thirty sixth example, the method of the thirty fifth example, wherein the number of subcarriers per PUSCH before OCC spreading equals 12 times the number of RBs divided by an OCC size.

[0167] In a thirty seventh example, the method of the thirty fifth example, wherein the number of subcarriers per PUSCH before OCC spreading is further based on a floor or ceiling function.

[0168] In a thirty eighth example, the method of the twenty sixth example, wherein each resource block (RB) is multiplied by an OCC value.

[0169] In a thirty ninth example, the method of the thirty eighth example, further comprising determining a transport block (TB) size based on a number of resource elements (REs) allocated for PUSCH.

[0170] In a fortieth example, the method of the first example, wherein the type of OCC is cross-slot OCC.

[0171] In a forty first example, the method of the fortieth example, further comprising processing configuration information for single transport block (TB) with repetition for cross-slot OCC.

[0172] In a forty second example, the method of the forty first example, wherein a total number of slots allocated for the PUSCH transmission is based on a parameter indicating a number of repetitions and a parameter indicating an OCC size.

[0173] In a forty third example, the method of the forty second example, wherein OCC spreading is applied to slots before PUSCH repetition redundancy version (RV) is applied to the slots.

[0174] In a forty fourth example, the method of the forty second example, wherein PUSCH repetition redundancy version (RV) is applied to slots before OCC spreading is applied to the slots.

[0175] In a forty fifth example, the method of the forty first example, wherein a total number of slots allocated for the PUSCH transmission is based on a parameter indicating a number of repetitions.

[0176] In a forty sixth example, the method of the forty fifth example, wherein OCC spreading is applied to slots before PUSCH repetition redundancy version (RV) is applied to the slots.

[0177] In a forty seventh example, the method of the forty fifth example, wherein PUSCH repetition redundancy version (RV) is applied to slots before OCC spreading is applied to the slots.

[0178] In a forty eighth example, the method of the fortieth example, further comprising generating, for transmission to a network, capability information indicating a capability of OCC demodulation reference signal (DMRS) bundling, wherein the network schedules cross-slot OCC based on the capability information.

[0179] In a forty ninth example, the method of the fortieth example, wherein an initiation value of PUSCH demodulation reference signal (DMRS) sequence uses a common slot number within a frame.

[0180] In a fiftieth example, the method of the first example, further comprising processing an indication of an OCC scheme to be used for PUSCH transmission.

[0181] In a fifty first example, the method of the fiftieth example, wherein the OCC scheme is one of cross-symbol OCC, intra-symbol OCC and cross-slot OCC.

[0182] In a fifty second example, the method of the first example, further comprising processing an indication of two or more OCC schemes for multiplexing PUSCH.

[0183] In a fifty third example, the method of the fifty second example, further comprising processing downlink control  information (DCI) comprising an indication that one of the two or more OCC schemes is to be used for the PUSCH transmission.

[0184] In a fifty fourth example, the method of the fifty third example, wherein the two or more OCC schemes include cross-symbol OCC, intra-symbol OCC and cross-slot OCC.

[0185] In a fifty fifth example, a processor configured to perform any of the methods of the first through fifty fourth examples.

[0186] In a fifty sixth example, a user equipment (UE) comprising a transceiver configured to communicate with a base station and a processor communicatively coupled to the transceiver and configured to perform any of the methods of the first through fifty fourth examples.

[0187] Those skilled in the art will understand that the above-described example embodiments may be implemented in any suitable software or hardware configuration or combination thereof. An example hardware plat form for implementing the example embodiments may include, for example, an Intel x86 based platform with compatible operating system, a Windows OS, a Mac platform and MAC OS, a mobile device having an operating system such as iOS, Android, etc. The example embodiments of the above described method may be embodied as a program containing lines of code stored on a non-transitory computer readable storage medium that, when compiled, may be executed on a processor or microprocessor.

[0188] Although this application described various embodiments each having different features in various  combinations, those skilled in the art will understand that any of the features of one embodiment may be combined with the features of the other embodiments in any manner not specifically disclaimed or which is not functionally or logically inconsistent with the operation of the device or the stated functions of the disclosed embodiments.

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

[0190] It will be apparent to those skilled in the art that various modifications may be made in the present disclosure, without departing from the spirit or the scope of the disclosure. Thus, it is intended that the present disclosure cover modifications and variations of this disclosure provided they come within the scope of the appended claims and their equivalent.

Claims

1.An apparatus comprising processing circuitry configured to:process configuration information for transmitting physical upl ink shared channel (PUSCH) with a type of orthogonal cover code (OCC) in a terrestrial network (TN) or a non-terrestrial network (NTN) ;process scheduling information for a PUSCH transmission; andgenerate, for transmission, PUSCH based on the scheduling information, wherein transmitting the PUSCH includes applying the type of OCC.2.The apparatus of claim 1, wherein the type of OCC is cross-symbol OCC.3.The apparatus of claim 2, wherein the PUSCH transmission is over a single slot.4.The apparatus of claim 3, wherein the single slot includes two or more demodulation reference signal (DMRS) symbols and applying the type of OCC includes no OCC spreading on the two or more symbols or no data transmissions on the DMRS symbols.5.The apparatus of claim 3, wherein the single slot includes two or more demodulation reference signal (DMRS) symbols and applying the type of OCC includes OCC spreading to a next DMRS symbol in the single slot.6.The apparatus of claim 3, wherein the single slot includes two sets of demodulation reference signal (DMRS) symbols comprising a first set of consecutive DMRS symbols with OCC  spreading and a second set of consecutive DMRS symbols with OCC spreading.7.The apparatus of claim 3, wherein a number of PUSCH symbols in the slot is not divisible by an OCC size and wherein a remaining symbol carries a new PUSCH symbol.8.The apparatus of claim 3, wherein a number of PUSCH symbols in the slot is not divisible by an OCC size and wherein a remaining symbol carries a copy of a PUSCH symbol included in the slot.9.The apparatus of claim 3, wherein the processing circuitry is further configured to:determine a transport block (TB) size for the single slot PUSCH based on at least a first parameter indicting a number of symbols for the PUSCH transmission before OCC spreading, wherein the first parameter is based on at least a second parameter indicating a total number o f PUSCH symbol allocation for the single slot and a third parameter indicating an OCC size.10.The apparatus of claim 3, wherein the processing circuitry is further configured to:determine a transport block (TB) size for the single slot PUSCH based on at least a first parameter indicting a number of symbols for the PUSCH transmission before OCC spreading, wherein the first parameter is based on at least a second parameter indicating a total number of PUSCH symbol allocation for the single slot, a third parameter indicting a number of demodulation reference symbols (DMRS) in the single slot and a fourth parameter indicating an OCC size.11.The apparatus of claim 2, wherein the PUSCH transmission is over multiple slots.12.The apparatus of claim 11, wherein the multiple slots include a first slot comprising multiple demodulation reference signals (DMRS) and a second slot comprising multiple DMRS, wherein a first DMRS symbol in the first slot is OCC spread to a next DMRS symbol in the first slot and the first DMRS symbol in the second slot is OCC spread to a next DMRS symbol in the second slot.13.The apparatus of claim 11, wherein the multiple slots include a first slot comprising multiple demodulation reference signals (DMRS) and a second slot comprising multiple DMRS, wherein a first DMRS symbol in the first slot is OCC spread to a first DMRS symbol in the second slot and the second DMRS slot in the first symbol is OCC spread to the second DMRS in the second slot.14.The apparatus of claim 11, wherein a number of PUSCH symbols over the multiple slots is not divisible by an OCC size and wherein a remaining symbol carries a new PUSCH symbol.15.The apparatus of claim 11, wherein a number of PUSCH symbols over the multiples slots is not divisible by an OCC size and wherein a remaining symbol carries a copy of a PUSCH symbol included in the multiple slots.16.The apparatus of claim 11, wherein redundancy version (RV) cycling is applied over the multiple slots.17.The apparatus of claim 16, wherein a same OCC sequence is applied over the multiple slots.18.The apparatus of claim 16, wherein a different OCC sequence is applied over the multiple slots.19.The apparatus of claim 11, wherein redundancy version (RV) cycling stops over different slots of the multiple slots.20.The apparatus of claim 19, wherein a same OCC sequence is applied over the multiple slots.

Images