Uplink control information multiplexing on physical uplink shared channel with orthogonal cover codes

Abstract

Various example embodiments relate to methods and apparatus for uplink control information (UCI) repeat transmissions multiplexed on a physical uplink shared channel (PUSCH). For example, an apparatus may be configured to transmit multiplexed uplink control information (UCI) on a physical uplink shared channel (PUSCH) operating in an orthogonal cover code (OCC) manner, the uplink control information being repeated among a plurality of repetitions corresponding to an orthogonal cover code sequence.

Description

Uplink control information multiplexing on a physical uplink shared channel with orthogonal coverage codes Technical Field

[0001] The various example embodiments described herein relate generally to communication technologies, and more specifically, to methods and apparatus for multiplexing uplink control information (UCI) on a physical uplink shared channel (PUSCH) with orthogonal overlay codes (OCC). Background Technology

[0002] Orthogonal Cover Code (OCC) is a coding technique used to enhance the multi-user multiplexing capability and throughput of wireless communication networks. By assigning OCC to different User Equipments (UEs), it allows UE data to be transmitted simultaneously and without interference on the same time-frequency resources. For example, when OCC is applied to data on the Physical Uplink Shared Channel (PUSCH), it enables UE multiplexing on the same time-frequency resources, thereby improving resource efficiency. Summary of the Invention

[0003] The following provides a brief overview of exemplary embodiments to offer a basic understanding of some aspects of the various embodiments. It should be noted that the content of this invention is not intended to identify key features of essential elements or define the scope of the embodiments, and its sole purpose is to introduce some concepts in a simplified form as an introduction to the more detailed description provided below.

[0004] In a first aspect, an example embodiment of an apparatus for a terminal device is provided. The apparatus may include: at least one processor; and at least one memory storing instructions, which, when executed by the at least one processor, cause the apparatus to at least: transmit to a network device multiplexed uplink control information (UCI) on a Physical Uplink Shared Channel (PUSCH) operating in an orthogonal coverage code (OCC) manner, the uplink control information being repeated across a plurality of repetitions corresponding to the orthogonal coverage code sequence.

[0005] In a second aspect, an example embodiment of an apparatus for a network device is provided. The apparatus may include: at least one processor; and at least one memory storing instructions, which, when executed by the at least one processor, cause the apparatus to at least: receive uplink control information (UCI) multiplexed on a Physical Uplink Shared Channel (PUSCH) operating in an orthogonal coverage code (OCC) manner from a terminal device, the uplink control information being repeated across a plurality of repetitions corresponding to the orthogonal coverage code sequence.

[0006] Thirdly, an example embodiment of a method performed by a device of a terminal device is provided. The method may include: transmitting to a network device multiplexed uplink control information (UCI) on a Physical Uplink Shared Channel (PUSCH) operating in an orthogonal coverage code (OCC) manner, the uplink control information being repeated across multiple repetitions corresponding to the orthogonal coverage code sequence.

[0007] In a fourth aspect, an example embodiment of a method performed by means for a network device is provided. The method may include: receiving from a terminal device uplink control information (UCI) multiplexed on a Physical Uplink Shared Channel (PUSCH) operating in an orthogonal coverage code (OCC) manner, the uplink control information being repeated across a plurality of repetitions corresponding to the orthogonal coverage code sequence.

[0008] Fifthly, an example embodiment of a device for a terminal device is provided. The device for the terminal device may include: means for performing the method of the third aspect.

[0009] In a sixth aspect, an example embodiment of a device for a network device is provided. The device for the network device may include means for performing the method of the fourth aspect.

[0010] In a seventh aspect, an example embodiment of a computer-readable medium is provided. The computer-readable medium may include program instructions that, when executed by a device, cause the device to perform at least the method of the third or fourth aspect.

[0011] In an eighth aspect, an example embodiment of a computer program product is provided. The computer program product may include program instructions that, when executed by a device, cause the device to perform at least the method of the third or fourth aspect.

[0012] Other features and advantages of exemplary embodiments of this application will also become apparent from the following description of specific embodiments when read in conjunction with the accompanying drawings, which illustrate the principles of exemplary embodiments of this application by way of example. Attached Figure Description

[0013] Some exemplary embodiments will now be described by way of non-limiting examples with reference to the accompanying drawings.

[0014] Figure 1 is a schematic diagram illustrating an example communication network in which an example embodiment of this application can be implemented.

[0015] Figure 2 is a schematic diagram illustrating signal transmission using orthogonal cover code (OCC).

[0016] Figure 3 is a schematic diagram illustrating UCI retransmission multiplexed on PUSCH according to an example embodiment of this application.

[0017] Figure 4A is a message flow diagram illustrating a process for performing UCI retransmissions that can be multiplexed on a PUSCH, according to an example embodiment of this application.

[0018] Figure 4B is a message flow diagram illustrating a process for instructing an OCC scheme according to an example embodiment of this application.

[0019] Figure 4C is a message flow diagram illustrating a process for indicating a scaling factor according to an example embodiment of this application.

[0020] Figure 5 is a flowchart illustrating an example embodiment of the present application for enabling UCI retransmission multiplexed on a PUSCH implemented at the terminal device.

[0021] Figure 6 is a flowchart illustrating an example embodiment of the present application for enabling UCI retransmissions that are multiplexed on a PUSCH implemented at a network device.

[0022] Figure 7 is a block diagram illustrating an example embodiment of a device according to this application.

[0023] Figure 8 is a block diagram illustrating an example embodiment of a device according to this application.

[0024] Figure 9 is a block diagram illustrating a device in a communication system according to an example embodiment of this application.

[0025] Throughout the accompanying drawings, the same or similar reference numerals denote the same or similar elements. Repeated descriptions of the same elements will be omitted. Detailed Implementation

[0026] In the following description, some exemplary embodiments are described in detail with reference to the accompanying drawings. The description includes specific details intended to provide a thorough understanding of various concepts. However, it will be apparent to those skilled in the art that these concepts can be practiced without these specific details. In some instances, well-known circuits, technologies, and components are shown in block diagram form to avoid obscuring the described concepts and features.

[0027] As used herein, the term "network equipment" can refer to Radio Access Network (RAN) equipment. RAN equipment may include, for example, base stations that can provide cell or coverage areas, through which terminal equipment can access the network or receive services. Base stations can be implemented as evolved Node B (eNB), next-generation eNB (ng-eNB), next-generation Node B (gNB), or ultra-5G base stations. Base stations can be embodied as macro base stations, relay nodes, or low-power nodes such as pico or femtocells. Base stations can consist of several distributed network elements, such as a central unit (CU), one or more distributed units (DU), one or more remote radio heads (RRHs) or remote radio units (RRUs). The number and functionality of these distributed elements depend on the selected discrete RAN architecture. Base stations can be deployed on the ground or in the air, such as on satellites, high-altitude platform stations, unmanned aerial vehicle systems, balloons, aircraft, etc.

