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

Abstract

Various example embodiments relate to methods and apparatuses for enabling uplink control information (UCI) repetition transmission multiplexed on physical uplink shared channel (PUSCH). An apparatus may be configured to transmit uplink control information (UCI) multiplexed on a physical uplink shared channel (PUSCH) operated as an orthogonal cover code (OCC) manner, the uplink control information repeating across plural repetitions corresponding to the orthogonal cover code sequence.

Description

UPLINK CONTROL INFORMATION MULTIPLEXING ON PHYSICAL UPLINK SHARED CHANNEL WITH ORTHOGONAL COVER CODESTECHNICAL FIELD

[0001] Various example embodiments described herein generally relate to communication technologies, and more particularly, to methods and apparatuses for uplink control information (UCI) multiplexing on physical uplink shared channel (PUSCH) with orthogonal cover codes (OCC) .BACKGROUND

[0002] Orthogonal cover code (OCC) is a coding technique that can be used to enhance the multi-user multiplexing capability and throughput of a wireless communication network. By assigning orthogonal cover codes to different user equipment (UEs) , it may allow for simultaneous and interference-free transmission of these UEs’ data on the same time-frequency resources. For example, when the OCC is applied to the data on physical uplink shared channel (PUSCH) , it may enable multiplexing UEs on the same time-frequency resources, thereby increasing the resource efficiency.SUMMARY

[0003] A brief summary of exemplary embodiments is provided below to provide basic understanding of some aspects of various embodiments. It should be noted that this summary is not intended to identify key features of essential elements or define scopes of the embodiments, and its sole purpose is to introduce some concepts in a simplified form as a preamble for a 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 comprise at least one processor; and at least  one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to perform: transmitting, to a network device, uplink control information (UCI) multiplexed on a physical uplink shared channel (PUSCH) operated as an orthogonal cover code (OCC) manner, the uplink control information repeating across plural repetitions corresponding to the orthogonal cover code sequence.

[0005] In a second aspect, an example embodiment of an apparatus for a network device is provided. The apparatus may comprise at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to perform: receiving, from a terminal device, uplink control information (UCI) multiplexed on a physical uplink shared channel (PUSCH) operated as an orthogonal cover code (OCC) manner, the uplink control information repeating across plural repetitions corresponding to the orthogonal cover code sequence.

[0006] In a third aspect, an example embodiment of a method performed by an apparatus for a terminal device is provided. The method may comprise: transmitting, to a network device, uplink control information (UCI) multiplexed on a physical uplink shared channel (PUSCH) operated as an orthogonal cover code (OCC) manner, the uplink control information repeating across plural repetitions corresponding to the orthogonal cover code sequence.

[0007] In a fourth aspect, an example embodiment of a method performed by an apparatus for a network device is provided. The method may comprise: receiving, from a terminal device, uplink control information (UCI) multiplexed on a physical uplink shared channel (PUSCH) operated as an orthogonal cover code (OCC) manner, the uplink control information repeating across plural repetitions corresponding to the orthogonal cover code sequence.

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

[0009] In a sixth aspect, an example embodiment of an apparatus for a network  device is provided. The apparatus for the network device may comprise: 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 comprise program instructions that, when executed by an apparatus, cause the apparatus to at least perform 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 comprise program instructions that, when executed by an apparatus, cause the apparatus to at least perform the method of the third or fourth aspect.

[0012] Other features and advantages of the example embodiments of the present disclosure will also be apparent from the following description of specific embodiments when read in conjunction with the accompanying drawings, which illustrate, by way of example, the principles of example embodiments of the present disclosure.BRIEF DESCRIPTION OF THE DRAWINGS

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

[0014] Fig. 1 is a schematic diagram illustrating an example communication network in which example embodiments of the present disclosure may be implemented.

[0015] Fig. 2 is schematic diagram illustrating the signal transmission by applying orthogonal cover codes (OCC) .

[0016] Fig. 3 is a schematic diagram illustrating UCI repetition transmission multiplexed on PUSCH according to an example embodiment of the present disclosure.

[0017] Fig. 4A is a message flow diagram illustrating a process for enabling UCI repetition transmission multiplexed on PUSCH according to an example embodiment of the present disclosure.

[0018] Fig. 4B is a message flow diagram illustrating a process for indicating the OCC scheme according to an example embodiment of the present disclosure.

[0019] Fig. 4C is message flow diagram illustrating a process for indicating the scaling factor according to an example embodiment of the present disclosure.

[0020] Fig. 5 is a flowchart illustrating operations for enabling UCI repetition transmission multiplexed on PUSCH implemented at a terminal device according to an example embodiment of the present disclosure.

[0021] Fig. 6 is a flowchart illustrating operations for enabling UCI repetition transmission multiplexed on PUSCH implemented at a network device according to an example embodiment of the present disclosure.

[0022] Fig. 7 is a block diagram illustrating an apparatus in accordance with an example embodiment of the present disclosure.

[0023] Fig. 8 is a block diagram illustrating an apparatus in accordance with an example embodiment of the present disclosure.

[0024] Fig. 9 is a block diagram illustrating devices in a communication system in accordance with an example embodiment of the present disclosure.

[0025] Throughout the drawings, same or similar reference numbers indicate same or similar elements. A repetitive description on the same elements would be omitted.DETAILED DESCRIPTION

[0026] Herein below, some example embodiments are described in detail with reference to the accompanying drawings. The following description includes specific details for the purpose of providing a thorough understanding of various concepts. However, it will be apparent to those skilled in the art that these concepts may be practiced without these specific details. In some instances, well known circuits, techniques and components are shown in block diagram form to avoid obscuring the described concepts and features.

[0027] As used herein, the term “network device” may refer to a radio access network (RAN) device. The RAN device may include for example a base station  that can provide cells or coverage, through which terminal devices can access the network or receive services. The base station may be implemented as an evolved node B (eNB) , a next generation eNB (ng-eNB) , a next generation node B (gNB) , or a beyond 5G base station. The base station may be embodied as a macro base station, a relay node, or a low power node such as a pico base station or a femto base station. The base station may consist of several distributed network units, such as a central unit (CU) , one or more distributed units (DUs) , one or more remote radio heads (RRHs) or remote radio units (RRUs) . The number and functions of these distributed units depend on the selected split RAN architecture. The base station may be deployed on the ground or in the sky, for example on a satellite, a high altitude platform station, an unmanned aircraft system, a balloon, an airplane, and / or the like.

