Techniques for uplink capacity enhancement

By employing OCC technology and DFT-s-OFDM waveforms in the wireless communication system, the problems of low UL coverage and low resource utilization in satellite communication are solved, the system capacity and resource allocation efficiency are improved, and the rapid communication needs of UEs within the geographical coverage area of ​​LEO satellites are met.

CN122641998APending Publication Date: 2026-08-25LENOVO (SINGAPORE) PTE LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202580011936.0
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Priority Date
2024-02-09
Filing Date
2025-02-10
Publication Date
2026-08-25

AI Technical Summary

Technical Problem

In wireless communication systems, especially in satellite communications, repeated transmissions lead to low UL coverage and resource utilization, affecting system capacity and throughput. Furthermore, resource allocation efficiency is low, and the need for rapid coordination of UEs within the geographical coverage area of ​​LEO satellites has not been effectively addressed.

Method used

The orthogonal coverage code (OCC) technique is used to apply Discrete Fourier Transform Spread Spectrum Orthogonal Frequency Division Multiplexing (DFT-s-OFDM) waveforms in the time-domain UL data channel. Through flexible time-domain resource allocation and multiplexing technology, the UL communication capacity is improved.

Benefits of technology

It improves the UL capacity and resource utilization of the wireless communication system, reduces latency, and meets the rapid resource allocation needs of UEs within the geographical coverage area of ​​LEO satellites.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122641998A_ABST
    Figure CN122641998A_ABST
Patent Text Reader

Abstract

Various aspects of the present disclosure relate to techniques for preventing dimension reduction attacks. A user equipment (UE) is configured to receive, from a network entity, a configuration comprising a set of time-domain orthogonal cover code sequences, each time-domain orthogonal cover code sequence of the set of time-domain orthogonal cover code sequences comprising a sequence length that is different from sequence lengths of other time-domain orthogonal cover code sequences of the set of time-domain orthogonal cover code sequences; select, from the set of time-domain orthogonal cover code sequences, at least one time-domain orthogonal cover code sequence; multiplex uplink (UL) data associated with the UE in accordance with the selected at least one time-domain orthogonal cover code sequence; transmit, via a physical UL shared channel (PUSCH), a waveform carrying the multiplexed uplink data associated with the UE.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This disclosure relates to wireless communications, and more specifically to techniques for uplink (UL) capacity enhancement. Background Technology

[0002] A wireless communication system may include one or more network communication devices, such as base stations, that support wireless communication for one or more user communication devices, which may also be referred to as user equipment (UE) or other suitable terms. The wireless communication system can support wireless communication with one or more user communication devices by utilizing the resources of the wireless communication system (e.g., time resources (e.g., symbols, time slots, subframes, frames, etc.) or frequency resources (e.g., subcarriers, carriers, etc.)). Furthermore, the wireless communication system can support wireless communication across a variety of radio access technologies, including third-generation (3G), fourth-generation (4G), fifth-generation (5G), and other suitable radio access technologies other than 5G (e.g., sixth-generation (6G)). Summary of the Invention

[0003] The article “a” preceding an element is unrestricted and should be understood to refer to “at least one” or “one or more” of those elements. The terms “a,” “at least one,” “one or more,” and “at least one of one or more” are interchangeable. As used herein, the word “or,” as used in a list of items (e.g., a list of items beginning with phrases such as “at least one,” “one or more,” or “one or two”) indicates an inclusive list, such that a list of at least one of, for example, A, B, or C means A or B or C or AB or AC or BC or ABC (i.e., A and B and C). Furthermore, as used herein, the phrase “based on” should not be construed as referring to a closed set of conditions. For example, without departing from the scope of this disclosure, an example step described as “based on condition A” may be based on both condition A and condition B. In other words, as used herein, the phrase “based on” should be interpreted in the same manner as the phrase “at least partially based on.” Furthermore, as used herein, the word “group” may comprise one or more elements.

[0004] A UE for wireless communication is described. The UE can be configured, enabled, or operable to: receive from a network entity a configuration comprising a set of time-domain orthogonal code sequences, each of the time-domain orthogonal code sequences comprising a sequence length different from the sequence lengths of the other time-domain orthogonal code sequences in the set; select at least one time-domain orthogonal code sequence from the set of time-domain orthogonal code sequences; multiplex UL data associated with the UE according to the selected at least one time-domain orthogonal code sequence; and transmit a waveform carrying the multiplexed UL data associated with the UE via a Physical UL Shared Channel (PUSCH).

[0005] A method for wireless communication performed by a UE is described. The method is configurable, capable of, or operable to: receive from a network entity a configuration comprising a set of time-domain orthogonal code sequences, each of the time-domain orthogonal code sequences comprising a sequence length different from the sequence lengths of the other time-domain orthogonal code sequences in the set; select at least one time-domain orthogonal code sequence from the set of time-domain orthogonal code sequences; multiplex UL data associated with the UE according to the selected at least one time-domain orthogonal code sequence; and transmit a waveform carrying the multiplexed UL data associated with the UE via a PUSCH.

[0006] A network apparatus (NE) for wireless communication is described. The NE is configured, capable of, or operable to transmit to a UE an indication of applying an orthogonal code sequence in the time domain, receive a PUSCH transmission having at least one selected orthogonal code sequence applied to a waveform in the time domain, and multiplex the PUSCH transmissions of multiple UEs based on the orthogonal code sequence in the time domain.

[0007] A method for wireless communication performed by a NE is described. The method is configurable, capable, or operable to transmit to a UE an indication of applying an orthogonal code sequence in the time domain, receive a PUSCH transmission having at least one selected orthogonal code sequence applied to a waveform in the time domain, and multiplex the PUSCH transmissions of multiple UEs based on the orthogonal code sequence in the time domain. Attached Figure Description

[0008] Figure 1 Examples of wireless communication systems according to aspects of this disclosure are described.

[0009] Figure 2A This describes an example of a PUSCH-Config Radio Resource Control (RRC) message according to aspects of this disclosure.

[0010] Figure 2BThis describes an instance of the ConfiguredGrantConfig information element according to aspects of this disclosure.

[0011] Figure 3 This document describes an example of a time-domain orthogonal cover code (OCC) configuration for multi-slot PUSCH transmission according to aspects of this disclosure.

[0012] Figure 4 This describes an example of an OCC application that enables time-slot aggregation according to aspects of this disclosure.

[0013] Figure 5 Examples of UEs based on aspects of this disclosure are described.

[0014] Figure 6 Examples of processors according to aspects of this disclosure are described.

[0015] Figure 7 Examples of NEs based on aspects of this disclosure are described.

[0016] Figure 8 A flowchart illustrating a method performed by a UE according to aspects of this disclosure.

[0017] Figure 9 A flowchart illustrating the method performed by NE according to aspects of this disclosure. Detailed Implementation

[0018] Wireless communication systems (e.g., non-terrestrial networks (NTNs)) that include one or more UEs and NEs can support improved UL coverage, such as repeating and demodulation reference signal (DMRS) bundling. In some cases, applying repeating to wireless communication (e.g., UL transmission, downlink transmission) alone can significantly reduce the capacity of the wireless communication system, including the throughput of one or more UEs, by reducing the resources available for data that can be used for one or more UEs and the entire wireless communication system (e.g., other UEs or NEs). Furthermore, applying repeating to wireless communication alone can increase the latency of wireless communication, and therefore, one or more UEs may experience higher utilization of UL resources in the time domain before these resources can be released to other UEs.

[0019] As an example, in an NTN, satellites can be configured with extensive geographic coverage areas, which can result in many UEs being located within these coverage areas. In some cases (e.g., wireless communication via low Earth orbit (LEO) satellites), several UEs within the geographic coverage area of ​​an LEO satellite may need to quickly coordinate with the LEO satellite (e.g., gain access to the LEO satellite, obtain resource allocation from the LEO satellite, etc.) to perform wireless communication (e.g., transmission) while within the LEO satellite's geographic coverage area. The limitation of the total spectrum resources available to the NTN may further necessitate significant improvements in system capacity efficiency. For example, depending on the service mode, some UEs may require more resources than others, thus requiring a higher granularity of resource multiplexing.