[0028] As used herein, the terms "terminal device" or "user equipment" (UE) can refer to any entity or device capable of wirelessly communicating with or with network devices or with each other. Examples of terminal devices may include mobile phones, mobile terminals (MT), mobile stations (MS), subscriber stations (SS), portable subscriber stations (PSS), access terminals (AT), computers, wearable devices, vehicular communication devices, machine-type communication (MTC) devices, D2D communication devices, V2X communication devices, sensors, etc. The term "terminal device" may be used interchangeably with UE, user terminal, mobile terminal, mobile station, or wireless device.

[0029] Figure 1 is a schematic diagram illustrating an example communication network 100 in which exemplary embodiments of this application may be implemented. The communication network 100 may form part of a larger network, such as a cellular communication network. Referring to Figure 1, the communication network 100 may include a UE 110 and a base station (BS) 120a. The base station 120a may be implemented as a 5G base station gNB, a Long Term Evolution (LTE) base station eNB, or a super 5G base station. The base station 120a may communicate with the UE 110 via a Uu interface through a downlink (DL) and an uplink (UL). In other examples, the base station 120a may implement other radio access technologies to communicate with the UE 110. As an example, the downlink channel may include a Physical Downlink Shared Channel (PDSCH) and / or a Physical Downlink Control Channel (PDCCH), and the uplink channel may include a Physical Uplink Shared Channel (PUSCH) and / or a Physical Uplink Control Channel (PUCCH).

[0030] The communication network 100 can also be implemented as a non-terrestrial network (NTN) to enhance network service coverage. The NTN system may include one or more NTN nodes, such as satellite 102 (one shown in Figure 1). As shown, satellite 102 may include a 5G New Radio (NR) base station 120b designated as an onboard gNB. An NR-Uu radio interface may be implemented on the serving link between satellite 102 and UE 110, and an N2 / N3 interface may be implemented on the feeder link between satellite 102 and a ground-based gateway 130. Gateway 130 may provide interconnection to ground infrastructure including, for example, base station 120a and / or a core network (not shown). Alternatively, satellite 102 may act as an analog radio repeater to relay communication between UE 110 and base station 120a on the ground (via gateway 130). For example, if base station 120a is implemented as a 5G NR base station designated as a gNB, the transparent satellite can simply forward the NR-Uu radio interface on the feeder link and the serving link. In addition, satellites 102 can also communicate with each other via inter-satellite links (ISL). Using satellites 102, NTN 100 can extend network services to areas without any terrestrial infrastructure.

[0031] As described above, in NTN 100, UE 110 can communicate with base station 120a deployed on the ground or base station 120b deployed on satellite 102. For ease of description, base station 120a and base station 120b can be collectively referred to as base station 120 or individually as base station 120.

[0032] In an NTN system, UE 110 can operate under low signal quality conditions in terms of signal-to-noise ratio (SNR) because resources and infrastructure are limited in remote areas. To support more UEs in an NTN deployment, a feasible approach is to apply orthogonal coverage codes (OCC) to the transmitted signals (e.g., PUSCH), allowing these UEs to multiplex them in the code domain. In this way, multiple UEs can share the same amount of bandwidth (e.g., 180 kHz for a PRB with a subcarrier spacing of 15 kHz) to transmit PUSCH data. Therefore, network services can be provided to more UEs, thereby increasing the overall system throughput.

[0033] Figure 2 illustrates the principle of applying OCC to transmitted signals. In this example, two UEs transmit two PUSCH repetitions in the same time-frequency resources, denoted as 210 and 220. For example, the first UE (UE1) applies a first OCC [+1 +1] to its PUSCH data, and the second UE (UE2) applies a second OCC [+1 -1] to its PUSCH data. These OCCs can be, for example, discrete Fourier transform sequences or Walsh-Hadamard sequences. As shown in Figure 2, x1 and x2 represent the signals transmitted by UE1 and UE2, respectively, and y1 and y2 are the total signals received by the base station in the first and second repetitions, respectively. For UE1, the signal x1 on the first resource can be multiplied by 1, and the signal x1 on the second resource can be multiplied by 1. For UE2, the signal x2 on the first resource can be multiplied by 1, and the signal x2 on the second resource can be multiplied by -1. This allows the base station to receive the signal of each UE without interference from the other UE. It should be noted that, generally speaking, in order to reuse N UEs, at least N signal repetitions for each UE are necessary. Additionally, in this example, the OCC can have any suitable length other than 2.

[0034] Although some aspects of OCC have been shown above in the context of the NTN system, it should be understood that the example embodiments are not limited to the system given as an example, but those skilled in the art can apply the solution to other communication systems, such as terrestrial communication systems.

[0035] In addition to data signals, PUSCH can also carry uplink control information (UCI) signals, such as Channel State Information (CSI) including CSI Part 1 and CSI Part 2, and Hybrid Automatic Repeat Request (HARQ) acknowledgment / non-acknowledgment (ACK / NACK). That is, UCI signaling can be multiplexed on the PUSCH channel, for example, through rate matching and puncturing of the PUSCH. However, according to 3GPP TS 38.212, UCI is only multiplexed on the PUSCH in configured time slots, where overlap between the PUSCH carrying UCI and the PUSCH occurs in repetition type A or in transport block processing over multiple time slots (TBoMS). In other words, unlike PUSCH data, UCI may not be transmitted in a repetitive manner. Furthermore, according to 3GPP TS 38.331, the β offset value is configured to adjust the robustness of UCI, but this value may not be suitable for UCI that has applied OCC and is multiplexed on the PUSCH.

[0036] Therefore, it is desirable to provide an efficient mechanism to extend the applicability of OCC to the case where UCI is reused on PUSCH.

[0037] The example embodiments of this application provide a solution to this problem. The example embodiments allow the UE to apply OCC to PUSCH repetition with UCI multiplexing and to maintain orthogonality between UEs using different OCC codes from the same resource. Therefore, the performance of OCC operation can be guaranteed, and system performance can be enhanced. The example embodiments can be applied to terrestrial networks (TN) or non-terrestrial networks (NTN).