[0028] As used herein, the term “terminal device” or “user equipment” (UE) may refer to any entities or devices that can wirelessly communicate with the network devices or with each other. Examples of the terminal device can include a mobile phone, a mobile terminal (MT) , a mobile station (MS) , a subscriber station (SS) , a portable subscriber station (PSS) , an access terminal (AT) , a computer, a wearable device, an on-vehicle communication device, a machine type communication (MTC) device, a D2D communication device, a V2X communication device, a sensor and the like. The term “terminal device” can be used interchangeably with a UE, a user terminal, a mobile terminal, a mobile station, or a wireless device.

[0029] Fig. 1 is a schematic diagram illustrating an example communication network 100 in which example embodiments of the present disclosure may be implemented. The communication network 100 may form a part of a larger network e.g. a cellular communication network. Referring to Fig. 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 beyond 5G base station. The base station 120a may communicate with the UE 110 via downlink (DL) and uplink (UL) over a Uu interface. 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 physical downlink shared channel (PDSCH) , and / or physical downlink control channel (PDCCH) , and the uplink channel may include physical uplink shared channel (PUSCH) and / or physical uplink control channel (PUCCH) .

[0030] The communication network 100 may also be implemented as a non-terrestrial network (NTN) so as to enhance the coverage of network service. The NTN system may include one or more NTN nodes e.g., satellites 102 (one is shown in Fig. 1) . As shown, the satellite 102 may include a 5G New Radio (NR) base station 120b named gNB onboard, NR-Uu radio interface may be implemented on a service link between the satellite 102 and the UE 110, and N2 / N3 interface may be implemented on a feeder link between the satellite 102 and a gateway 130 on the ground. The gateway 130 may provide interconnections to terrestrial infrastructures including for example a base station 120a and / or a core network (not shown) . Alternatively, the satellite 102 may act as an analogue radio frequency repeater to relay communications between the UE 110 and the base station 120a on the ground (via the gateway 130) . For example, if the base station 120a is implemented as a 5G NR base station named gNB, the transparent satellite may simply repeat NR-Uu radio interface on the feeder link and the service link. Additionally, the satellites 102 may also communicate with each other via an inter satellite link (ISL) . With the satellites 102, the NTN 100 can extend network services to places without any terrestrial infrastructures.

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

[0032] In NTN systems, the UE 110 may operate in low signal quality conditions in terms of signal-noise-ratio (SNR) , since the resources and infrastructure are limited in remote area. In order to support more UEs in the NTN deployment, a feasible way is to apply orthogonal cover codes (OCC) to the transmission signal  (e.g., PUSCH) , so that the UEs can be multiplexed in the code domain. In this way, the same amount of bandwidth (e.g., 180 kHz corresponding to one PRB at a subcarrier spacing of 15 kHz) may be shared by plurality of UEs to transmit the PUSCH data. Thus, more UEs may be provided with network service, thereby increasing the total throughput of the system.

[0033] Fig. 2 illustrates the principle of applying OCC to the transmission signal. In this example, two UEs are transmitting two PUSCH repetitions in the same time-frequency resources denoted as 210, 220. For example, the first UE (UE1) applies a first OCC [+1 +1] , and the second UE (UE2) applies a second OCC [+1 -1] to their PUSCH data, respectively. These OCC may be, for example, a Discrete Fourier transform sequence or Walsh-Hadamard sequence. As shown in Fig. 2, x1 and x2 represent the signals transmitted by UE1 and UE2, respectively and in both repetitions, and y1 and y2 are the total signals received by the base station in the first and second repetition, respectively. For UE1, the signal x1 on the first resource may be multiplied by 1 and the signal x1 on the second resource may be multiplied by 1. For UE2, the signal x2 on the first resource may be multiplied by 1 and the signal x2 on the second resource may be multiplied by -1. This may allow the base station to receive the signals of each UE without the interference of other UE. It is to be noted that, in general in order to multiplex N UEs, a number of at least N signal repetitions per UE are necessary. In addition, the OCC may have any suitable length other than 2 in this example.

[0034] Although some aspects of the OCC are illustrated above in the context of NTN system, it shall be understood that the example embodiments are not, however, restricted to the system given as an example but a person skilled in the art may apply the solution to other communication systems, e.g., terrestrial communication system.

[0035] In addition to the data signals, the PUSCH may also carry the transmission of uplink control information (UCI) signals, e.g., channel state information (CSI) including CSI part1 and CSI part2, hybrid automatic repeat request (HARQ) acknowledgement  / non acknowledgement (ACK / NACK) . That is, the UCI signals  may be multiplexed on the PUSCH channel, for example, by rate matching and puncturing the PUSCH. However, according to 3GPP TS 38.212, UCI is only multiplexed on PUSCH in the configured slot (s) where an overlap between the PUCCH that would carry the UCI and the PUSCH occurs in case of repetition type A or transport block processing over multiple slots (TBoMS) . In other words, the UCI might not be transmitted in a repetition manner, in contrast to the PUSCH data. Further, according to 3GPP TS 38.331, a beta offset value is configured to adjust the robustness of the UCI, but this value might not be suitable for the UCI that is applied with OCC, and is multiplexed on PUSCH.

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

[0037] Example embodiments of the present disclosure provide solutions for this problem. The example embodiments allow a UE to apply the OCC to PUSCH repetitions with UCI multiplexing and maintain orthogonality among UEs using different OCC codes in the same resources. Thus, the performance of OCC operation can be guaranteed and the system performance can be enhanced. The example embodiments may be applied to terrestrial network (TN) or non-terrestrial network (NTN) .