[0020] Various aspects of this disclosure relate to enabling one or more UEs to support UL communication using orthogonal coverage codes (OCC), which can result in increased UL capacity for one or more UEs as described herein. Other aspects of this disclosure relate to one or more configurations for applying OCC to time-domain UL data channels while employing Discrete Fourier Transform Spread Spectrum Orthogonal Frequency Division Multiplexing (DFT-s-OFDM) waveforms.

[0021] Aspects of this disclosure are described in the context of wireless communication systems.

[0022] Figure 1 This section describes an example of a wireless communication system 100 according to aspects of this disclosure. The wireless communication system 100 may include one or more NEs 102, one or more UEs 104, and a core network (CN) 106. The wireless communication system 100 may support various radio access technologies. In some embodiments, the wireless communication system 100 may be a 4G network, such as an LTE network or an LTE-A network. In some other embodiments, the wireless communication system 100 may be an NR network, such as a 5G network, a 5G-A network, or a 5G Ultra Wideband (5G-UWB) network. In other embodiments, the wireless communication system 100 may be a combination of 4G and 5G networks, or other suitable radio access technologies, including IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), and IEEE 802.20. The wireless communication system 100 may support radio access technologies other than 5G, such as 6G. In addition, the wireless communication system 100 can support technologies such as Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), or Code Division Multiple Access (CDMA).

[0023] One or more NEs 102 may be distributed across a geographical area to form a wireless communication system 100. One or more of the NEs 102 described herein may be, include, or be referred to as a network node, base station, network element, network function, network entity, radio access network (RAN), NodeB, eNodeB (eNB), next-generation NodeB (gNB), or other suitable terms. NEs 102 and UEs 104 may communicate via a communication link, which may be a wireless or wired connection. For example, NEs 102 and UEs 104 may perform wireless communication (e.g., receive signaling, transmit signaling) via a Uu interface.

[0024] NE 102 can provide a geographic coverage area that supports services for one or more UEs 104 within that geographic coverage area. For example, NE 102 and UE 104 can support wireless communication of signals associated with services (e.g., voice, video, packet data, messaging, broadcasting, etc.) based on one or more radio access technologies. In some embodiments, NE 102 can be mobile, for example, a satellite associated with a non-terrestrial network (NTN). In some embodiments, different geographic coverage areas 112 associated with the same or different radio access technologies can overlap, but different geographic coverage areas can be associated with different NEs 102.

[0025] One or more UEs 104 may be distributed across a geographical area of ​​the wireless communication system 100. UE 104 may include or be referred to as a remote unit, mobile device, wireless device, remote device, subscriber device, transmitter device, receiver device, or some other suitable term. In some implementations, UE 104 may be referred to as a unit, station, terminal, or client, and other instances thereof. Additionally or alternatively, UE 104 may be referred to as an Internet of Things (IoT) device, an Internet of Everything (IoE) device, or a Machine Type Communication (MTC) device, and other instances thereof.

[0026] UE 104 may be able to support direct wireless communication with other UE 104 via a communication link. For example, UE 104 may support direct wireless communication with another UE 104 via a device-to-device (D2D) communication link. In some implementations, such as vehicle-to-vehicle (V2V) deployments, vehicle-to-everything (V2X) deployments, or cellular-V2X deployments, communication link 114 may be referred to as a side link. For example, UE 104 may support direct wireless communication with another UE 104 via a PC5 interface.

[0027] NE 102 may support communication with CN 106 or with another NE 102 or both. For example, NE 102 may interface with other NE 102 or CN 106 via one or more backhaul links (e.g., S1, N2, N2, or network interfaces). In some embodiments, NE 102 may communicate directly with each other. In some other embodiments, NE 102 may communicate with each other or indirectly (e.g., via CN 106). In some embodiments, one or more NE 102 may include sub-components, such as access network entities, which may be instances of Access Node Controllers (ANCs). The ANC may communicate with one or more UE 104s via one or more other access network transmitting entities (which may be referred to as radio heads, smart radio heads, or TRPs).

[0028] CN 106 can support user authentication, access authorization, tracking, connectivity, and other access, routing, or mobility functions. CN 106 can be an evolved packet core (EPC) or a 5G core (5GC), which may include control plane entities (e.g., Mobility Management Entity (MME), Access and Mobility Management Function (AMF)) that manage access and mobility, and user plane entities (e.g., Serving Gateway (S-GW), Packet Data Network (PDN) Gateway (P-GW), or User Plane Function (UPF)) that route packets or interconnect to external networks. In some implementations, the control plane entities may manage non-access stratum (NAS) functions of one or more UEs 104 served by one or more NEs 102 associated with CN 106, such as mobility, authentication, and bearer management (e.g., data bearers, signaling bearers, etc.).

[0029] CN 106 can communicate with the packet data network via one or more backhaul links (e.g., via S1, N2, N2, or another network interface). The packet data network may contain an application server. In some implementations, one or more UEs 104 can communicate with the application server. UE 104 can establish a session (e.g., a Protocol Data Unit (PDU) session, etc.) with CN 106 via NE 102. CN 106 can use the established session (e.g., an established PDU session) to route services (e.g., control information, data, etc.) between UE 104 and the application server. A PDU session may be an instance of a logical connection between UE 104 and CN 106 (e.g., one or more network functions of CN 106).

[0030] In the wireless communication system 100, NE 102 and UE 104 can use the resources of the wireless communication system 100 (e.g., time resources (e.g., symbols, time slots, subframes, frames, etc.) or frequency resources (e.g., subcarriers, carriers)) to perform various operations (e.g., wireless communication). In some embodiments, NE 102 and UE 104 may support different resource structures. For example, NE 102 and UE 104 may support different frame structures. In some embodiments, such as in 4G, NE 102 and UE 104 may support a single frame structure. In some other embodiments, such as in 5G and other suitable radio access technologies, NE 102 and UE 104 may support various frame structures (i.e., multiple frame structures). NE 102 and UE 104 may support various frame structures based on one or more parameter sets.

[0031] The wireless communication system 100 may support one or more parameter sets, and the parameter sets may include subcarrier spacing and cyclic prefixes. A first parameter set (e.g., μ=0) may be associated with a first subcarrier spacing (e.g., 15 kHz) and a regular cyclic prefix. In some embodiments, the first parameter set (e.g., μ=0) associated with the first subcarrier spacing (e.g., 15 kHz) may utilize one time slot per subframe. A second parameter set (e.g., μ=1) may be associated with a second subcarrier spacing (e.g., 30 kHz) and a regular cyclic prefix. A third parameter set (e.g., μ=2) may be associated with a third subcarrier spacing (e.g., 60 kHz) and a regular cyclic prefix or an extended cyclic prefix. A fourth parameter set (e.g., μ=3) may be associated with a fourth subcarrier spacing (e.g., 120 kHz) and a regular cyclic prefix. A fifth parameter set (e.g., μ=4) may be associated with a fifth subcarrier spacing (e.g., 240 kHz) and a regular cyclic prefix.

[0032] Time intervals for resources (e.g., communication resources) can be organized according to frames (also known as radio frames). Each frame may have a duration, for example, 10 milliseconds (ms). In some embodiments, each frame may contain multiple subframes. For example, each frame may contain 10 subframes, and each subframe may have a duration, for example, 1 ms. In some embodiments, each frame may have the same duration. In some embodiments, each subframe of a frame may have the same duration.

[0033] Alternatively, the time intervals of resources (e.g., communication resources) can be organized according to time slots. For example, a subframe may contain a certain number (e.g., quantity) of time slots. The number of time slots in each subframe may also depend on one or more parameter sets supported in the wireless communication system 100. For example, the first, second, third, fourth, and fifth parameter sets (i.e., μ=0, μ=1, μ=2, μ=3, μ=4) associated with corresponding subcarrier intervals of 15 kHz, 30 kHz, 60 kHz, 120 kHz, and 240 kHz may utilize a single time slot per subframe, two time slots per subframe, four time slots per subframe, eight time slots per subframe, and 16 time slots per subframe, respectively. Each time slot may contain a certain number (e.g., quantity) of symbols (e.g., OFDM symbols). In some embodiments, the number (e.g., quantity) of time slots in a subframe may depend on the parameter set. For a conventional cyclic prefix, a time slot may contain 14 symbols. For an extended cyclic prefix (e.g., applicable to a 60 kHz subcarrier spacing), a time slot may contain 12 symbols. The relationship between the number of symbols per time slot for the regular cyclic prefix and the extended cyclic prefix, the number of time slots per subframe, and the number of time slots per frame may depend on the parameter set. It should be understood that references to the first parameter set (e.g., μ=0) associated with the first subcarrier spacing (e.g., 15 kHz) may be used interchangeably between subframes and time slots.