[0038] Figure 3 is a schematic diagram illustrating a UCI repeat transmission multiplexed on a PUSCH according to an example embodiment of this application. Referring to Figure 3, the PUSCH can operate in OCC mode, and an OCC of length L is applied. For example, the length L can take the value 2, 3, or any other integer. In addition to the resources allocated for the first transmission of the PUSCH (i.e., PUSCH-1), additional opportunities or resources can be provided to the UE to transmit the same PUSCH, for example, PUSCH-2 to PUSCH-L, where L corresponds to the length of the OCC sequence. In this document, both the first transmission and subsequent repeats are referred to as repeats, and all or part of the repeats are referred to as OCC blocks.

[0039] As shown in Figure 3, the UCI used in the OCC can be multiplexed on the PUSCH and transmitted repeatedly across all repetitions within OCC block 310. This design ensures that all repetitive resources within the OCC block carry identical signals, allowing the transmitted UCI along with the PUSCH data to be correctly extracted by the base station's decoding operation without interference from other UEs. This enables multiple UEs allocated different OCCs to use the same time-frequency resources to transmit their UCI-multiplexed PUSCHs, resulting in enhanced network capacity and throughput.

[0040] In some embodiments, if UCI multiplexing will occur in one or more time slots of an OCC block that includes a first time slot of the OCC block (in the absence of PUSCH repetition of the OCC), then UCI repetition transmission in the OCC block occurs.

[0041] In some embodiments, when the OCC block length is less than the number of PUSCH repetitions, if UCI multiplexing will occur in one or more time slots of the first time slot excluding the current OCC block (in the case of no PUSCH repetitions of OCC), then UCI repetition transmission is avoided in the current OCC block, and the UCI repetition transmission is postponed to the next OCC block. In this document, the current OCC block refers to the OCC block in which UCI multiplexing will occur in the case of no PUSCH repetitions of OCC.

[0042] In some embodiments, if UCI multiplexing is to occur in one or more time slots of the first time slot of the current OCC block (excluding the current OCC block) (in the case of a PUSCH repetition without OCC) and the current OCC block is the last OCC block in a set of PUSCH repetitions, then the UCI transmission and / or the repetition transmission is discarded.

[0043] In some embodiments, OCC can be applied in the time domain, and the repetitions are across symbols, across symbol clusters, or across time slots. In some other embodiments, OCC can be applied within OFDM symbols, and these repetitions are within symbols.

[0044] In some embodiments, the number of UCI resources (e.g., resource elements) on a PUSCH repeat can be kept the same as in the conventional approach (e.g., the conventional approach specified in 3GPP TS 38.212). That is, the amount of UCI resources (once UCI repeats are taken into account) will be L times that of the conventional case where UCI multiplexing on a PUSCH is not operated as an OCC method (hereinafter referred to as the conventional case).

[0045] This embodiment achieves OCC gain at a resource-efficient cost. For example, when the OCC length L is large, such as when L is 8, the amount of resources occupied by UCI will increase significantly. This is different from the traditional beta offset. Directly using the resources to determine each repeating UCI and then multiplying it by the length L is too conservative and results in excessive resource consumption.

[0046] Therefore, in some embodiments of this application, UCI resources can be scaled down on each repetition by a scaling factor, thereby mitigating excessive overhead caused by UCI multiplexing on all repetitions within an OCC block and thus improving resource efficiency.

[0047] Figure 4A is a message flow diagram illustrating a process for efficiently performing UCI retransmissions multiplexed on the PUSCH according to an example embodiment of this application. The process shown in Figure 4A can be performed by a base station and a user equipment. For example, UE 110 and base station 120 in the TN / NTN network 100 described above with reference to FIG1 can be configured to perform a process capable of performing UCI retransmissions.

[0048] Referring to Figure 4A, at operation 410, base station 120 can determine the OCC scheme and / or the scaling factor (hereinafter referred to as "scaling factor") for UCI resources. In some embodiments, the OCC scheme can be selected from, for example, intra-symbol OCC, inter-symbol OCC, inter-symbol cluster OCC, and inter-slot OCC.

[0049] In some embodiments, the scaling factor can be set to a fixed value, for example... Where M represents the scaling factor and L is the OCC length, i.e., the length / size of the OCC block. In this way, UCI resource scaling is applied to each of the L repetitions by a ratio M, and the total amount of resources used by the UCI for all repetitions will be equal to that in the conventional case.

[0050] In some embodiments, resource scaling may be greater than or equal to a lower threshold. For example, scaling may further employ a lower limit or threshold in the number of resource elements (REs) allocated for UCI transmissions. In this case, UE 110 will limit the scaling of UCIs such that the final number of REs for each repeated UCI will be equal to or greater than the lower limit / threshold. In some embodiments, UE 110 determines an actual scaling factor that is less than the configured (or nominal) scaling factor, such that when the actual scaling factor is applied, the final number of REs for each repeated UCI will be equal to or greater than the lower limit / threshold.

[0051] In some embodiments, the scaling factor can be determined by taking into account the impairments of UE 110. Impairments of UE 110 can be, for example, inter-UE interference due to multi-user multiplexing and non-ideal orthogonality caused by frequency offset (FO), time offset (TO), time drift, phase rotation, channel estimation, and power imbalance. Therefore, due to these impairments, the amount of resources allocated for UCI at the OCC block level is generally not the same as the amount of resources without OCC and resource multiplexing. In one example, the scaling factor can be greater than or equal to the reciprocal of the length of the orthogonal coverage code sequence and less than or equal to 1. That is, This can mitigate the damage to UE 110 and realize the benefits of aligning reliability with conventional methods and leveraging resource utilization efficiency.

[0052] In some embodiments, the scaling factor can be determined by several parameters, such as the OCC sequence length (hereinafter referred to as OCC length), the impairment to a single UE, and the channel quality based on the signal-to-noise ratio (SNR). In an example, the scaling factor for UCI used in OCC applications can be derived using the following formula ( ):

[0053]

[0054]

[0055]

[0056] in, η represents the scaling factor, L is the OCC length, SNR is the signal-to-noise ratio, η is the SNR degradation of the OCC due to impairments that can be derived from link-level simulation depending on the OCC scheme, and N is the number of samples associated with different SNR values.

[0057] For each sample, it can be derived using equation (1). (SNR, L). Then, it can be derived by using equation (2) or equation (3). In this way, compared to a single UCI transmission without OCC application, the scaling factor... The overhead of repeated UCI across L PUSCHs and the impairment due to OCC application are both derived, which is advantageous from the perspective of maintaining the same reliability as in the non-OCC case.

[0058] In one example, the same scaling factor can be used for HARQ-ACK, CSI Part-1, and CSI Part-2. In another example, different scaling factors can be derived independently for HARQ-ACK, CSI Part-1, and CSI Part-2.