[0038] Fig. 3 is a schematic diagram illustrating UCI repetition transmission multiplexed on PUSCH according to an example embodiment of the present disclosure. Referring to Fig. 3, the PUSCH may be operated as an OCC manner, and is applied with a length-L OCC. The length L may take a value of 2, 3, or any other integer number, for example. In addition to the resources allocated for the first transmission of PUSCH (i.e. PUSCH-1) , a UE may be provided with additional occasions or resources to transmit the same PUSCH, e.g., PUSCH-2 through PUSCH-L, where L corresponds to the length of OCC sequence. Herein, the first transmission and subsequent repetition (s) are all referred to as repetitions, and all or part of the repetitions are referred to as an OCC block.

[0039] As shown in Fig. 3, the UCI, to which the OCC is also applied, may be multiplexed on the PUSCH, and is repeatedly transmitted across all the repetitions  within the OCC block 310. Through this design, all the repeated resources within the OCC block carry exact same signal, so that the transmitted UCI along with the PUSCH data can be extracted properly through decoding operation at the base station side, without interference from other UEs. This enables multiple UEs assigned with different OCCs to use the same time-frequency resources to transmit their PUSCH multiplexed with UCI, thus leading to enhancement of the network capacity and throughput.

[0040] In some embodiment, the UCI repetition transmission in an OCC block occurs if the UCI multiplexing would occur (in case of PUSCH repetitions without OCC) in one or more slots of the OCC block that include the first slot of the OCC block.

[0041] In some embodiments, in case the OCC block length is smaller than the number of PUSCH repetitions, the UCI repetition transmission is refrained in the current OCC block and is postponed to a next OCC block if the UCI multiplexing would occur (in case of PUSCH repetitions without OCC) in one or more slots of the current OCC block that do not include the first slot of the current OCC block. Herein the current OCC block refers to the OCC block where the UCI multiplexing would occur in case of PUSCH repetitions without OCC.

[0042] In some embodiments, the UCI transmission and / or repetition transmission is dropped if the UCI multiplexing would occur (in case of PUSCH repetitions without OCC) in one or more slots of the current OCC block that do not include the first slot of the current OCC block and the current OCC block is a last OCC block within a set of PUSCH repetitions.

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

[0044] In some embodiments, the number of UCI resource (e.g. resource elements) on a PUSCH repetition may maintain the same as legacy method, e.g., specified in 3GPP TS 38.212. That is, the amount of resource for UCI (once considering the  UCI repetition) will be L times than the legacy case where UCI multiplexing on PUSCH is not operated as the OCC manner (hereinafter briefly referred to as “legacy case” ) .

[0045] This embodiment achieves the OCC gain at the cost of resource efficiency. For example, the amount of resource occupied by the UCI will be significantly increased especially when OCC length L is big, e.g., when L takes a value of 8. If the conventional beta offset is used directly to determine the resource of UCI for each repetition, which is then multiplied by the length L, it is too conservative and leads to consuming too many resources.

[0046] To this end, in some embodiments of the present disclosure, the UCI resource may scale down with a scaling factor on each repetition, so the excessive overhead due to UCI multiplexing on all repetitions within the OCC block can be alleviated, and the resource efficiency can thus be improved.

[0047] Fig. 4A is a message flow diagram illustrating a process for enabling UCI repetition transmission multiplexed on PUSCH in an efficient manner according to an example embodiment of the present disclosure. The process shown in Fig. 4A may be performed by a base station and a user equipment. For example, the UE 110 and the base station 120 in the TN / NTN network 100 described above with reference to Fig. 1 may be configured to perform the process of enabling UCI repetition transmission.

[0048] Referring to Fig. 4A, at an operation 410, the base station 120 may determine an OCC scheme and / or a scaling factor for UCI resource (hereinafter briefly referred to as “scaling factor” ) . In some embodiments, the OCC scheme may be selected from, e.g. intra-symbol OCC, inter-symbol OCC, inter-symbol cluster OCC, and inter-slot OCC.

[0049] In some embodiments, the scaling factor can be set as a fixed value, e.g.,  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 scales with the ratio M on each of the L repetitions, and the total amount of resources occupied by UCI for all  repetitions would be equal to legacy case.

[0050] In some embodiments, the scaling of resources may be greater than or equal to a lower threshold. For example, the scaling may be further subject to a lower bound or threshold in the number of resource elements (REs) allocated for UCI transmission. In this case, the UE 110 would limit the scaling of the UCI so that the final number of REs for UCI per repetition would be equal to or greater than the lower bound / threshold. In some embodiments, the UE 110 determines an actual scaling factor smaller than the configured (or nominal) scaling factor, so that when applying the actual scaling factor the final number of REs for UCI per repetition would be equal to or greater than the lower bound / threshold.

[0051] In some embodiments, the scaling factor may be determined by taking into account of the impairment for the UE 110. The impairment for the UE 110 may be, e.g., inter-UE interference due to multi-user multiplexing and non-ideal orthogonality that is caused by frequency offset (FO) , time offset (TO) , time drift, phase rotation, channel estimation, and power imbalance, and the like. Therefore, the amount of resource allocated for UCI normally cannot be the same in OCC block level as without applying OCC and resource multiplexing due to these impairments. In an example, the scaling factor may be greater than or equal to an inverse of a length of the orthogonal cover code sequence, and less than or equal to one. That is,  This can mitigate the impairment for the UE 110 and achieve the benefit of aligning the reliability with conventional method and leveraging the resource utilization efficiency.

[0052] In some embodiments, the scaling factor may be determined by several parameters, such as the OCC sequence length (hereinafter briefly referred to as “OCC length” ) , the impairment to single UE, and the channel quality in terms of a signal-to-noise-ratio (SNR) . In an example, the scaling factor for OCC applied UCI (ρocc) may be derived using following equations:

[0053] Where stands for the scaling factor, L is the OCC length, SNR is the signal-to-noise-ratio, η is SNR degradation for OCC due to the impairment that can be derived by link level simulation depending on the OCC scheme, and N is the number of samples associated with different SNR values.