[0034] In the wireless communication system 100, the electromagnetic (EM) spectrum can be divided into various categories, frequency bands, channels, etc., based on frequency or wavelength. For example, the wireless communication system 100 may support one or more operating frequency bands, such as frequency range names FR1 (410 MHz to 7.125 GHz), FR2 (24.25 GHz to 52.6 GHz), FR3 (7.125 GHz to 24.25 GHz), FR4 (52.6 GHz to 114.25 GHz), FR4a or FR4-1 (52.6 GHz to 71 GHz), and FR5 (114.25 GHz to 300 GHz). In some embodiments, NE 102 and UE 104 may perform wireless communication on one or more of the operating frequency bands. In some embodiments, FR1 may be used by NE 102 and UE 104, as well as other equipment or devices, for cellular communication services (e.g., control information, data). In some implementations, FR2 can be used by NE 102 and UE 104, as well as other equipment or devices, for short-range, high data rate capabilities.

[0035] FR1 may be associated with one or more parameter sets (e.g., at least three parameter sets). For example, FR1 may be associated with a first parameter set containing a 15 kHz subcarrier spacing (e.g., μ=0); a second parameter set containing a 30 kHz subcarrier spacing (e.g., μ=1); and a third parameter set containing a 60 kHz subcarrier spacing (e.g., μ=2). FR2 may be associated with one or more parameter sets (e.g., at least two parameter sets). For example, FR2 may be associated with a third parameter set containing a 60 kHz subcarrier spacing (e.g., μ=2); and a fourth parameter set containing a 120 kHz subcarrier spacing (e.g., μ=3).

[0036] The solutions discussed in this paper relate to techniques for enhancing UL capacity. According to TS 38.300 (which is incorporated herein by reference), the downlink transmit waveform is conventional orthogonal frequency division multiplexing (OFDM) using a cyclic prefix (CP). The UL transmit waveform is conventional OFDM using CP, where a transform precoding function performs Discrete Fourier Transform (DFT) spread spectrum, which can be disabled or enabled. For operations with shared spectrum channel access in FR1, the UL transmit waveform subcarrier mapping can be mapped to subcarriers interleaved in one or more Physical Resource Blocks (PRBs).

[0037] In one embodiment, the Physical UL Shared Channel (PUSCH) supports two transmission schemes: codebook-based transmission and non-codebook-based transmission. For codebook-based transmission, the gNB provides a transmit precoding matrix indication to the UE in the Downlink Control Information (DCI). The UE uses the indication to select a PUSCH transmit precoder from the codebook. For non-codebook-based transmission, the UE determines its PUSCH precoder based on the Wideband Probe Reference Signal (SRS) Resource Indicator (SRI) field from the DCI.

[0038] PUSCH supports spatial multiplexing based on closed-loop DMRS. For a given UE, it supports up to 4 layers of transmission. The number of codewords is 1. When using transform precoding, only a single multiple-input multiple-output (MIMO) layer transmission is supported. It supports transmission durations from 1 to 14 symbols per time slot and supports aggregation of multiple time slots with transport block (TB) repetition.

[0039] In one embodiment, two types of frequency hopping are supported: intra-slot frequency hopping and inter-slot frequency hopping in the case of time slot aggregation. Intra-slot and inter-slot frequency hopping are not supported when using PRB interleaved UL transmit waveforms.

[0040] In one embodiment, PUSCH can be scheduled using DCI on the Physical Downlink Control Channel (PDCCH), or semi-static configuration authorization can be provided via Radio Resource Control (RRC), supporting two types of operations: triggering the first PUSCH with DCI, wherein subsequent PUSCH transmissions follow the RRC configuration and scheduling received on DCI, or triggering the PUSCH by data arriving at the UE's transmit buffer and PUSCH transmissions following the RRC configuration.

[0041] In one embodiment, the UL physical layer processing of the transport channel comprises the following steps: transport block CRC appending; code block segmentation and code block CRC appending; channel coding: LDPC coding; physical layer hybrid ARQ processing; rate matching; scrambling; modulation: π / 2 BPSK (with transform precoding only), QPSK, 16QAM, 64QAM, and 256QAM; layer mapping, transform precoding (enabled / disabled by configuration), and precoding; mapping to assigned resources and antenna ports.

[0042] In one embodiment, the UE transmits at least one symbol with a demodulation reference signal on each layer of each frequency hopping frequency in which it transmits the PUSCH, and up to three additional DMRSs can be configured by higher layers. Phase tracking RSs can be transmitted on the additional symbols to assist receiver phase tracking. The UL-SCH physical layer model is described in TS38.202, which is incorporated herein by reference.

[0043] For configuration grant operations with shared spectrum channel access as described in Clause 10.3, configuration grant UL control information (CG-UCI) may be transmitted in the PUSCH scheduled by configuration UL grant.

[0044] In one embodiment, according to 3GPP TS 38.211, up to two codewords can be transmitted. In the case of single codeword transmission, .

[0045] For each codeword, bit block ,in The scrambling bit block is the number of bits in the codeword q transmitted over the physical channel and should be scrambled before modulation. The scrambling bit block is generated according to the following pseudocode.

[0046]

[0047] Where x and y are labels defined, for example, in TS 38.212 (which is incorporated herein by reference) and where the scrambling sequence As given in Clause 5.2.1, the scrambling sequence generator shall apply the following initialization:

[0048]

[0049] in It is equal to the higher-level parameter dataScramblingIdentityPUSCH (if configured) and RNTI is equal to C-RNTI, MCS-C-RNTI, SP-CSI-RNTI or CS-RNTI, and DCI format 0_0 is not used to schedule the launch in the common search space; If the higher-level parameter msgA-DataScramblingIndex (if configured) is true and the PUSCH transmission is triggered by one of two random access procedures as described in Clause 8.1A of TS 38.213 (which is incorporated herein by reference); otherwise, ; It is the index of the random access preamble for the msgA transmission as described in Clause 5.1.3A of TS 38.321 (which is incorporated herein by reference), and in which The RA-RNTI is equal to msgA, and otherwise corresponds to the RNTI associated with the PUSCH transmission as described in Clause 6.1 of TS 38.214 (which is incorporated herein by reference) and Clause 8.3 of TS 38.213 (which is incorporated herein by reference).

[0050] For each codeword q, the scrambling bit block should be modulated using one of the modulation schemes in Table 6.3.1.2-1 as described in Clause 5.1. Generate complex-valued modulation symbol blocks .

[0051] In one embodiment, the complex-valued modulation symbol of each of the codewords to be transmitted should be mapped to up to four layers according to Table 7.3.1.3-1. The complex-valued modulation symbol of codeword q Should be mapped to layer Above, among which It is the number of layers and It is the number of modulation symbols in each layer.

[0052] In one embodiment, if transform precoding is not enabled according to TS 38.214 6.1.3, then for each layer , .

[0053] If transform precoding is enabled according to TS38.214 6.1.3, then and It depends on the configuration of the phase tracking reference signal.

[0054] If the procedure in TS 38.214 indicates that a phase tracking reference signal is not used, then a single layer Complex value symbol block It should be classified as The set, each corresponding to an OFDM symbol and .

[0055] If the program in TS 38.214 indicates that a phase tracking reference signal is being used, then the complex value symbol block... It should be divided into multiple sets, each set corresponding to one OFDM symbol, and the set... contain Each symbol is mapped to the corresponding OFDM symbol before transform precoding. Complex value symbol ,in and The set is defined in Clause 6.4.1.2.2.2. The index m of the PT-RS samples and the number of samples per PT-RS group. and the number of PT-RS groups When OFDM symbol When there are one or more PT-RS samples, the number ,otherwise .