[0059] In some embodiments, a multidimensional table can be created to determine the scaling factor M. This table can be indexed by dimensions such as L, SNR, and η, as discussed above. In the example, multiple tables associated with different OCC lengths can be created, and an appropriate table can be selected based on the OCC length. In one example, a two-dimensional table can be created using an index of SNR (Y-axis) and the OCC length (X-axis). Each entry in the table is a scaling factor calculated using the formula (1) above. In one example, to simplify the table, for example, by reducing the dimensions, the SNR column can be removed, allowing the table to be created based on an SNR-independent algorithm, for example, by setting it to be equal to the reciprocal of the OCC length, i.e. Alternatively, use formula (2) or (3) above.

[0060] In some embodiments, the scaling factor of UCI for OCC applications can be... Merging into the traditional β offset as defined in 3GPP TS38.331 ( For example, merging scaling factors ( This can be calculated as the product of the scaling factor of OCC and the traditional β offset, which can be expressed as:

[0061]

[0062] In the above formula (4), Represents the scaling factor, which can be calculated as , or derived from equations (1)-(3), as described above. Parameters This is the traditional β offset of UCI, which can be taken as defined in 3GPP TS 38.213. , ,and The value of .

[0063] In the example, the merge scaling factor can be extended to a specified table, such as tables 9.3-1 and 9.3-2 as defined in 3GPP TS 38.213. As an example, some entries with dedicated indexes and corresponding β offset values ​​can be populated in the reserved portion of the table, as follows:

[0064] Table 1

[0065]

[0066] In this implementation, the UL authorization for scheduling PUSCH with OCC applied can be used to indicate the merged scaling factor index.

[0067] At operation 420, base station 120 may transmit the OCC scheme configuration to UE 110. For example, the OCC scheme may be selected from one of intra-symbol OCC, inter-symbol OCC, inter-symbol cluster OCC, and inter-slot OCC.

[0068] In some embodiments, base station 120 may semi-statically configure the OCC scheme of UE 110, for example, via Radio Resource Control (RRC) signaling. The OCC scheme may be applied until it is changed by reconfiguration via RRC. In some embodiments, base station 120 may dynamically configure the OCC scheme, for example, via Downlink Control Information (DCI) or Media Access Control Element (MACCE).

[0069] For example, referring to Figure 4B, a message flow diagram is shown for indicating the OCC scheme. At operation 422, UE 110 may report to base station 120 the ability of UE 110 to support at least one OCC scheme.

[0070] In the example, capability information may include one or more OCC schemes supported by UE 110, such as intra-symbol OCC with pre-DFT, intra-symbol OCC with post-DFT, inter-symbol OCC, inter-symbol cluster OCC, and inter-slot OCC. In the example, UE 110 may report capability information to base station 120 in advance, or in response to a request received from base station 120.

[0071] Based on the capability information of UE 110, as an option, base station 120 may transmit a semi-static configuration for the OCC scheme used at UE 110 at operation 424. Alternatively, at operation 426, base station 120 may transmit a semi-static configuration based on the capability information of UE 110, which can be applied to at least one OCC scheme for UE 110. Then, at operation 428, base station 120 may transmit a dynamic configuration, for example, using DCI, indicating one of the OCC schemes used at UE 110.

[0072] Referring back to Figure 4A, at operation 430, base station 120 may transmit an indication of the scaling factor to UE 110. In this example, the indication may be transmitted by a higher layer via Radio Resource Control (RRC) signaling or dynamically by Downlink Control Information (DCI) or Media Access Control Element (MAC CE) or a combination thereof.

[0073] The scaling factor indication can indicate the value of the scaling factor, an index of the scaling factor, or a β offset index. In one example, the scaling factor can be configured in RRC signaling independent of the OCC length. In another example, the scaling factor can be indicated in RRC signaling at least partially associated with the OCC length. In this case, UE 110 can be able to select the scaling factor based on the OCC length, which may have been semi-statically or dynamically indicated by base station 120. Alternatively or additionally, the scaling factor can be indicated in the DCI by an index. The index can be explicitly indicated in the DCI, or implicitly indicated, for example, by association with the OCC length. In yet another example, the scaling factor can be jointly indicated by the index and the OCC length.

[0074] Referring to Figure 4C, in one example, as an option, base station 120 may transmit a semi-static configuration of scaling factors for use at UE 110 at operation 432. In another example, as an option, base station 120 may transmit a semi-static configuration of a scaling factor list or table at operation 434. Then, at operation 436, base station 120 may, for example, transmit a dynamic configuration indicating the scaling factor selected from the scaling factor list or the table for use at UE 110 by using a two-bit indication.

[0075] In some embodiments, the configuration of the OCC scheme and the indication of the scaling factor can be transmitted via the same RRC and / or DCI signaling (as different information elements of the same message) or different RRC and / or DCI signaling (in different messages).

[0076] For example, RRC signaling carrying the configuration of the OCC scheme and the indication of the scaling factor can include the following forms:

[0077] PUSCH-Config ::= SEQUENCE {

[0078] occSchemeOnPUSCH SetupRelease { OCC-SchemeOnPUSCH} OPTIONAL, -- Required M

[0079] pusch-OccScalingFactors SetupRelease { PUSCH-OccScalingFactors}OPTIONAL, -- Required M

[0080] ……

[0081] }

[0082] OCC-SchemeOnPUSCH ::= CHOICE {

[0083] dynamic SEQUENCE (SIZE (1..4)) OF ENUMERATED {intraSymbolPreDFT, intraSymbolPostDFT, interSymbolCluster, interSlot},

[0084] semiStatic ENUMERATED { intraSymbolPreDFT,intraSymbolPostDFT, interSymbolCluster, interSlot}

[0085] } OPTIONAL, -- Required M

[0086] PUSCH-OccScalingFactors ::= CHOICE {

[0087] dynamic SEQUENCE (SIZE (1..4)) OF PUSCH-OccScalingFactorsList,

[0088] semiStatic OccScalingFactors

[0089] } OPTIONAL, -- Required M

[0090] PUSCH-OccScalingFactorsList ::= SEQUENCE (SIZE (1..4)) OFOccScalingFactors

[0091] OccScalingFactors ::=INTEGER(0..15) OPTIONAL, -- requires S

[0092] In another example, the configuration of the OCC scheme and the scaling factor for the OCC used to apply UCI can be indicated by UL authorization. An example illustrating the potential impact of downlink control information on the specification is shown below.

[0093] Table 2

[0094]

[0095] Upon receiving the scaling factor instruction, UE 110 can determine the resources for transmitting UCI at operation 440 as shown in FIG4A, such that the number of resources can be reduced by the indicated scaling factor compared to the number of resources for UCI transmission when UCI multiplexing on PUSCH is not operated as OCC mode.

[0096] In some embodiments, the indicated scaling factor may be applied ( The number of coded modulation symbols in the UCI is calculated using this method. As discussed above, the calculation can be performed in implicit or explicit mode, and will be described in detail below using HARQ-ACK as an example. The calculation method is the same for other UCI types, namely CSI Part-1 and CSI Part-2.

[0097] In the example, with UCI multiplexing on the PUSCH using OCC, the number of coded modulation symbols per layer used for HARQ-ACK transmission is expressed as: It can be determined as follows:

[0098]

[0099] In the above formula, Indicates the number of HARQ-ACK bits. Indicates the number of CRC bits. Its value can be derived from Table 1 (index 0-20) mentioned earlier. The specified scaling factor indicated, i.e. . It is the total number of OFDM symbols in PUSCH. It can be used for OFDM symbols The number of resource elements transmitted in UCI. It is the number of UL-SCH code blocks transmitted by PUSCH. It is the size of the r-th code block of the UL-SCH transmitted by PUSCH, and α is a parameter configured by higher-layer signaling.

[0100] In another example, with UCI multiplexing on the PUSCH using OCC, the number of coded modulation symbols per layer used for HARQ-ACK transmission is expressed as: It can be determined as follows:

[0101]

[0102] The parameters in equation (6) above , , , , , and Same as in equation (5). For the parameters... The new values ​​should be applied to the reserved portions of Table 1 (e.g., indices 21-31), as previously described.

[0103] Then, at operation 450, UE 110 can apply the OCC to the uplink transmission including the UCI multiplexed on the PUSCH and transmit the PUSCH to base station 120. In the following repeated uplink transmissions, UE 110 can apply the same OCC to each of the repeated uplink transmissions. Upon receiving an uplink transmission, base station 120 can receive and decode the UCI based on the OCC.

[0104] According to the example embodiments of this application, multiple UEs can reuse their UCIs on the PUSCH and repeat UCI transmissions across multiple repetitions. Since UCI resources are scaled by a scaling factor on each repetition, some example embodiments offer the technical advantage of improving resource efficiency while maintaining reliability at the same level as in normal circumstances.

[0105] Figure 5 illustrates a flowchart of an example method 500 for UCI retransmission multiplexed on a PUSCH according to an example embodiment of this application. Method 500 can be implemented at a terminal device such as UE 110 discussed above. It should be understood that the steps shown in the dashed boxes represent optional steps and may be omitted in some example embodiments. In some example embodiments, method 500 may also include one or more steps performed at UE 110 as described above with respect to Figures 3-4. It should also be understood that details of some steps in process 500 have been discussed above with respect to Figures 3-4, and process 500 will be described herein in a simplified manner.

[0106] At box 510, the terminal device can report to the network device its ability to support at least one orthogonal overlay code scheme.

[0107] At box 520, the terminal device can receive configuration for the orthogonal overlay code scheme for the terminal device from the network device.

[0108] In some example embodiments, the terminal device may receive the configuration of an orthogonal overlay code scheme via radio resource control signaling, downlink control information, or media access control elements. In some example embodiments, the terminal device may receive a semi-static configuration of at least one orthogonal overlay code scheme; and / or receive a dynamic configuration indicating at least one orthogonal overlay code scheme to be used at the terminal device.

[0109] At box 530, the terminal device can receive an indication of the scaling factor from the network device.

[0110] In some example embodiments, the terminal device may receive an indication of the scaling factor via radio resource control signaling, downlink control information, or media access control elements.

[0111] In some example embodiments, the scaling factor is indicated as being at least partially associated with the length of the orthogonal covering code sequence. In some example embodiments, the scaling factor is indicated by the β offset index.

[0112] In some example embodiments, the terminal device may receive at least a semi-static configuration of a scaling factor list; and at least a dynamic configuration indicating scaling factors selected from the scaling factor list for use at the terminal device.

[0113] In some example embodiments, the terminal device may receive at least a semi-static configuration for scaling factors used at the terminal device.

[0114] At box 540, the terminal device may determine the resources for transmitting uplink control information in such a way that the amount of these resources is reduced by a scaling factor compared to the case where the UCI multiplexing on the PUSCH is not operated as an orthogonal overlay code.

[0115] In some example embodiments, the scaling factor is greater than or equal to the reciprocal of the length of the orthogonal covering code sequence, and less than or equal to 1. In some example embodiments, the scaling factor is greater than or equal to a lower limit threshold.

[0116] At box 550, the terminal device may transmit uplink control information (UCI) multiplexed on the Physical Uplink Shared Channel (PUSCH) operating as an orthogonal cover code (OCC) to the network device, the uplink control information being repeated across multiple repetitions corresponding to the orthogonal cover code sequence.

[0117] In some example embodiments, these repetitions are cross-symbol, cross-symbol cluster, cross-slot, or intra-symbol (i.e., intra-symbol pre-DFT and intra-symbol FD) repetitions.

[0118] Figure 6 illustrates a flowchart of an example method 600 for UCI retransmission multiplexed on a PUSCH according to an example embodiment of this application. Method 600 can be performed at a base station similar to base station 120 discussed above. In some example embodiments, method 600 may also include one or more steps performed at base station 120, as described above with respect to Figures 3-4. It should also be understood that details of some steps in process 600 have been discussed above with respect to Figures 3-4, and process 600 will be described herein in a simplified manner.

[0119] At box 610, the network device can receive from the terminal device the capability of the terminal device to support at least one orthogonal overlay code scheme.

[0120] At box 620, the network device can transmit the configuration of the orthogonal overlay code scheme for the terminal device to the terminal device.

[0121] In some example embodiments, network devices may transmit the configuration of an orthogonal overlay code scheme via radio resource control signaling, downlink control information, or media access control elements.

[0122] In some example embodiments, the network device may transmit a semi-static configuration of at least one orthogonal overlay code scheme; and / or transmit a dynamic configuration indicating at least one orthogonal overlay code scheme for use at the terminal device.

[0123] At box 630, the network device can send an indication of the scaling factor to the end device.

[0124] In some example embodiments, network devices may transmit scaling factor indications via radio resource control signaling, downlink control information, or media access control elements.

[0125] In some example embodiments, the scaling factor is indicated as being at least partially associated with the length of the orthogonal covering code sequence. In some example embodiments, the scaling factor is indicated by the β offset index.

[0126] In some example embodiments, the network device may transmit at least a semi-static configuration of a scaling factor list; and transmit at least a dynamic configuration indicating the scaling factor selected from the scaling factor list for use at the end device.

[0127] In some example embodiments, the network device may transmit at least a semi-static configuration of the scaling factor for use at the end device.

[0128] At box 640, the network device can receive uplink control information (UCI) multiplexed on the Physical Uplink Shared Channel (PUSCH) operating as an orthogonal cover code (OCC) from the terminal device, the uplink control information being repeated across multiple repetitions corresponding to the orthogonal cover code sequence.

[0129] In some example embodiments, repetition is cross-symbol, cross-symbol cluster, cross-slot, or intra-symbol (i.e., intra-symbol pre-DFT and intra-symbol FD) repetition.

[0130] In some example embodiments, network devices can receive uplink control information on a scaled-down amount of resources compared to the amount of resources when UCI multiplexing on PUSCH is not operated in orthogonal overlay code mode.

[0131] In some example embodiments, the scaling factor is greater than or equal to the reciprocal of the length of the orthogonal covering code sequence, and less than or equal to 1. In some example embodiments, the scaling factor is greater than or equal to a lower limit threshold.

[0132] Figure 7 is a block diagram illustrating a device 700 according to an example embodiment of this application. Device 700 can be implemented at a terminal device similar to UE 110 to perform operations related to UE 110 as described above. Since the operations related to UE 110 have been discussed in detail with reference to Figures 3-4, the block diagram of device 700 will be briefly described here, and its details can be found in the above description.

[0133] Referring to FIG7, device 700 may include a first device 710 for transmitting uplink control information (UCI) multiplexed on a Physical Uplink Shared Channel (PUSCH) operating as an orthogonal cover code (OCC) to a network device, the uplink control information being repeated across multiple repetitions corresponding to an orthogonal cover code sequence.

[0134] In some example embodiments, device 700 may further include a second means 720 for determining the amount of resources for transmitting uplink control information in such a way that the amount of resources is reduced by a scaling factor compared to the case where UCI multiplexing on PUSCH is not operated in an orthogonal overlay code manner.

[0135] In some example embodiments, device 700 may also include a third means 730 for receiving an indication of a scaling factor from a network device.

[0136] In some example embodiments, device 700 may further include a fourth means 740 for receiving configuration of an orthogonal overlay code scheme for a terminal device from a network device.

[0137] In some example embodiments, device 1100 may further include a fifth means 750 for reporting to network devices the capability of terminal devices to support at least one orthogonal overlay code scheme.

[0138] Figure 8 is a block diagram illustrating a device 800 according to an example embodiment of this application. The device 800 may be implemented to include or form at least a portion of the base station 120 discussed above, to perform at least a portion of the operations associated with the base station 120. Since the operations associated with the base station 120 have been discussed above with reference to Figures 3-4, the block diagram of the device 800 will be briefly described herein, and its details can be found in the above description.

[0139] Referring to FIG8, device 800 may include a first device 810 for receiving uplink control information (UCI) multiplexed on a physical uplink shared channel (PUSCH) operating as an orthogonal cover code (OCC) from a terminal device, the uplink control information being repeated across multiple repetitions corresponding to an orthogonal cover code sequence.

[0140] In some example embodiments, device 800 may also include a second means 820 for transmitting an indication of a scaling factor to a terminal device.

[0141] In some example embodiments, device 800 may further include a third means 830 for transmitting to a terminal device a configuration of an orthogonal overlay code scheme for the terminal device.

[0142] In some example embodiments, device 800 may further include a fourth means 840 for receiving from a terminal device the capability of a terminal device to support at least one orthogonal overlay code scheme.

[0143] Figure 9 is a block diagram illustrating devices in a communication system 900 according to an example embodiment of this application. As shown in Figure 9, the communication system 900 may include a terminal device 910 and a network device 920. The terminal device 910 may be implemented as the UE 110 discussed above, and the network device 920 may be implemented as the base station 120 discussed above.

[0144] Referring to Figure 9, terminal device 910 may include one or more processors 911, one or more memories 912, and one or more transceivers 913 interconnected via one or more buses 914. The one or more buses 914 may be address, data, or control buses and may include any interconnection mechanism, such as a series of lines on a motherboard or integrated circuit, optical fibers, optics, or other optical communication devices. Each of the one or more transceivers 913 may include a receiver and a transmitter connected to one or more antennas 916. Terminal device 910 may wirelessly communicate with radio access network device 920 via the one or more antennas 916. The one or more memories 912 may include instructions 915, which, when executed by the one or more processors 911, may cause terminal device 910 to perform operations and procedures related to UE 110 as described above.

[0145] Network device 920 may include one or more processors 921, one or more memories 922, one or more transceivers 923, and one or more network interfaces 927 interconnected via one or more buses 924. The one or more buses 924 may be address, data, or control buses and may include any interconnection mechanism, such as a series of lines on a motherboard or integrated circuit, optical fibers, optics, or other optical communication devices. Each of the one or more transceivers 923 may include a receiver and a transmitter connected to one or more antennas 926. Network device 920 may operate as a base station for terminal device 910 and wirelessly communicate with terminal device 910 via one or more antennas 926. The one or more network interfaces 927 may provide a wired or wireless communication link through which network device 920 may communicate with other network devices, entities, components, or functions. For example, network device 920 may communicate with core network equipment (not shown) via a backhaul connection. The one or more memories 922 may include instructions 925, which, when executed by one or more processors 921, may cause network device 920 to perform operations and procedures related to base station 120.

[0146] The one or more processors 911, 921 discussed above can be any suitable type for the local technology network and can include one or more processors such as general-purpose processors, dedicated processors, microprocessors, digital signal processors (DSPs), processor-based multi-core processor architectures, and dedicated processors such as those developed based on field-programmable gate arrays (FPGAs) and application-specific integrated circuits (ASICs). The one or more processors 911, 921 can be configured to control and cooperate with other elements of the UE / radio access network equipment / core network equipment to perform the processes described above.

[0147] One or more memories 912, 922 may include at least one storage medium of various forms, such as transient and / or non-transient memories. Transient memories may include, but are not limited to, random access memory (RAM) or cache. Non-transient memories may include, but are not limited to, read-only memory (ROM), hard disks, flash memory, etc. The term “non-transient” as used herein refers to a limitation of the medium itself (i.e., tangible, not tactile), rather than a limitation of data storage persistence (e.g., RAM versus ROM). Furthermore, one or more memories 912, 922 may include, but are not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or apparatuses, or any combination thereof.

[0148] It should be understood that the blocks in the figures can be implemented in various ways, including software, hardware, firmware, or any combination thereof. In some embodiments, one or more blocks may be implemented using software and / or firmware (e.g., machine-executable instructions stored in a storage medium). In addition to or in lieu of machine-executable instructions, some or all of the blocks in the figures may be implemented at least partially by one or more hardware logic components. Examples, but not limited to, illustrative types of hardware logic components that may be used include Field-Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), Application-Specific Standard Products (ASSPs), Systems-on-Chip (SoCs), Complex Programmable Logic Devices (CPLDs), etc.

[0149] Some example embodiments also provide program instructions or directives that, when executed by one or more processors, cause a device or apparatus to perform the processes described above. The program instructions for performing the processes of the example embodiments can be written in any combination of one or more programming languages. The program instructions can be provided to one or more processors or controllers of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that, when executed by the processor or controller, the program instructions cause the functions / operations specified in the flowchart and / or the block diagram to be implemented. The program instructions can be executed entirely on the machine, partially on the machine, as a standalone software package, partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0150] Some example embodiments also provide a computer program product or a computer-readable medium having program instructions or directives stored therein. A computer-readable medium can be any tangible medium that may include or store a program used by or in connection with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. More specific examples of machine-readable storage media include electrical connections having one or more lines, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable optical disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0151] As used herein, “at least one of the following: ” and “at least one of ” and similar wording, wherein the list of two or more elements is connected by “and” or “or”, means at least any one element, or at least any two or more elements, or at least all elements.