[0054] For each sample, ρocc (SNR, L) can be derived by using equation (1) . Then,  can be derived by using either equation (2) or equation (3) . By this way, the scaling factor is derived to include both the overhead of repeating UCI across the L PUSCH repetitions and the impairments due to OCC application compared to a single UCI transmission without applying OCC, which is advantageous from the perspective of maintaining the same reliability as non-OCC case.

[0055] In an example, a same scaling factor may be used for HARQ-ACK, CSI part-1 and CSI part-2. In another example, different scaling factors may be derived independently for HARQ-ACK, CSI part-1 and CSI part-2.

[0056] In some embodiments, a multi-dimension table can be created for the determination of the scaling factor M. The table may be indexed by dimension (s) such as L, SNR, η as discussed above. In an example, multiple tables associated with different OCC length might be created, and a proper table can be selected according to the OCC length. In an example, a two-dimension table may be created by using index of the SNR (Y-axis) and OCC length (X-axis) . Each entry in the table is the scaling factor computed by using the above equation (1) . In an example, in order to simply the table, e.g., by decreasing the dimension, the SNR column might be removed, so that the table may be created based on an SNR independent algorithm, e.g., setting it equal to the inverse of the OCC length, i.e.  or using the above equations (2) or (3) .

[0057] In some embodiments, the scaling factor ρocc for OCC applied UCI may  be merged into legacy beta offset as defined in 3GPP TS 38.331. For example, a merged scaling factor can be calculated to be equal to the product of scaling factor for OCC and legacy beta offset, which can be denoted as:

[0058] In the above equation (4) , ρocc stands for the scaling factor, which can be calculated as or be derived from equations (1) - (3) , as described above. Parameter is the legacy beta offset of UCI, which may take the value of  and as defined in 3GPP TS 38.213.

[0059] In an example, the merged scaling factor might be extended into the specified table, e.g., table 9.3-1 and 9.3-2 as defined in 3GPP TS 38.213. By way of example, some entries with dedicated index and corresponding beta offset value may be filled in the reserved part of the table, as follows:

[0060] Table 1

[0061] In this implementation, a UL grant for scheduling PUSCH to which an OCC is applied can be used to indicate the merged scaling factor index.

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

[0063] In some embodiments, the base station 120 may semi-statically configure the OCC scheme for the UE 110, e.g., via a radio resource control (RRC) signaling. The OCC scheme may be applied till it is changed by RRC reconfiguration. In some embodiments, the base station 120 may configure the OCC scheme in a dynamic manner, e.g., via downlink control information (DCI) , or media access control element (MAC CE) .

[0064] For example, referring to Fig. 4B, which illustrates a message flow diagram of a process for indicating the OCC scheme. At an operation 422, the UE 110 may report, to the base station 120, capability of the UE 110 supporting at least one OCC scheme.

[0065] In an example, the capability information may include one or multiple OCC schemes that the UE 110 supports, e.g. intra-symbol with pre DFT, intra-symbol with post DFT, inter-symbol, inter-symbol cluster and inter-slot OCC. In an example, the UE 110 may report the capability information to the base station 120 in advance or in response to receiving a request from the base station 120.

[0066] Based on the capability information of the UE 110, as an option, the base station 120 may transmit, at an operation 424, a semi-static configuration of an OCC scheme for use at the UE 110. As another option, at an operation 426, the base station 120 may transmit, based on the capability information of the UE 110, a semi-static configuration of at least one OCC scheme that may be suitable for the UE 110. Then, at an operation 428, the base station 120 may transmit a dynamic configuration, e.g., by using DCI, indicating one of the OCC schemes for use at the UE 110.

[0067] Referring back to Fig. 4A, at an operation 430, the base station 120 may transmit an indication of the scaling factor to the UE 110. In an example, the indication may be transmitted by higher layers via radio resource control (RRC) signaling, or dynamically by downlink control information (DCI) , or media access control element (MAC CE) , or a combination thereof.

[0068] The scaling factor indication may indicate a value of the scaling factor, an index of the scaling factor, or a beta offset index. In an example, the scaling factor may be configured in RRC signaling independent to the OCC length. In another example, the scaling factor may be indicated in RRC signaling at least partly associated with the OCC length. In this case, the UE 110 may be able to choose the scaling factor according to the OCC length, which may have been semi-statically or dynamically indicated by the base station 120. Alternatively or additionally, the scaling factor may be indicated in the DCI by an index. The index may be indicated explicitly in the DCI, or be indicated implicitly, e.g., by correlated to the OCC length. In yet another example, the scaling factor may be indicated by an index and the OCC length jointly.

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

[0070] In some embodiments, the configuration of OCC scheme and the indication of the scaling factor may 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) .

[0071] For example, the RRC signaling carrying the configuration of OCC scheme and the indication of the scaling factor may include the following form:

[0072] In another example, the configuration of OCC scheme and scaling factor for OCC applied UCI may be indicated by a UL grant. An example representing the possible impact of downlink control information on the specification may be shown as follows.

[0073] Table 2

[0074] Receiving the indication of the scaling factor, the UE 110 may, at an operation 440 shown in Fig. 4A, determine resources for transmitting the UCI so that the number of resources can be scaled down by the indicated scaling factor than the number of resources for transmission of the UCI in case UCI multiplexing on PUSCH is not operated as the OCC manner.

[0075] In some embodiments, the indicated scaling factor (ρocc) may be applied to calculate the number of coded modulation symbols of UCI. As discussed above, the calculation may be made in an implicit or explicit mode, for which details are described below by taking the HARQ-ACK as an example. For the other UCI types, i.e. CSI part-1 and CSI part-2, the calculation methods are the same.

[0076] In an example, in case UCI multiplexing on PUSCH applying OCC, the number of coded modulation symbols per layer for HARQ-ACK transmission, denoted as Q′ACK, can be determined as follows:

[0077] In the above equation, OACK represents the number of HARQ-ACK bits, and LACK denotes the number of CRC bits.  which valve can be derived from the previously disclosed table 1 (index 0-20) . ρocc stands for the indicated scaling factor that is is the total number of OFDM symbols of the PUSCH,  is the number of resource elements that can be used for transmission of UCI in OFDM symbol l, CUL-SCH is the number of code blocks for a UL-SCH of the PUSCH transmission, Kr is the size of an r- th code block for the UL-SCH of the PUSCH transmission, and α is a parameter configured by higher layer signaling.