[0056] The precoding should be transformed according to the following applications:

[0057]

[0058]

[0059]

[0060] Generate complex value symbol block .variable ,in The bandwidth of PUSCH is represented by the resource block, and it should satisfy:

[0061]

[0062] in It is a set of non-negative integers.

[0063] In one embodiment, vector block Precoding should be performed according to the following:

[0064]

[0065] in The antenna port set should be determined according to the procedure in [6, TS 38.214]. .

[0066] For non-codebook-based transmissions, the precoding matrix W is equal to the identity matrix.

[0067] For codebook-based transmission, the precoding matrix W depends on the number of antenna ports used for transmission—for single-layer transmission on a single antenna port, W = 1; for transmission using 2 or 4 antenna ports, W is given by Tables 6.3.1.5-1 to 6.3.1.5-7; for transmission using 8 antenna ports, W is given by… The matrix is ​​given, where the subscripts i and f(i) denote the rows of the corresponding matrices; f(i) is given in Table 6.3.1.5-8; the intermediate precoding matrix W' is given in Tables 6.3.1.5-9 to 6.3.1.5-24, 6.3.1.5-29 to 6.3.1.5-36, and 6.3.1.5-39 to 6.3.1.5-47, where... Represents a matrix with m rows and n columns, all zeros; submatrix The details are given in Tables 6.3.1.5-25 to 6.3.1.5-28 and 6.3.1.5-37 to 6.3.1.5-38.

[0068] The TPMI index used in the table above is obtained from the DCI or higher-level parameters that schedule the UL transmission, according to the procedure in TS 38.214. When the higher-level parameter txConfig is not configured, the precoding matrix W = 1.

[0069] Generally, the subject matter described in this document describes the application of OCC time domain to the configuration of UL data channel capacity improvement while employing DFT-s-OFDM waveforms. The time domain allocation of resources for PUSCH is flexible, with different symbols within a single time slot potentially allocated to the UE. Furthermore, time domain scheduling can be dynamic or based on RRC signaling. Therefore, the selection of the OCC lookup table from different length tables will depend on the number of time domain symbols allocated. Additionally, the allocated time domain symbols may exceed the available OCC sequence length, which in turn will require an applicability indication mapping mode for multiple OCC lengths. Therefore, the following features are disclosed herein: indications of enabling / disabling the time domain application of OCC to PUSCH transmission and capability indications; configuration of OCC parameters including a DCI-based solution with dynamic scheduling and an RRC signaling-based solution for semi-persistent scheduling; OCC parameters for multi-slot scheduling; and configuration of OCC parameters for PUSCH repetition.

[0070] According to the first embodiment, when transform precoding is enabled, the network instructs the UE to apply OCC in the time domain for multiplexing of PUSCH transmissions from multiple users. In one implementation, the application of OCC to PUSCH transmissions can be indicated via RRC signaling, and the selection of the sequence to be used can be explicitly or implicitly indicated along with PUSCH resource allocation. For example, new fields 202 and 204 in the PUSCH-Config RRC message can be used to indicate whether time-domain or frequency-domain OCC will be used, such as... Figure 2A As explained in the text. Figure 2A This describes an example of a PUSCH-Config RRC message according to aspects of this disclosure.

[0071] In one implementation, when multiple types of OCC sequences are defined as lookup tables, the type of OCC to be applied to the PUSCH transmission can also be indicated in the configuration. For example, two sets of OCCs can be used for PUSCH transmission in the time or frequency domain, such as a DFT-based OCC and a Walsh-Hadamard-based OCC. Then, in addition to information about enabling / disabling OCCs, fields can be used to indicate which type of table will be used to select the OCC sequence, for example, using the field `timeDomainOCCType = ENUMERATED (DFT, Walsh-Hadamard) 204`. The OCC length and index of the selected OCC sequence can be indicated separately or in the same configuration.

[0072] In one implementation, temporal OCC is only applied when transform precoding is enabled. Therefore, if the transformPrecoder field is disabled in the PUSCH-Config IE, information about OCC may not be considered. If the ttransformPrecoder field does not exist, the UE will look for the msg3-transformPrecoder field, and if that field is enabled, only the OCC field in the PUSCH configuration will be used.

[0073] In one embodiment, the UE indicates to the network its capability to support OCC for time-domain applications of PUSCH transmission, which may be indicated by a specific field in the IE Phy-Parameters (used to convey physical layer capabilities) during capability exchange messages via RRC signaling. The network can only configure the OCC sequence for the UE if it knows that the UE has the capability to apply OCC. In one implementation, the UE also indicates the maximum length of the codes it supports and its capability to support OCC applications.

[0074] According to the second embodiment, once the network indicates that OCC application is enabled for PUSCH data (e.g., as described in the first embodiment), the network explicitly or implicitly indicates to the UE the OCC parameters that can help select the OCC sequence to be used in the time domain. Depending on the type of PUSCH scheduling, such as dynamic scheduling or configuration scheduling, this can be explicitly or implicitly indicated in the DCI, or indicated via the System Information Block (SIB) or via dedicated RRC signaling.

[0075] In one embodiment, when dynamically configuring time-domain PUSCH resource allocation, the OCC index (i.e., which selects the OCC sequence from the OCC lookup table) can be explicitly indicated in the UL scheduling DCI format (e.g., DCI 0_0 and 0_1) by using a field (e.g., the OCC index), while the length of the code (i.e., which defines the selection of the lookup table from multiple OCC lookup tables of various lengths) can be explicitly or implicitly indicated by a field in the same configuration.

[0076] In one implementation, the length of the OCC is implicitly indicated using a Start and Length Indicator (SLIV) value, where the OCC sequence may have the same length as the value L in the SLIV. Here, L indicates the allocation length of the PUSCH symbol in the time domain. Essentially, the UE will need to select a row index, where this row index corresponds to the time domain resource assignment value in DCI 0_0 or 0_1.

[0077] For example, when TimeDomainAllocationList is not configured via IEs pusch-ConfigCommon or pusch-ConfigDepending, the UE will use the default PUSCH time domain allocation table A, which specifies up to 16 rows of parameters indicating, for example, slot offset, PUSCH mapping type, start value, and length of allocation symbol. The UE will select the corresponding row from the lookup table based on the received four-bit value of the time domain resource assignment in DCI 0_0 or 0_1.

[0078] Alternatively, when configuring the TimeDomainAllocationList, the UE decodes the start and length values ​​from the SLIV values ​​indicated in the time-domain allocation list. It should be noted that the maximum value of the parameter L in the SLIV (indicating the length of the allocated symbol in the time domain) is 14. Furthermore, the length in the time domain is always allocated in multiples of 2, starting from a minimum of 4 symbols and continuing up to a maximum of 14 symbols. Therefore, in one implementation, multiple OCC lookup tables corresponding to these lengths (e.g., lengths 2, 4, 6, 8, 10, 12, and 14) can be defined. Once the UE knows the allocated length of the time-domain PUSCH symbol, the UE selects one of the OCC lookup tables corresponding to the L value from the SLIV, where an index, which can be explicitly configured via the DCI, will help select the corresponding OCC sequence from the lookup table.

[0079] In one implementation, when the DMRS carrier symbol is not OCC multiplexed with UL data, the UE selects a table from the allocated length via SLIV minus the DMRS carrier symbol for OCC applications. For example, if the indicated length via SLIV is L=8 and there are two DMRS carrier symbols ( If ), then the UE will select a length of 6 ( The OCC lookup table for ).