[0152] Furthermore, although the operations are described in a specific order, this should not be construed as requiring that these operations must be performed in the specific or sequential order shown, or that all of the operations shown must be performed to achieve the desired result. In some cases, multitasking and parallel processing may be advantageous. Similarly, while some specific implementation details are included in the foregoing discussion, these should not be construed as limiting the scope of this application, but rather as descriptions of features specific to particular embodiments. Certain features described in the context of a single embodiment may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments.

[0153] Although the subject matter has been described in language specific to structural features and / or methodological actions, it should be understood that the subject matter defined in the appended claims is not limited to the specific features or actions described above. Rather, the specific features and actions described above are disclosed as examples of implementing the claims.

[0154] Some abbreviations that can be found in the specification and / or drawings are defined here as follows:

[0155] BS base station

[0156] DCI downlink control information

[0157] OCC Orthogonal Cover Code

[0158] PRB Physical Resource Block

[0159] PUSCH Physical Uplink Shared Channel

[0160] RRC Radio Resource Control

[0161] UCI uplink control information

[0162] UE User Equipment

Claims

1. An apparatus for a terminal device, comprising: At least one processor; The device also includes at least one memory storing instructions that, when executed by the at least one processor, cause the device to at least: transmit multiplexed uplink control information (UCI) to a network device on a Physical Uplink Shared Channel (PUSCH) operating in an orthogonal cover code (OCC) manner, the uplink control information being repeated across multiple repetitions corresponding to the orthogonal cover code sequence.