[0078] In another example, in case UCI multiplexing on PUSCH applying OCC, the number of coded modulation symbols per layer for HARQ-ACK transmission, denoted as Q′ACK, can be determined as follows:

[0079] The parameters OACK, LACK,  CUL-SCH, Kr, and α, in the above equation (6) are the same as those in equation (5) . For the parameter  which shall apply the new values in the reserved part of the table 1 (e.g., index 21-31) as previously disclosed.

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

[0081] According to example embodiments of the present disclosure, multiple UEs can multiplex their UCI on the PUSCH and repeats the UCI transmission across plural repetitions. As the UCI resource scales with a scaling factor on each repetition, a technical advantage provided by some example embodiments is that the resource efficiency can be improved, while the reliability can be maintained the same level as conventional case.

[0082] Fig. 5 shows a flowchart of an example method 500 for UCI repetition transmission multiplexed on PUSCH according to an example embodiment of the present disclosure. The method 500 can be implemented at a terminal device e.g. the UE 110 discussed above. It would be understood that step illustrated in dashed-line block represent an optional step and can be omitted in some example embodiments. In some example embodiments, the method 500 may further include  one or more steps that are performed at the UE 110 as described above with respect to Figs. 3-4. It would also be understood that details of some steps in the procedure 500 have been discussed above with respect to Figs. 3-4 and the procedure 500 will be described here in a simple manner.

[0083] At block 510, the terminal device may report to the network device, capability of the terminal device supporting at least one orthogonal cover code scheme.

[0084] At block 520, the terminal device may receive from the network device, configuration of an orthogonal cover code scheme for the terminal device.

[0085] In some example embodiments, the terminal device may receive the configuration of the orthogonal cover code scheme via radio resource control signaling, downlink control information, or media access control element. In some example embodiments, the terminal device may receive receiving a semi-static configuration of at least one orthogonal cover code scheme; and / or receiving a dynamic configuration indicating at least one orthogonal cover code scheme for use at the terminal device.

[0086] At block 530, the terminal device may receive from the network device, an indication of the scaling factor.

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

[0088] In some example embodiments, the scaling factor is indicated at least partly associated with a length of the orthogonal cover code sequence. In some example embodiments, the scaling factor is indicated by a beta offset index.

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

[0090] In some example embodiments, the terminal device may receive at least a semi-static configuration of a scaling factor for use at the terminal device.

[0091] At block 540, the terminal device may determine resources for transmitting the uplink control information in a way that the number of resources is scaled down by a scaling factor than the number of resources for transmission of the uplink control information in case UCI multiplexing on PUSCH is not operated as the orthogonal cover code manner.

[0092] In some example embodiments, the scaling factor is greater than or equal to an inverse of a length of the orthogonal cover code sequence, and less than or equal to one. In some example embodiments, the scaling factor is greater than or equal to a lower threshold.

[0093] At block 550, the terminal device may transmit to the network device, uplink control information (UCI) multiplexed on a physical uplink shared channel (PUSCH) operated as an orthogonal cover code (OCC) manner, the uplink control information repeating across plural repetitions corresponding to the orthogonal cover code sequence.

[0094] In some example embodiments, the repetitions are across-symbols, across-symbol clusters, across-slots, or intra-symbol (i.e. intra-symbol pre-DFTs and intra-symbol FD) repetitions.

[0095] Fig. 6 shows a flowchart of an example method 600 for UCI repetition transmission multiplexed on PUSCH according to an example embodiment of the present disclosure. The method 600 may be performed at a base station like the base station 120 discussed above. In some example embodiments, the method 600 may further include one or more steps that are performed at the base station 120 as described above with respect to Figs. 3-4. It would also be understood that details of some steps in the procedure 600 have been discussed above with respect to Figs. 3-4 and the procedure 600 will be described here in a simple manner.

[0096] At block 610, the network device may receive from a terminal device, capability of the terminal device supporting at least one orthogonal cover code scheme.

[0097] At block 620, the network device may transmit to the terminal device, configuration of an orthogonal cover code scheme for the terminal device.

[0098] In some example embodiments, the network device may transmit the configuration of the orthogonal cover code scheme via radio resource control signaling, downlink control information, or media access control element.

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

[0100] At block 630, the network device may transmit to the terminal device, an indication of the scaling factor.

[0101] In some example embodiments, the network device may transmit the indication of the scaling factor via radio resource control signaling, downlink control information, or media access control element.

[0102] In some example embodiments, the scaling factor is indicated at least partly associated with a length of the orthogonal cover code sequence. In some example embodiments, the scaling factor is indicated by a beta offset index.

[0103] 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 terminal device.

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

[0105] At block 640, the network device may receive from the terminal device, uplink control information (UCI) multiplexed on a physical uplink shared channel (PUSCH) operated as an orthogonal cover code (OCC) manner, the uplink control information repeating across plural repetitions corresponding to the orthogonal cover code sequence.

[0106] In some example embodiments, the repetitions are across-symbols, across-symbol clusters, across-slots, or intra-symbol (i.e. intra-symbol pre-DFTs and intra-symbol FD) repetitions.

[0107] In some example embodiments, the network device may receive the uplink  control information on a number of resources scaled down by a scaling factor than the number of resources for transmission of the uplink control information in case UCI multiplexing on PUSCH is not operated as the orthogonal cover code manner.

[0108] In some example embodiments, the scaling factor is greater than or equal to an inverse of a length of the orthogonal cover code sequence, and less than or equal to one. In some example embodiments, the scaling factor is greater than or equal to a lower threshold.

[0109] Fig. 7 is a block diagram illustrating an apparatus 700 according to an example embodiment of the present disclosure. The apparatus 700 may be implemented at a terminal device like the UE 110 to perform operations relating to the UE 110 as discussed above. Since the operations relating to the UE 110 have been discussed in detail with reference to Figs. 3-4, the blocks of the apparatus 700 will be described briefly here and details thereof may refer to the above description.