[0080] In one implementation, when there is no separate lookup table for each length, but instead a single OCC lookup table defining multiple OCC lengths and corresponding sequences is used, the UE then selects the row corresponding to the value of L, and the network can indicate in the DCI the index to be used to select the sequence from the row. For example, Table 1 illustrates a DFT-based OCC lookup table for PUSCH, where each row corresponds to an OCC code of one length, and each column defines different available sequences for that length. In this case, the UE can select the row corresponding to the value L in the SLIV, and the sequence value ( It can be configured via DCI.

[0081] Table 1: Orthogonal sequences used for PUSCH

[0082]

[0083] In one implementation, whenever the UE receives a new PDCCH carrying information about changes in resource allocation in the time domain (e.g., changes in the L value or index in SLIV), the UE will update the selection of the OCC lookup table or OCC sequence accordingly.

[0084] In one embodiment, when the length of the allocated time-domain symbol is greater than the length of the available OCC sequence, the UE can then be further instructed on which length codes will be used for which symbols. For example, an OCC can define / specify up to four length sequences; for instance, there are up to three lookup tables for OCCs of lengths 2, 3, and 4. However, the allocated length of the time-domain symbol may exceed the longest available sequence, for example, L > 4. In this case, the network may need to provide additional instructions on which length sequences need to be applied to which symbols in the time slot. For example, if the UE is instructed with an SLIV value where L = 6 and the maximum length of the available OCC sequence is 4, then the UE will need additional information about which code table will be applied along with the OCC sequence index.

[0085] In one implementation, a mapping table can be specified, defining different combinations of OCC lengths and their application order—for example, which length should be applied first. This table helps select the OCC lookup table according to the order in which specific codes are applied when the number of assigned symbols exceeds the available OCC lengths. For example, if OCC tables of lengths 2, 3, 4, 5, and 6 are available and the maximum number of symbols that can be assigned is 12, then the table can contain all possible combinations of lengths greater than 6 and up to a maximum of 12. An explanation of this table is provided in Table 2.

[0086] For example, if the allocated length is 7 and the maximum available OCC sequence length is 6, then index 1 or 2 is configured to the UE in the DCI for dynamic scheduling, or to the UE via RRC in the case of time-domain resource configuration scheduling. The UE will first select the OCC lookup table corresponding to the first length, for example, a 2-length OCC lookup table when index 1 is configured, and then select the next length (e.g., a 5-length lookup table). Indexes for selecting specific OCC sequences within these OCC length lookup tables can be configured individually.

[0087] Table 2: Mapping table examples when the OCC length is less than the allocation symbol

[0088]

[0089]

[0090] In one implementation, the index and length are indicated via RRC signaling, for example, in the PUSCH config IE, while DCI or MAC-CE is used to indicate whether the configuration values ​​are valid. If invalid, then DCI or MAC-CE signaling is used to rewrite those configuration values.

[0091] In one embodiment, when PUSCH time-domain resource allocation is performed via semi-persistent scheduling (SPS), the OCC sequence index can be explicitly indicated via RRC signaling or via DCI (in order to select a sequence from the OCC lookup table), while the OCC length can be implicitly indicated via RRC signaling (in order to select the OCC lookup table).

[0092] In one implementation, when configuring UL time resources to a UE using IE ConfiguredGrantConfig via RRC signaling of authorization type 1 or type 2, the network can additionally explicitly indicate the activation of OCC for PUSCH in the time domain, the selection of the OCC table (length), and the selection of OCC sequence 206 from the lookup table (index) within the same IE. For this purpose, new fields can be used to indicate these OCC parameters, as shown below. Figure 2B This describes an instance of the ConfiguredGrantConfig IE based on aspects of this disclosure.

[0093] In one implementation, the length of the OCC sequence can be implicitly indicated via an RRC message, for example, derived from the parameter "timeDomainAllocation" in IEConfiguredGrantConfig, where this parameter indicates a combination of the start symbol, length, and PUSCH mapping type. Once the UE knows the length of the allocated time domain symbol, the UE can use the same length to select an OCC lookup table, where other parameters, such as the index for selecting the sequence from the table, can be individually indicated by fields in the same IE.

[0094] In one implementation, when configuring resource allocation via authorization type 2, the OCC index and length can be configured via DCI, where the OCC index can be explicitly indicated by a field, while the OCC length can be implicitly indicated by the time-domain allocation symbol length.

[0095] According to the third embodiment, when UL transmissions are configured to be transmitted over multiple time slots, the network can provide implicit or explicit indications to apply time-domain OCC to PUSCH transmissions over multiple time slots. For example, if PUSCH transmissions are periodically configured for either configuration authorization type 1 or configuration authorization type 2 via an IEConfiguredGrantConfig with the field "Periodicity," utilizing the same allocation of time and frequency resources, then the network can be configured to use the same OCC index (i.e., the same OCC sequence) or to configure different OCC indices for each periodic interval.

[0096] For example, if multiple OCC indices are not configured and the UL transmission is configured periodically, the UE can use the same OCC sequence for all periodic intervals. The network can configure any new sequence at any time using the PDCCH. Alternatively, the network can configure different OCC indices for each periodic interval in the same configuration or select the next OCC index by referring to the first configured OCC index settings.

[0097] In one implementation, a relative index for the reference configuration index can be indicated in the configuration. The UE selects the next index by adding the relative index to the configuration index. For example, the UE receives the relative index of OCC index 2 302 and field 1 in IE ConfiguredGrantConfig. The UE selects the OCC sequence corresponding to index 2 302 and applies it to the first PUSCH transmission. During the next periodic PUSCH transmission, the UE selects the OCC sequence corresponding to index 3 304 because the relative index value is 1, such as... Figure 3 As explained in the text, Figure 3 This describes an example of a time-domain OCC configuration for multi-slot PUSCH transmission according to aspects of this disclosure. The UE continues to repeat this process until it receives a PDCCH or a new RRC configuration.

[0098] Figure 4 This section describes an example of OCC application with slot aggregation enabled according to aspects of this disclosure. According to a fourth embodiment, when a UL transmission is configured with repetition to increase PUSCH coverage via dynamic scheduling or configuration grant (i.e., repeating the same transport block (TB) across multiple slots), the same OCC index can be applied to all repetitions. For example, if the pusch-AggregationFactor in the PUSCH-Config IE for dynamic scheduling or the repK in the ConfiguredGrantConfig IE for configuration grant is used with a value greater than 1 for repetition and the UE is scheduled with one OCC index 402, then the UE will apply the same OCC sequence 404 to all repetitions, such as... Figure 4 As shown in the image, Figure 4 This describes an example of an OCC application that enables slotted aggregation with PUSCH - AggregationFactor = 4, according to aspects of this disclosure.

[0099] Figure 5An example of a UE 500 according to aspects of this disclosure is described. UE 500 may include a processor 502, a memory 504, a controller 506, and a transceiver 508. The processor 502, memory 504, controller 506, or transceiver 508, or various combinations thereof, or various components thereof, may be examples of components for performing the various aspects of this disclosure as described herein. These components may be coupled via one or more interfaces (e.g., operatively, communicatively, functionally, electronically, electrically).

[0100] Processor 502, memory 504, controller 506, or transceiver 508, or various combinations or components thereof, may be implemented in hardware (e.g., a circuit system). The hardware may be a processor, digital signal processor (DSP), application-specific integrated circuit (ASIC), or other programmable logic device, or any combination thereof configured to or otherwise support components for performing the functions described in this disclosure.

[0101] Processor 502 may include intelligent hardware devices (e.g., a general-purpose processor, DSP, CPU, ASIC, FPGA, or any combination thereof). In some embodiments, processor 502 may be configured to operate memory 504. In some other embodiments, memory 504 may be integrated into processor 502. Processor 502 may be configured to execute computer-readable instructions stored in memory 504 to cause UE 500 to perform various functions of this disclosure.

[0102] Memory 504 may comprise volatile or non-volatile memory. Memory 504 may store computer-readable, computer-executable code containing instructions that, when executed by processor 502, cause UE 500 to perform the various functions described herein. The code may be stored in a non-transitory computer-readable medium, such as memory 504 or another type of memory. Computer-readable medium includes both non-transitory computer storage media and communication media, wherein the communication media includes any media that facilitates the transfer of a computer program from one place to another. Non-transitory storage media may be any available media accessible by a general-purpose or special-purpose computer.

[0103] In some implementations, processor 502 and memory 504 coupled to processor 502 may be configured to cause UE 500 to perform one or more of the functions described herein (e.g., processor 502 executing instructions stored in memory 504). For example, processor 502 may support wireless communication at UE 500 according to examples disclosed herein.

[0104] UE 500 can be configured to support components for: receiving from a network entity a configuration comprising a set of time-domain orthogonal code sequences, each of the time-domain orthogonal code sequences comprising a sequence length different from the sequence length of the other time-domain orthogonal code sequences in the set; selecting at least one time-domain orthogonal code sequence from the set of time-domain orthogonal code sequences; multiplexing UL data associated with the UE according to the selected at least one time-domain orthogonal code sequence; and transmitting a waveform carrying the multiplexed UL data associated with the UE via a PUSCH.

[0105] In one embodiment, the UE 500 may be configured to support receiving components for selecting and applying at least one orthogonal code sequence from a plurality of time-domain orthogonal code sequences.

[0106] In one embodiment, the configuration includes the type of orthogonal code sequence to be applied. In one embodiment, the type of orthogonal code sequence to be applied includes a discrete Fourier transform type or a Walsh-Hadamard type.

[0107] In one embodiment, the application of orthogonal code sequences is performed in the time domain in response to enabling transform precoding.

[0108] In one embodiment, the UE 500 may be configured to support components that indicate to network entities its ability to apply orthogonal code sequences in the time domain for physical UL transmission.

[0109] In one embodiment, the UE 500 may be configured to support a component for receiving from a network entity at least one parameter for selecting at least one orthogonal code sequence.

[0110] In one embodiment, at least one parameter is indicated in the downlink control information format in response to the resource allocation for dynamically configured PUSCH transmission.

[0111] In one embodiment, at least one parameter includes the orthogonal code sequence length, which is indicated using a start and length indicator in the time domain.

[0112] In one embodiment, at least one parameter includes at least one symbol to be used based on the length of the orthogonal code sequence in response to the allocation of a time-domain symbol whose length is greater than the length of the orthogonal code sequence.

[0113] In one embodiment, at least one processor is configured to enable the UE to reference a lookup table for different combinations of orthogonal code sequence lengths and their application order.

[0114] In one embodiment, at least one parameter is indicated in the downlink control information format or radio resource control signaling in response to resource allocation for semi-persistent scheduling of PUSCH transmissions, and the orthogonal code sequence length is implicitly indicated via radio resource control signaling.

[0115] In one embodiment, at least one parameter is indicated via a configuration authorization information element through radio resource control signaling.

[0116] In one embodiment, at least one parameter includes the length of an orthogonal code sequence, which is implicitly provided via radio resource control signaling and indicated by a start symbol and length, as well as a physical UL transmit mapping type.

[0117] In one embodiment, in response to configuring resource allocation by configuring authorization type 2, the orthogonal code sequence length is implicitly indicated by the time-domain allocated symbol length.

[0118] In one embodiment, the UE 500 may be configured to support components for applying at least one orthogonal code sequence in the time domain to multiple time slots in response to a physical UL transmission configured to transmit on multiple time slots.

[0119] In one embodiment, the UE 500 may be configured to support a component for repeatedly applying at least one orthogonal code sequence in the time domain to each of the multiple time slots in response to a physical UL transmission configured to repeatedly transmit on multiple time slots.

[0120] In one embodiment, at least one orthogonal code sequence includes at least one orthogonal overlay code sequence. In one embodiment, an instruction to apply the orthogonal code sequence in the time domain is received via radio resource control signaling.

[0121] Controller 506 manages the input and output signals of UE 500. Controller 506 can also manage peripheral devices not integrated into UE 500. In some embodiments, controller 506 may utilize an operating system such as iOS®, ANDROID®, WINDOWS®, or other operating systems. In some embodiments, controller 506 may be implemented as part of processor 502.

[0122] In some embodiments, UE 500 may include at least one transceiver 508. In other embodiments, UE 500 may have more than one transceiver 508. Transceiver 508 may represent a wireless transceiver. Transceiver 508 may include one or more receiver chains 510, one or more transmitter chains 512, or a combination thereof.

[0123] Receiver chain 510 may be configured to receive signals (e.g., control information, data, packets) over a wireless medium. For example, receiver chain 510 may include one or more antennas for receiving signals over the air or over a wireless medium. Receiver chain 510 may include at least one amplifier (e.g., a low-noise amplifier (LNA)) configured to amplify the received signal. Receiver chain 510 may include at least one demodulator configured to demodulate the received signal and obtain the transmitted data by reversing the modulation technique applied during signal transmission. Receiver chain 510 may include at least one decoder for decoding and processing the demodulated signal to receive the transmitted data.

[0124] Transmitter chain 512 can be configured to generate and transmit signals (e.g., control information, data, packets). Transmitter chain 512 may include at least one modulator for modulating data onto a carrier signal, preparing the signal for transmission over a wireless medium. The at least one modulator may be configured to support one or more techniques, such as amplitude modulation (AM), frequency modulation (FM), or digital modulation schemes like phase shift keying (PSK) or quadrature amplitude modulation (QAM). Transmitter chain 512 may also include at least one power amplifier configured to amplify the modulated signal to an appropriate power level suitable for transmission over a wireless medium. Transmitter chain 512 may also include one or more antennas for transmitting the amplified signal into the air or wireless medium.

[0125] Figure 6 An example of a processor 600 according to aspects of this disclosure is described. Processor 600 may be an example of a processor configured to perform various operations according to the examples described herein. Processor 600 may include a controller 602 configured to perform various operations according to the examples described herein. Processor 600 may optionally include at least one memory 604, which may be, for example, an L1 / L2 / L3 cache. Additionally or alternatively, processor 600 may optionally include one or more arithmetic logic units (ALUs) 606. One or more of these components may be electronically communicated or otherwise coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more interfaces (e.g., buses).

[0126] Processor 600 may be a processor chipset and includes a protocol stack (e.g., a software stack) executed by the processor chipset to perform various operations (e.g., receive, acquire, retrieve, transmit, output, forward, store, determine, identify, access, write, read) according to the examples described herein. The processor chipset may include one or more cores, one or more caches (e.g., memory native to the processor chipset (e.g., processor 600) or contained within the processor chipset (e.g., processor 600)) or other memory (e.g., random access memory (RAM), read-only memory (ROM), dynamic RAM (DRAM), synchronous dynamic RAM (SDRAM), static RAM (SRAM), ferroelectric RAM (FeRAM), magnetic RAM (MRAM), resistive RAM (RRAM), flash memory, phase-change memory (PCM), and others).

[0127] Controller 602 can be configured to manage and coordinate various operations of processor 600 (e.g., signaling, receiving, acquiring, retrieving, transmitting, outputting, forwarding, storing, determining, identifying, accessing, writing, and reading) to enable processor 600 to support various operations according to the examples described herein. For example, controller 602 can operate as a control unit of processor 600, generating control signals that manage the operation of various components of processor 600. These control signals include enabling or disabling functional units, selecting data paths, initiating memory accesses, and coordinating operation timing.

[0128] Controller 602 may be configured to fetch (e.g., fetch, retrieve, receive) instructions from memory 604 and determine subsequent instructions to be executed to enable processor 600 to support various operations according to the examples described herein. Controller 602 may be configured to track the memory addresses of instructions associated with memory 604. Controller 602 may be configured to decode instructions to determine the operations to be performed and the operands involved. For example, controller 602 may be configured to interpret instructions and determine control signals to be output to other components of processor 600 to enable processor 600 to support various operations according to the examples described herein. Additionally or alternatively, controller 602 may be configured to manage data flow within processor 600. Controller 602 may be configured to control data transfers between registers, arithmetic logic unit (ALU), and other functional units of processor 600.

[0129] Memory 604 may include one or more caches (e.g., memory local to processor 600 or included in processor 600) or other memories, such as RAM, ROM, DRAM, SDRAM, SRAM, MRAM, flash memory, etc. In some embodiments, memory 604 may reside within or on the processor chipset (e.g., local to processor 600). In some other embodiments, memory 604 may reside outside the processor chipset (e.g., remote from processor 600).

[0130] Memory 604 may store computer-readable, computer-executable code containing instructions that, when executed by processor 600, cause processor 600 to perform the various functions described herein. The code may be stored in a non-transitory computer-readable medium, such as system memory or another type of memory. Controller 602 and / or processor 600 may be configured to execute computer-readable instructions stored in memory 604 to cause processor 600 to perform various functions. For example, processor 600 and / or controller 602 may be coupled to or coupled to memory 604, and processor 600, controller 602, and memory 604 may be configured to perform the various functions described herein. In some instances, processor 600 may include multiple processors, and memory 604 may include multiple memories. One or more of the multiple processors may be coupled to one or more of the multiple memories, which may be individually or collectively configured to perform the various functions described herein.

[0131] One or more ALUs 606 may be configured to support various operations according to the examples described herein. In some embodiments, one or more ALUs 606 may reside within or on a processor chipset (e.g., processor 600). In some other embodiments, one or more ALUs 606 may reside outside the processor chipset (e.g., processor 600). One or more ALUs 606 may perform one or more calculations on data, such as addition, subtraction, multiplication, and division. For example, one or more ALUs 606 may receive input operands and an opcode that determines the operation to be performed. One or more ALUs 606 may be configured with various logic and arithmetic circuitry, including adders, subtractors, shifters, and logic gates, to process and manipulate data according to the operation. Alternatively, one or more ALU 606s may support logical operations such as AND, OR, XOR, NOR, and NAND, enabling one or more ALU 606s to handle conditional operations, comparisons, and bitwise operations.

[0132] Processor 600 may support wireless communication according to examples disclosed herein. In one embodiment, processor 600 may be configured or operable to support components for: receiving from a network entity a configuration comprising a set of time-domain orthogonal code sequences, each of the set of time-domain orthogonal code sequences comprising a sequence length different from the sequence length of the other time-domain orthogonal code sequences in the set; selecting at least one time-domain orthogonal code sequence from the set of time-domain orthogonal code sequences; multiplexing UL data associated with the UE according to the selected at least one time-domain orthogonal code sequence; and transmitting a waveform carrying the multiplexed UL data associated with the UE via a PUSCH.

[0133] In one embodiment, the processor 600 may be configured or operable to support components for receiving configurations for selecting and applying at least one orthogonal code sequence from a plurality of time-domain orthogonal code sequences.

[0134] In one embodiment, the configuration includes the type of orthogonal code sequence to be applied. In one embodiment, the type of orthogonal code sequence to be applied includes a discrete Fourier transform type or a Walsh-Hadamard type.

[0135] In one embodiment, the application of orthogonal code sequences is performed in the time domain in response to enabling transform precoding.

[0136] In one embodiment, processor 600 may be configured or operable to support components that indicate to a network entity its ability to apply orthogonal code sequences in the time domain for physical UL transmission.

[0137] In one embodiment, processor 600 may be configured or operable to support components for receiving from a network entity at least one parameter for selecting at least one orthogonal code sequence.

[0138] In one embodiment, at least one parameter is indicated in the downlink control information format in response to the resource allocation for dynamically configured PUSCH transmission.

[0139] In one embodiment, at least one parameter includes the orthogonal code sequence length, which is indicated using a start and length indicator in the time domain.

[0140] In one embodiment, at least one parameter includes at least one symbol to be used based on the length of the orthogonal code sequence in response to the allocation of a time-domain symbol whose length is greater than the length of the orthogonal code sequence.

[0141] In one embodiment, at least one processor is configured to enable the UE to reference a lookup table for different combinations of orthogonal code sequence lengths and their application order.

[0142] In one embodiment, at least one parameter is indicated in the downlink control information format or radio resource control signaling in response to resource allocation for semi-persistent scheduling of PUSCH transmissions, and the orthogonal code sequence length is implicitly indicated via radio resource control signaling.

[0143] In one embodiment, at least one parameter is indicated via a configuration authorization information element through radio resource control signaling.

[0144] In one embodiment, at least one parameter includes the length of an orthogonal code sequence, which is implicitly provided via radio resource control signaling and indicated by a start symbol and length, as well as a physical UL transmit mapping type.

[0145] In one embodiment, in response to configuring resource allocation by configuring authorization type 2, the orthogonal code sequence length is implicitly indicated by the time-domain allocated symbol length.

[0146] In one embodiment, the processor 600 may be configured or operable to support components configured to apply at least one orthogonal code sequence in the time domain to multiple time slots in response to a physical UL emission.

[0147] In one embodiment, the processor 600 may be configured or operable to support components for repeatedly applying at least one orthogonal code sequence to each of the plurality of time slots in the time domain in response to a physical UL emission configured to repeatedly transmit on a plurality of time slots.

[0148] In one embodiment, at least one orthogonal code sequence includes at least one orthogonal overlay code sequence. In one embodiment, an instruction to apply the orthogonal code sequence in the time domain is received via radio resource control signaling.

[0149] Figure 7 An example of NE 700 according to aspects of this disclosure is described. NE 700 may include a processor 702, a memory 704, a controller 706, and a transceiver 708. The processor 702, memory 704, controller 706, or transceiver 708, or various combinations thereof, or various components thereof, may be examples of components for performing the various aspects of this disclosure as described herein. These components may be coupled via one or more interfaces (e.g., operatively, communicatively, functionally, electronically, electrically).

[0150] Processor 702, memory 704, controller 706, or transceiver 708, or various combinations or components thereof, may be implemented in hardware (e.g., a circuit system). The hardware may be a processor, digital signal processor (DSP), application-specific integrated circuit (ASIC), or other programmable logic device, or any combination thereof configured or otherwise supporting components for performing the functions described in this disclosure.

[0151] The NE 700 can be configured to support components for: transmitting to a UE an indication of applying an orthogonal code sequence in the time domain; receiving a PUSCH transmission having at least one selected orthogonal code sequence applied to a waveform in the time domain; and multiplexing the PUSCH transmissions of multiple UEs based on the orthogonal code sequence in the time domain.

[0152] Processor 702 may include intelligent hardware devices (e.g., a general-purpose processor, DSP, CPU, ASIC, FPGA, or any combination thereof). In some embodiments, processor 702 may be configured to operate memory 704. In some other embodiments, memory 704 may be integrated into processor 702. Processor 702 may be configured to execute computer-readable instructions stored in memory 704 to cause NE 700 to perform various functions of this disclosure.

[0153] Memory 704 may comprise volatile or non-volatile memory. Memory 704 may store computer-readable, computer-executable code containing instructions that, when executed by processor 702, cause NE 700 to perform the various functions described herein. The code may be stored in a non-transitory computer-readable medium, such as memory 704 or another type of memory. Computer-readable medium includes both non-transitory computer storage media and communication media, wherein the communication media includes any media that facilitates the transfer of a computer program from one place to another. Non-transitory storage media may be any available media accessible by a general-purpose or special-purpose computer.

[0154] In some implementations, processor 702 and memory 704 coupled to processor 702 may be configured to cause NE 700 to perform one or more of the functions described herein (e.g., processor 702 executes instructions stored in memory 704). For example, processor 702 may support wireless communication at NE 700 according to examples disclosed herein.

[0155] Controller 706 manages the input and output signals of NE 700. Controller 706 can also manage peripheral devices not integrated into NE 700. In some embodiments, controller 706 may utilize an operating system such as iOS®, ANDROID®, WINDOWS®, or other operating systems. In some embodiments, controller 706 may be implemented as part of processor 702.

[0156] In some embodiments, the NE 700 may include at least one transceiver 708. In other embodiments, the NE 700 may have more than one transceiver 708. The transceiver 708 may represent a wireless transceiver. The transceiver 708 may include one or more receiver chains 710, one or more transmitter chains 712, or a combination thereof.

[0157] Receiver chain 710 may be configured to receive signals (e.g., control information, data, packets) over a wireless medium. For example, receiver chain 710 may include one or more antennas for receiving signals over the air or over a wireless medium. Receiver chain 710 may include at least one amplifier (e.g., a low-noise amplifier (LNA)) configured to amplify the received signal. Receiver chain 710 may include at least one demodulator configured to demodulate the received signal and obtain the transmitted data by reversing the modulation technique applied during signal transmission. Receiver chain 710 may include at least one decoder for decoding and processing the demodulated signal to receive the transmitted data.

[0158] Transmitter chain 712 can be configured to generate and transmit signals (e.g., control information, data, packets). Transmitter chain 712 may include at least one modulator for modulating data onto a carrier signal, preparing the signal for transmission over a wireless medium. The at least one modulator may be configured to support one or more techniques, such as amplitude modulation (AM), frequency modulation (FM), or digital modulation schemes like phase shift keying (PSK) or quadrature amplitude modulation (QAM). Transmitter chain 712 may also include at least one power amplifier configured to amplify the modulated signal to an appropriate power level suitable for transmission over a wireless medium. Transmitter chain 712 may also include one or more antennas for transmitting the amplified signal into the air or wireless medium.

[0159] Figure 8 A flowchart illustrating a method according to an aspect of this disclosure is provided. The operation of the method can be implemented by a UE as described herein. In some embodiments, the UE can execute a set of instructions to control the functional elements of the UE to perform the described functions.

[0160] In 802, the method may receive a configuration comprising a set of time-domain orthogonal code sequences from a network entity. The operation of 802 may be performed according to examples as described herein. In some implementations, it may be provided by reference to... Figure 5 The described aspect of the UE performing the 802 operation.

[0161] In 804, the method may select at least one time-domain orthogonal code sequence from the set of time-domain orthogonal code sequences. The operation of 804 may be performed according to the examples described herein. In some embodiments, it may be performed by, as referenced... Figure 5 The described aspect of the UE performing the 804 operation.

[0162] In 806, the method can multiplex UL data associated with the UE based on at least one selected time-domain orthogonal code sequence. The operation of 806 can be performed according to examples as described herein. In some implementations, it can be performed by reference to... Figure 5 The described aspect of the UE performing 806 operations.

[0163] In 808, the method may transmit a waveform carrying multiplexed UL data associated with the UE via the PUSCH. Operation of 808 may be performed according to examples as described herein. In some implementations, it may be performed as referenced... Figure 5 The described aspect of the UE performing operation 808.

[0164] Figure 9 A flowchart illustrating a method according to an aspect of this disclosure is provided. The operation of the method can be implemented by an NE as described herein. In some embodiments, the NE can execute a set of instructions to control the functional elements of the NE to perform the described functions.

[0165] In 902, the method may transmit to the UE an indication of applying an orthogonal code sequence in the time domain. The operation of 902 may be performed according to the examples described herein. In some implementations, it may be performed by reference to... Figure 7 The described aspect of the NE performing operation 902.

[0166] In 904, the method may receive a PUSCH transmission having at least one selected orthogonal code sequence applied to the waveform in the time domain. The operation of 904 may be performed according to the examples described herein. In some embodiments, it may be performed by reference to... Figure 7 The described aspect of the NE performing operation 904.

[0167] In 906, the method can multiplex the PUSCH transmissions of multiple UEs based on orthogonal code sequences in the time domain. The operation of 906 can be performed according to the examples described herein. In some implementations, it can be achieved by referring to... Figure 7 The described aspect of the NE performing operation 906.

[0168] It should be noted that the methods described herein describe possible implementations, and the operations and steps may be rearranged or otherwise modified, and other implementations are possible.

[0169] The description herein is provided to enable those skilled in the art to make or use this disclosure. Various modifications to this disclosure will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other variations without departing from the scope of this disclosure. Therefore, this disclosure is not limited to the examples and designs described herein, but should be given the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A user equipment (UE) for wireless communication, comprising: At least one memory; and At least one processor, coupled to the at least one memory and configured to enable the UE to: Receive configuration from network entity including a set of time-domain orthogonal code sequences, each of the time-domain orthogonal code sequences in the set including a sequence length different from the sequence length of the other time-domain orthogonal code sequences in the set; Select at least one time-domain orthogonal code sequence from the set of time-domain orthogonal code sequences; The uplink UL data associated with the UE is multiplexed according to the at least one time-domain orthogonal code sequence; and The waveform carrying the multiplexed UL data associated with the UE is transmitted via the Physical UL Shared Channel (PUSCH).

2. The UE of claim 1, wherein the at least one processor is configured to enable the UE to receive configuration for selecting and applying the at least one time-domain orthogonal code sequence from the set of time-domain orthogonal code sequences.

3. The UE of claim 2, wherein the configuration includes the type of orthogonal code sequence to be applied, and wherein the type of orthogonal code sequence to be applied includes a discrete Fourier transform type or a Walsh-Hadamard type.

4. The UE of claim 1, wherein the application of an orthogonal code sequence is performed in the time domain in response to enabling transform precoding.

5. The UE of claim 1, wherein the at least one processor is configured to enable the UE to indicate one or more capabilities for supporting the application of orthogonal code sequences in the time domain for physical UL transmission.

6. The UE of claim 1, wherein the at least one processor is configured to cause the UE to receive from the network entity at least one parameter for selecting the at least one time-domain orthogonal code sequence.

7. The UE of claim 6, wherein the at least one parameter is indicated in the downlink control information format in response to dynamically configuring the resource allocation of the PUSCH.

8. The UE of claim 6, wherein the at least one parameter includes the orthogonal code sequence length, and the orthogonal code sequence length is indicated using a start and length indicator in the time domain.

9. The UE of claim 8, wherein the at least one parameter includes at least one symbol to be used based on the orthogonal code sequence length in response to the allocation of a time-domain symbol length greater than the orthogonal code sequence length.

10. The UE of claim 9, wherein the at least one processor is configured to make the UE refer to a lookup table of different combinations of orthogonal code sequence lengths and their application order, and wherein the at least one parameter is indicated in a downlink control information format or radio resource control signaling in response to resource allocation of the PUSCH in a semi-persistent scheduling manner, and the orthogonal code sequence length is implicitly indicated via radio resource control signaling.

11. The UE of claim 7, wherein the at least one parameter is indicated via a configuration authorization information element through radio resource control signaling.

12. The UE of claim 7, wherein the at least one parameter includes the length of an orthogonal code sequence implicitly provided via radio resource control signaling and indicated by a start symbol and length and a physical UL transmit mapping type.

13. The UE of claim 12, wherein in response to configuring the resource allocation by configuring authorization type 2, the length of the orthogonal code sequence is implicitly indicated by the time-domain allocation symbol length.

14. The UE of claim 1, wherein the at least one processor is configured to cause the UE to apply the at least one time-domain orthogonal code sequence to the plurality of time slots in response to a physical UL transmission configured to transmit on the plurality of time slots in the time domain.

15. The UE of claim 1, wherein the at least one processor is configured to cause the UE to apply the at least one time-domain orthogonal code sequence to each of the plurality of time slots in the time domain in response to a physical UL transmission configured to repeatedly transmit on a plurality of time slots.

16. A method performed by a user equipment (UE), the method comprising: Receive configuration from network entity including a set of time-domain orthogonal code sequences, each of the time-domain orthogonal code sequences in the set including a sequence length different from the sequence length of the other time-domain orthogonal code sequences in the set; Select at least one time-domain orthogonal code sequence from the set of time-domain orthogonal code sequences; Multiplexing uplink UL data associated with the UE according to the at least one time-domain orthogonal code sequence; and The waveform carrying the multiplexed UL data associated with the UE is transmitted via the Physical UL Shared Channel (PUSCH).

17. A network device NE for wireless communication, comprising: At least one memory; and At least one processor, coupled to the at least one memory and configured to enable the NE: Transmit an instruction to the user equipment (UE) to apply an orthogonal code sequence in the time domain; Receive a physical uplink UL shared channel (PUSCH) transmission having at least one selected orthogonal code sequence applied to the waveform in the time domain; and Multiplexing of PUSCH transmissions of multiple UEs is performed based on the orthogonal code sequence in the time domain.

18. The NE of claim 17, wherein the at least one processor is configured to transmit to the UE a configuration comprising a set of time-domain orthogonal code sequences, each of the time-domain orthogonal code sequences comprising a sequence length different from the sequence length of the other time-domain orthogonal code sequences in the set of time-domain orthogonal code sequences.

19. The NE of claim 18, wherein the at least one processor is configured to enable the NE to transmit a configuration for selecting and applying at least one orthogonal code sequence from the set of time-domain orthogonal code sequences.

20. A method performed by a network equipment (NE), the method comprising: Transmit an instruction to the user equipment (UE) to apply an orthogonal code sequence in the time domain; Receive a physical uplink UL shared channel (PUSCH) transmission having at least one selected orthogonal code sequence applied to the waveform in the time domain; and Multiplexing of PUSCH transmissions of multiple UEs is performed based on the orthogonal code sequence in the time domain.