2. The apparatus of claim 1, wherein, The repetition is across symbols, across symbol clusters, across time slots, or within symbols.

3. The apparatus as claimed in claim 1 or 2, wherein, The device is configured to perform the following: determining the resources for transmitting the uplink control information in such a way that the number of resources is reduced by a scaling factor compared to the case where the UCI multiplexing on the PUSCH is not operated as the orthogonal overlay code mode.

4. The apparatus of claim 3, wherein, The scaling factor is greater than or equal to the reciprocal of the length of the orthogonal covering code sequence, and less than or equal to 1.

5. The apparatus of claim 4, wherein, The scaling factor is greater than or equal to the lower threshold.

6. The apparatus of claim 3, wherein, The device is configured to perform: receiving an instruction on the scaling factor from the network device.

7. The apparatus of claim 6, wherein, The device is configured to perform: receiving an indication of scaling factor from a network device via Radio Resource Control (RRC) signaling, Downlink Control Information (DCI) or Media Access (MAC) control elements.

8. The apparatus of claim 6, wherein, The scaling factor is indicated to be at least partially associated with the length of the orthogonal overlay code sequence.

9. The apparatus of claim 6, wherein, The scaling factor is indicated by the β offset index.

10. The apparatus of claim 6, wherein, The apparatus is configured to perform: a semi-static configuration of receiving at least a list of scaling factors; and a dynamic configuration of receiving at least a scaling factor selected from the list of scaling factors for use at a terminal device.