[0110] Referring to Fig. 7, the apparatus 700 may include a first means 710 for transmitting, to a network device, uplink control information (UCI) multiplexed on a physical uplink shared channel (PUSCH) operated as an orthogonal cover code (OCC) manner, the uplink control information repeating across plural repetitions corresponding to the orthogonal cover code sequence.

[0111] In some example embodiments, the apparatus 700 may further include a second means 720 for determining resources for transmitting the uplink control information in a way that the number of resources is scaled down by a scaling factor than the number of resources for transmission of the uplink control information in case UCI multiplexing on PUSCH is not operated as the orthogonal cover code manner.

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

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

[0114] In some example embodiments, the apparatus 1100 may further include a fifth means 750 for reporting, to the network device, capability of the terminal device supporting at least one orthogonal cover code scheme.

[0115] Fig. 8 is a block diagram illustrating an apparatus 800 according to an example embodiment of the present disclosure. The apparatus 800 may be implemented to comprise or to form at least part of the base station 120 discussed above to perform at least part of operations related to the base station 120. Since the operations related to the base station 120 have been discussed above with reference to Figs. 3-4, the blocks of the apparatus 800 will be described briefly here and details thereof may refer to the above description.

[0116] Referring to Fig. 8, the apparatus 800 may include a first means 810 for receiving, from a terminal device, uplink control information (UCI) multiplexed on a physical uplink shared channel (PUSCH) operated as an orthogonal cover code (OCC) manner, the uplink control information repeating across plural repetitions corresponding to the orthogonal cover code sequence.

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

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

[0119] In some example embodiments, the apparatus 800 may further include a fourth means 840 for receiving, from the terminal device, capability of the terminal device supporting at least one orthogonal cover code scheme.

[0120] Fig. 9 is a block diagram illustrating devices in a communication system 900 in accordance with an example embodiment of the present disclosure. As shown in Fig. 9, the communication system 900 may comprise a terminal device 910 which may be implemented as the UE 110 discussed above and a network device 920 which may be implemented as the base station 120 discussed above.

[0121] Referring to Fig. 9, the terminal device 910 may comprise one or more  processors 911, one or more memories 912 and one or more transceivers 913 interconnected through 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 series of lines on a motherboard or integrated circuit, fiber, optics or other optical communication equipment, and the like. Each of the one or more transceivers 913 may comprise a receiver and a transmitter, which are connected to one or more antennas 916. The terminal device 910 may wirelessly communicate with the radio access network device 920 through 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 the terminal device 910 to perform operations and procedures relating to the UE 110 as described above.

[0122] The network device 920 may comprise one or more processors 921, one or more memories 922, one or more transceivers 923 and one or more network interfaces 927 interconnected through 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, fiber, optics or other optical communication equipment, and the like. Each of the one or more transceivers 923 may comprise a receiver and a transmitter, which are connected to one or more antennas 926. The network device 920 may operate as a base station for the terminal device 910 and wirelessly communicate with terminal device 910 through the one or more antennas 926. The one or more network interfaces 927 may provide wired or wireless communication links through which the network device 920 may communicate with other network devices, entities, elements or functions. For example, the network device 920 may communicate with a core network device (not shown) via backhaul connections. The one or more memories 922 may include instructions 925 which, when executed by the one or more processors 921, may cause the network device 920 to perform operations and procedures relating to the base station 120.

[0123] The one or more processors 911, 921 discussed above may be of any appropriate type that is suitable for the local technical network, and may include  one or more of general purpose processors, special purpose processor, microprocessors, a digital signal processor (DSP) , one or more processors in a processor based multi-core processor architecture, as well as dedicated processors such as those developed based on Field Programmable Gate Array (FPGA) and Application Specific Integrated Circuit (ASIC) . The one or more processors 911, 921 may be configured to control other elements of the UE / radio access network device / core network device and operate in cooperation with them to implement the procedures discussed above.

[0124] The one or more memories 912, 922 may include at least one storage medium in various forms, such as a transitory memory and / or a non-transitory memory. The transitory memory may include, but not limited to, for example, a random access memory (RAM) or a cache. The non-transitory memory may include, but not limited to, for example, a read only memory (ROM) , a hard disk, a flash memory, and the like. The term “non-transitory, ” as used herein, is a limitation of the medium itself (i.e., tangible, not a signal) as opposed to a limitation on data storage persistency (e.g., RAM vs. ROM) . Further, the one or more memories 912, 922 may include but not limited to an electric, a magnetic, an optical, an electromagnetic, an infrared, or a semiconductor system, apparatus, or device or any combination of the above.

[0125] It would be understood that blocks in the drawings may be implemented in various manners, including software, hardware, firmware, or any combination thereof. In some embodiments, one or more blocks may be implemented using software and / or firmware, for example, machine-executable instructions stored in the storage medium. In addition to or instead of machine-executable instructions, parts or all of the blocks in the drawings may be implemented, at least in part, by one or more hardware logic components. For example, and without limitation, illustrative types of hardware logic components that can be used include Field-Programmable Gate Arrays (FPGAs) , Application-Specific Integrated Circuits (ASICs) , Application-Specific Standard Products (ASSPs) , System-on-Chip systems (SOCs) , Complex Programmable Logic Devices (CPLDs) , etc.

[0126] Some exemplary embodiments further provide program instruction or instructions which, when executed by one or more processors, may cause a device or apparatus to perform the procedures described above. The program instruction for carrying out procedures of the exemplary embodiments may be written in any combination of one or more programming languages. The program instruction may 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 the program instruction, when executed by the processor or controller, cause the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program instruction may execute entirely on a machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.