11. The apparatus of claim 6, wherein, The device is configured to perform: receiving at least a semi-static configuration of a scaling factor for use at the terminal device.

12. The apparatus according to any one of claims 1 to 11, wherein, The device is configured to perform: receiving configuration from the network device for an orthogonal overlay code (OCC) scheme for the terminal device.

13. The apparatus of claim 12, wherein, The device is configured to perform: receiving an orthogonal overlay code (OCC) scheme via radio resource control (RRC) signaling, downlink control information (DCI) or media access control elements.

14. The apparatus of claim 12, wherein, The device is configured to perform: receiving a semi-static configuration of at least one orthogonal cover code (OCC) scheme; and / or receiving a dynamic configuration indicating at least one orthogonal cover code (OCC) scheme for use at the terminal device.

15. The apparatus according to any one of claims 1 to 14, wherein, The device is configured to perform the following: report to the network device the capability of the terminal device to support at least one orthogonal overlay code (OCC) scheme.

16. An apparatus for a network device, comprising: At least one processor; The device also includes at least one memory storing instructions that, when executed by the at least one processor, cause the device to at least perform: receiving uplink control information (UCI) multiplexed on a Physical Uplink Shared Channel (PUSCH) operating in an orthogonal cover code (OCC) manner from a terminal device, the uplink control information being repeated across multiple repetitions corresponding to the orthogonal cover code sequence.

17. The apparatus of claim 16, wherein, The repetition is a repetition across symbols, across symbol clusters, across time slots, or within symbols.

18. The apparatus of claim 16 or 17, wherein, The device is configured to perform: receiving the uplink control information on a resource quantity reduced by a scaling factor, the resource quantity being reduced by a scaling factor compared to the resource quantity when the UCI multiplexing on the PUSCH is not operated in the orthogonal overlay code mode.

19. The apparatus of claim 18, wherein, The scaling factor is greater than or equal to the reciprocal of the length of the orthogonal covering code sequence, and less than or equal to 1.

20. The apparatus of claim 19, wherein, The scaling factor is greater than or equal to the lower threshold.

21. The apparatus of claim 18, wherein, The device is configured to perform: transmit an instruction for the scaling factor to the terminal device.

22. The apparatus of claim 21, wherein, The device is configured to perform the following: transmit an indication of the scaling factor to the terminal device via Radio Resource Control (RRC) signaling, Downlink Control Information (DCI) or Media Access Control (MAC) elements.

23. The apparatus of claim 21, wherein, The scaling factor is indicated to be at least partially associated with the length of the orthogonal overlay code sequence.

24. The apparatus of claim 21, wherein, The scaling factor is indicated by the β offset index.