[0127] Some exemplary embodiments further provide a computer program product or a computer readable medium having the program instruction or instructions stored therein. The computer readable medium may be any tangible medium that may contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. The machine readable medium may be a machine readable signal medium or a machine readable storage medium. A machine readable medium may include but is not limited to an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the machine readable storage medium would include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM) , a read-only memory (ROM) , an erasable programmable read-only memory (EPROM or Flash memory) , an optical fiber, a portable compact disc read-only memory (CD-ROM) , an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0128] As used herein, “at least one of the following: <a list of two or more elements>” and “at least one of <a list of two or more elements>” and similar wording, where the list of two or more elements are joined by “and” or “or” , mean  at least any one of the elements, or at least any two or more of the elements, or at least all the elements.

[0129] Further, while operations are depicted in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Likewise, while several specific implementation details are contained in the above discussions, these should not be construed as limitations on the scope of the present disclosure, but rather as descriptions of features that may be specific to particular embodiments. Certain features that are described in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment may also be implemented in multiple embodiments separately or in any suitable sub-combination.

[0130] Although the subject matter has been described in a language that is specific to structural features and / or method actions, it is to be understood the subject matter defined in the appended claims is not limited to the specific features or actions described above. On the contrary, the above-described specific features and actions are disclosed as an example of implementing the claims.

[0131] Certain abbreviations that may be found in the description and / or in the figures are herewith defined as follows:

[0132] BS             base station

[0133] DCI            downlink control information

[0134] OCC            orthogonal cover codes

[0135] PRB            physical resource block

[0136] PUSCH          physical uplink shared channel

[0137] RRC            radio resource control

[0138] UCI            uplink control information

[0139] UE             user equipment

Claims

1.An apparatus for a terminal device, comprising:at least one processor; andat least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to perform:transmitting, to a network device, uplink control information (UCI) multiplexed on a physical uplink shared channel (PUSCH) operated as an orthogonal cover code (OCC) manner, the uplink control information repeating across plural repetitions corresponding to the orthogonal cover code sequence.2.The apparatus of claim 1, wherein the repetitions are across-symbols, across-symbol clusters, across-slots, or intra-symbol.3.The apparatus of claim 1 or 2, wherein the apparatus is configured to perform:determining resources for transmitting the uplink control information in a way that the number of resources is scaled down by a scaling factor than the number of resources for transmission of the uplink control information in case UCI multiplexing on PUSCH is not operated as the orthogonal cover code manner.4.The apparatus of claim 3, wherein the scaling factor is greater than or equal  to an inverse of a length of the orthogonal cover code sequence, and less than or equal to one.5.The apparatus of claim 4, wherein the scaling factor is greater than or equal to a lower threshold.6.The apparatus of claim 3, wherein the apparatus is configured to perform:receiving, from the network device, an indication of the scaling factor.7.The apparatus of claim 6, wherein the apparatus is configured to perform:receiving, from the network device, the indication of the scaling factor via radio resource control (RRC) signaling, downlink control information (DCI) , or media access (MAC) control element.8.The apparatus of claim 6, wherein the scaling factor is indicated at least partly associated with a length of the orthogonal cover code sequence.9.The apparatus of claim 6, wherein the scaling factor is indicated by a beta offset index.10.The apparatus of claim 6, wherein the apparatus is configured to perform:receiving at least a semi-static configuration of a scaling factor list; andreceiving at least a dynamic configuration indicating the scaling factor selected from the scaling factor list for use at the terminal device.11.The apparatus of claim 6, wherein the apparatus is configured to perform:receiving at least a semi-static configuration of a scaling factor for use at the terminal device.12.The apparatus of any of claims 1 to 11, wherein the apparatus is configured to perform:receiving, from the network device, configuration of an orthogonal cover code (OCC) scheme for the terminal device.13.The apparatus of claim 12, wherein the apparatus is configured to perform:receiving the configuration of the orthogonal cover code (OCC) scheme via radio resource control (RRC) signaling, downlink control information (DCI) , or media access (MAC) control element.14.The apparatus of claim 12, wherein the apparatus is configured to perform:receiving a semi-static configuration of at least one orthogonal cover code (OCC) scheme; and / orreceiving a dynamic configuration indicating at least one orthogonal cover code (OCC) scheme for use at the terminal device.15.The apparatus of any one of claims 1 to 14, wherein the apparatus is configured to perform:reporting, to the network device, capability of the terminal device supporting at least one orthogonal cover code (OCC) scheme.16.An apparatus for a network device, comprising:at least one processor; andat least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to perform:receiving, from a terminal device, uplink control information (UCI) multiplexed on a physical uplink shared channel (PUSCH) operated as an orthogonal cover code (OCC) manner, the uplink control information repeating across plural repetitions corresponding to the orthogonal cover code sequence.17.The apparatus of claim 16, wherein the repetitions are across-symbols, across-symbol clusters, across-slots, or intra-symbol repetitions.18.The apparatus of claim 16 or 17, wherein the apparatus is configured to perform:receiving the uplink control information on a number of resources scaled down by a scaling factor than the number of resources for transmission of the uplink control information in case UCI multiplexing on PUSCH is not operated as the orthogonal cover code manner.19.The apparatus of claim 18, wherein the scaling factor is greater than or equal to an inverse of a length of the orthogonal cover code sequence, and less than or equal to one.20.The apparatus of claim 19, wherein the scaling factor is greater than or equal to a lower threshold.21.The apparatus of claim 18, wherein the apparatus is configured to perform:transmitting, to the terminal device, an indication of the scaling factor.22.The apparatus of claim 21, wherein the apparatus is configured to perform:transmitting, to the terminal device, the indication of the scaling factor via radio resource control (RRC) signaling, downlink control information (DCI) , or media access (MAC) control element.23.The apparatus of claim 21, wherein the scaling factor is indicated at least partly associated with a length of the orthogonal cover code sequence.24.The apparatus of claim 21, wherein the scaling factor is indicated by a beta offset index.25.The apparatus of claim 21, wherein the apparatus is configured to perform:transmitting at least a semi-static configuration of a scaling factor list; andtransmitting at least a dynamic configuration indicating the scaling factor selected from the scaling factor list for use at the terminal device.26.The apparatus of claim 21, wherein the apparatus is configured to perform:transmitting at least a semi-static configuration of a scaling factor for use at the terminal device.27.The apparatus of any of claims 16 to 26, wherein the apparatus is configured to perform:transmitting, to the terminal device, configuration of an orthogonal cover code (OCC) scheme for the terminal device.28.The apparatus of claim 27, wherein the apparatus is configured to perform:transmitting the configuration of the orthogonal cover code (OCC) scheme via radio resource control (RRC) signaling, downlink control information (DCI) , or media access (MAC) control element.29.The apparatus of claim 27, wherein the apparatus is configured to perform:transmitting a semi-static configuration of at least one orthogonal cover code (OCC) scheme; and / ortransmitting a dynamic configuration indicating at least one orthogonal cover code (OCC) scheme for use at the terminal device.30.The apparatus of any one of claims 16 to 29, wherein the apparatus is configured to perform:receiving, from the terminal device, capability of the terminal device supporting at least one orthogonal cover code (OCC) scheme.31.A method performed by an apparatus for a terminal device, comprising:transmitting, to a network device, uplink control information (UCI) multiplexed on a physical uplink shared channel (PUSCH) operated as an orthogonal cover code (OCC) manner, the uplink control information repeating across plural repetitions corresponding to the orthogonal cover code sequence.32.The method of claim 31, wherein the repetitions are across-symbols, across-symbol clusters, across-slots, or intra-symbol repetitions.33.The method of claim 31 or 32, further comprising:determining resources for transmitting the uplink control information in a way that the number of resources is scaled down by a scaling factor than the number of resources for transmission of the uplink control information in case UCI multiplexing on PUSCH is not operated as the orthogonal cover code manner.34.The method of claim 33, wherein the scaling factor is greater than or equal to an inverse of a length of the orthogonal cover code sequence, and less than or equal to one.35.The method of claim 34, wherein the scaling factor is greater than or equal to a lower threshold.36.The method of claim 33, further comprising:receiving, from the network device, an indication of the scaling factor.37.The method of claim 36, further comprising:receiving, from the network device, the indication of the scaling factor via radio resource control (RRC) signaling, downlink control information (DCI) , or media access (MAC) control element.38.The method of claim 36, wherein the scaling factor is indicated at least partly associated with a length of the orthogonal cover code sequence.39.The method of claim 36, wherein the scaling factor is indicated by a beta offset index.40.The method of claim 36, further comprising:receiving at least a semi-static configuration of a scaling factor list; andreceiving at least a dynamic configuration indicating the scaling factor selected from the scaling factor list for use at the terminal device.41.The method of claim 36, further comprising:receiving at least a semi-static configuration of a scaling factor for use at the terminal device.42.The method of any of claims 31 to 41, further comprising:receiving, from the network device, configuration of an orthogonal cover code (OCC) scheme for the terminal device.43.The method of claim 42, further comprising:receiving the configuration of the orthogonal cover code (OCC) scheme via radio resource control (RRC) signaling, downlink control information (DCI) , or media access (MAC) control element.44.The method of claim 42, further comprising:receiving a semi-static configuration of at least one orthogonal cover code (OCC) scheme; and / orreceiving a dynamic configuration indicating at least one orthogonal cover code (OCC) scheme for use at the terminal device.45.The method of any one of claims 31 to 44, further comprising:reporting, to the network device, capability of the terminal device supporting at least one orthogonal cover code (OCC) scheme.46.A method performed by an apparatus for a network device, comprising:receiving, from a terminal device, uplink control information (UCI) multiplexed on a physical uplink shared channel (PUSCH) operated as an orthogonal cover code (OCC) manner, the uplink control information repeating across plural repetitions corresponding to the orthogonal cover code sequence.47.The method of claim 46, wherein the repetitions are across-symbols, across-symbol clusters, across-slots, or intra-symbol repetitions.48.The method of claim 46 or 47, further comprising:receiving the uplink control information on a number of resources scaled down by a scaling factor than the number of resources for transmission of the uplink control information in case UCI multiplexing on PUSCH is not operated as the orthogonal cover code manner.49.The method of claim 48, wherein the scaling factor is greater than or equal  to an inverse of a length of the orthogonal cover code sequence, and less than or equal to one.50.The method of claim 49, wherein the scaling factor is greater than or equal to a lower threshold.51.The method of claim 48, further comprising:transmitting, to the terminal device, an indication of the scaling factor.52.The method of claim 51, further comprising:transmitting, to the terminal device, the indication of the scaling factor via radio resource control (RRC) signaling, downlink control information (DCI) , or media access (MAC) control element.53.The method of claim 51, wherein the scaling factor is indicated at least partly associated with a length of the orthogonal cover code sequence.54.The method of claim 51, wherein the scaling factor is indicated by a beta offset index.55.The method of claim 51, further comprising:transmitting at least a semi-static configuration of a scaling factor list; andtransmitting at least a dynamic configuration indicating the scaling factor selected from the scaling factor list for use at the terminal device.56.The method of claim 51, further comprising:transmitting at least a semi-static configuration of a scaling factor for use at the terminal device.57.The method of any of claims 46 to 56, further comprising:transmitting, to the terminal device, configuration of an orthogonal cover code (OCC) scheme for the terminal device.58.The method of claim 57, further comprising:transmitting the configuration of the orthogonal cover code (OCC) scheme via radio resource control (RRC) signaling, downlink control information (DCI) , or media access (MAC) control element.59.The method of claim 57, further comprising:transmitting a semi-static configuration of at least one orthogonal cover code (OCC) scheme; and / ortransmitting a dynamic configuration indicating at least one orthogonal cover code (OCC) scheme for use at the terminal device.60.The method of any one of claims 46 to 59, further comprising:receiving, from the terminal device, capability of the terminal device supporting at least one orthogonal cover code (OCC) scheme.61.An apparatus for a terminal device, comprising means for performing the method of any of claims 31 to 45.62.An apparatus for a network device, comprising means for performing the method of any of claims 46 to 60.63.A computer readable medium comprising instructions which, when executed by an apparatus, cause the apparatus to at least perform the method of any of claims 31 to 60.64.A computer program product comprising instructions which, when executed by an apparatus, cause the apparatus to at least perform the method of any of claims 31 to 60.

Images