25. The apparatus of claim 21, wherein, The device is configured to perform at least a semi-static configuration of the emission scaling factor list; And a transmission instruction for at least a dynamic configuration of the scaling factor selected from the scaling factor list for use at the terminal device.

26. The apparatus of claim 21, wherein, The device is configured to perform: transmitting at least a semi-static configuration of a scaling factor for use at the terminal device.

27. The apparatus as claimed in any one of claims 16 to 26, wherein, The device is configured to perform: transmitting to the terminal device the configuration of the orthogonal overlay code (OCC) scheme for the terminal device.

28. The apparatus of claim 27, wherein, The device is configured to perform: configuration of transmitting an orthogonal overlay code (OCC) scheme via radio resource control (RRC) signaling, downlink control information (DCI) or media access control (MAC) elements.

29. The apparatus of claim 27, wherein, The device is configured to perform: a semi-static configuration of transmitting at least one orthogonal cover code (OCC) scheme; and / or a dynamic configuration of transmitting instructions for using at least one orthogonal cover code (OCC) scheme at the terminal device.

30. The apparatus according to any one of claims 16 to 29, wherein, The device is configured to perform: receiving from the terminal device the capability of the terminal device to support at least one orthogonal overlay code (OCC) scheme.

31. A method performed by a device of a terminal equipment, comprising: Multiplexed uplink control information (UCI) is transmitted to network devices on a Physical Uplink Shared Channel (PUSCH) operating in orthogonal cover code (OCC) mode, the uplink control information being repeated across multiple repetitions corresponding to the orthogonal cover code sequence.

32. The method of claim 31, wherein, The repetition is a repetition across symbols, across symbol clusters, across time slots, or within symbols.

33. The method of claim 31 or 32, further comprising: The resources used to transmit the uplink control information are determined as follows: the number of resources is reduced by a scaling factor compared to the case where the UCI multiplexing on the PUSCH is not operated as the orthogonal overlay code mode.

34. The method of claim 33, wherein, The scaling factor is greater than or equal to the reciprocal of the length of the orthogonal covering code sequence, and less than or equal to 1.

35. The method of claim 34, wherein, The scaling factor is greater than or equal to the lower threshold.

36. The method of claim 33, further comprising: Receive an indication of the scaling factor from the network device.

37. The method of claim 36, further comprising: Instructions for scaling factors are received from network devices via Radio Resource Control (RRC) signaling, Downlink Control Information (DCI) or Media Access (MAC) control elements.

38. The method of claim 36, wherein, The scaling factor is indicated to be at least partially associated with the length of the orthogonal overlay code sequence.

39. The method of claim 36, wherein, The scaling factor is indicated by the β offset index.

40. The method of claim 36, further comprising: A semi-static configuration that receives at least a list of scaling factors; And receive at least a dynamic configuration of the scaling factor selected from the scaling factor list for use at the terminal device.

41. The method of claim 36, further comprising: Receive at least a semi-static configuration of the scaling factor for use at the terminal device.

42. The method according to any one of claims 31 to 41, further comprising: Receive configuration from the network device for the orthogonal overlay code (OCC) scheme for the terminal device.

43. The method of claim 42, further comprising: Configuration for receiving orthogonal overlay code (OCC) schemes via Radio Resource Control (RRC) signaling, Downlink Control Information (DCI) or Media Access Control (MAC) elements.

44. The method of claim 42, further comprising: Receive a semi-static configuration of at least one orthogonal cover code (OCC) scheme; And / or receive instructions for the dynamic configuration of at least one orthogonal overlay code (OCC) scheme to be used at the terminal device.

45. The method of any one of claims 31 to 44, further comprising: The terminal device is reported to the network device for its ability to support at least one orthogonal overlay code (OCC) scheme.

46. ​​A method performed by a means of a network device, comprising: The terminal device receives uplink control information (UCI) multiplexed on a Physical Uplink Shared Channel (PUSCH) operating in orthogonal cover code (OCC) mode, the uplink control information being repeated across multiple repetitions corresponding to the orthogonal cover code sequence.

47. The method of claim 46, wherein, The repetition is a repetition across symbols, across symbol clusters, across time slots, or within symbols.

48. The method of claim 46 or 47, further comprising: The uplink control information is received on a resource quantity reduced by a scaling factor, which is the same as the resource quantity when the UCI multiplexing on the PUSCH is not operated in the orthogonal overlay code mode.

49. The method of claim 48, wherein, The scaling factor is greater than or equal to the reciprocal of the length of the orthogonal covering code sequence, and less than or equal to 1.

50. The method of claim 49, wherein, The scaling factor is greater than or equal to the lower threshold.

51. The method of claim 48, further comprising: The scaling factor instruction is transmitted to the terminal device.

52. The method of claim 51, further comprising: Instructions for the scaling factor are transmitted to the terminal device via Radio Resource Control (RRC) signaling, Downlink Control Information (DCI), or Media Access Control (MAC) elements.

53. The method of claim 51, wherein, The scaling factor is indicated to be at least partially associated with the length of the orthogonal overlay code sequence.

54. The method of claim 51, wherein, The scaling factor is indicated by the β offset index.

55. The method of claim 51, further comprising: At least a semi-static configuration of the emission scaling factor list; And a transmission instruction for at least a dynamic configuration of the scaling factor selected from the scaling factor list for use at the terminal device.

56. The method of claim 51, further comprising: Transmit at least a semi-static configuration of the scaling factor used at the terminal device.

57. The method of any one of claims 46 to 56, further comprising: The configuration of the orthogonal overlay code (OCC) scheme for the terminal device is transmitted to the terminal device.

58. The method of claim 57, further comprising: Configuration of transmitting orthogonal coverage code (OCC) schemes via radio resource control (RRC) signaling, downlink control information (DCI) or media access control (MAC) elements.

59. The method of claim 57, further comprising: Semi-static configuration for transmitting at least one orthogonal cover code (OCC) scheme; And / or transmit instructions for the dynamic configuration of at least one orthogonal overlay code (OCC) scheme used at the terminal device.

60. The method of any one of claims 46 to 59, further comprising: The terminal device has the capability to receive information from the terminal device that supports at least one orthogonal overlay code (OCC) scheme.

61. An apparatus for a terminal device, comprising means for performing the method of any one of claims 31 to 45.

62. An apparatus for a network device, comprising means for performing the method of any one of claims 46 to 60.

63. A computer-readable medium comprising instructions that, when executed by a device, cause the device to perform at least the method as claimed in any one of claims 31 to 60.

64. A computer program product comprising instructions that, when executed by a device, cause the device to perform at least the method as claimed in any one of claims 31 to 60.

Images