Devices, methods, and medium for communication

Abstract

Example embodiments of the present disclosure relate to devices, methods, and computer storage medium for communication. In the solution, a terminal device may encode the UCI with uplink data on PUSCH together to generate encoded code words, and further transmit the PUSCH based on OCC-based PUSCH configuration. As such, the UCI can be multiplexed with PUSCH, and the UCI and the uplink data can be jointly encoded. Therefore, PUSCH coverage performance and orthogonal property of PUSCH can be guaranteed.

Description

DEVICES, METHODS, AND MEDIUM FOR COMMUNICATIONFIELD

[0001] Example embodiments of the present disclosure generally relate to the field of communication techniques and in particular, to devices, methods, and a computer readable medium for communication.BACKGROUND

[0002] In the 3rd Generation Partnership Project (3GPP) release 19 (Rel-19) new radio (NR) non-terrestrial network (NTN) , when discussing different orthogonal cover code (OCC) schemes for physical uplink shared channel (PUSCH) , it is proposed to consider some aspects which include impacts on the uplink control information (UCI) multiplexing on PUSCH.SUMMARY

[0003] In general, example embodiments of the present disclosure provide devices, methods, and a computer storage medium for communication.

[0004] In a first aspect, there is provided a terminal device. The terminal device comprises at least one processor configured to cause the terminal device at least to: in accordance with a determination that a UCI needs to be multiplexed on a PUSCH with uplink data and OCC parameters are configured, encode the UCI with the uplink data together to generate encoded code words; and transmit, to a network device, the PUSCH comprising the encoded code words based on an OCC-based PUSCH configuration.

[0005] In a second aspect, there is provided a terminal device. The terminal device comprises at least one processor configured to cause the terminal device at least to: in accordance with a determination that a UCI needs to be multiplexed on a PUSCH with uplink data and OCC parameters are configured, determine an OCC unit based on an actual time domain window (TDW) , an OCC length, and a length of a PUSCH repetition; multiplex the UCI with the uplink data for a plurality of PUSCH repetitions within the OCC unit; and transmit, to a network device, the PUSCH comprising multiplexed UCI and uplink data based on an OCC-based PUSCH configuration.

[0006] In a third aspect, there is provided a network device. The network device  comprises at least one processor configured to cause the network device at least to: receive, from a terminal device, a PUSCH comprising encoded code words based on an OCC-based PUSCH configuration; and decode the encoded code words to obtain UCI and uplink data which are encoded together.

[0007] In a fourth aspect, there is provided a network device. The network device comprises at least one processor configured to cause the network device at least to: receive, from a terminal device, a PUSCH comprising multiplexed UCI and uplink data based on an OCC-based PUSCH configuration; and decode the PUSCH to obtain the UCI and the uplink data which are multiplexed for a plurality of PUSCH repetitions within an OCC unit, wherein the OCC unit is determined based on: an actual TDW, an OCC length, and a length of a PUSCH repetition.

[0008] In a fifth aspect, there is provided a method of communication. The method comprises: in accordance with a determination that a UCI needs to be multiplexed on a PUSCH with uplink data and OCC parameters are configured, encoding, at a terminal device, the UCI with the uplink data together to generate encoded code words; and transmitting, to a network device, the PUSCH comprising the encoded code words based on an OCC-based PUSCH configuration.

[0009] In a sixth aspect, there is provided a method of communication. The method comprises: in accordance with a determination that a UCI needs to be multiplexed on a PUSCH with uplink data and OCC parameters are configured, determining, at a terminal device, an OCC unit based on an actual TDW, an OCC length, and a length of a PUSCH repetition; multiplexing the UCI with the uplink data for a plurality of PUSCH repetitions within the OCC unit; and transmitting, to a network device, the PUSCH comprising multiplexed UCI and uplink data based on an OCC-based PUSCH configuration.

[0010] In a seventh aspect, there is provided a method of communication. The method comprises: receiving, at a network device from a terminal device, a PUSCH comprising encoded code words based on an OCC-based PUSCH configuration; and decoding the encoded code words to obtain UCI and uplink data which are encoded together.

[0011] In an eighth aspect, there is provided a method of communication. The method comprises: receiving, at a network device from a terminal device, a PUSCH comprising multiplexed UCI and uplink data based on an OCC-based PUSCH configuration; and decoding the PUSCH to obtain the UCI and the uplink data which are multiplexed for a  plurality of PUSCH repetitions within an OCC unit, wherein the OCC unit is determined based on: an actual TDW, an OCC length, and a length of a PUSCH repetition.

[0012] In a ninth aspect, there is provided a computer readable medium having instructions stored thereon, the instructions, when executed on at least one processor, causing the at least one processor to carry out the method according to any of the fifth to the eighth aspects above.

[0013] It is to be understood that the summary section is not intended to identify key or essential features of embodiments of the present disclosure, nor is it intended to be used to limit the scope of the present disclosure. Other features of the present disclosure will become easily comprehensible through the following description.BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Through the more detailed description of some example embodiments of the present disclosure in the accompanying drawings, the above and other objects, features and advantages of the present disclosure will become more apparent, wherein:

[0015] FIG. 1A illustrates an example communication network in which some embodiments of the present disclosure can be implemented;

[0016] FIG. 1B illustrates an NTN typical scenario based on transparent payload;

[0017] FIG. 1C illustrates an NTN typical scenario based on regenerative payload;

[0018] FIG. 1D illustrates a comparison of some CDMs with a no-CDM scheme;

[0019] FIG. 2 illustrates a signalling chart illustrating communication process in accordance with some embodiments of the present disclosure;

[0020] FIGS. 3A-3B illustrate example schematics of joint channel coding in accordance with some embodiments of the present disclosure;

[0021] FIG. 4 illustrates a signalling chart illustrating communication process in accordance with some embodiments of the present disclosure;

[0022] FIG. 5A illustrates an example schematic of mirrored mapping with an OCC length 2 in accordance with some embodiments of the present disclosure;

[0023] FIG. 5B illustrates an example schematic of mirrored mapping with an OCC length 4 in accordance with some embodiments of the present disclosure;

[0024] FIG. 6 illustrates a flowchart of an example method implemented at a terminal  device in accordance with some embodiments of the present disclosure;

[0025] FIG. 7 illustrates a flowchart of an example method implemented at a terminal device in accordance with some embodiments of the present disclosure;

[0026] FIG. 8 illustrates a flowchart of an example method implemented at a network device in accordance with some embodiments of the present disclosure;

[0027] FIG. 9 illustrates a flowchart of an example method implemented at a network device in accordance with some embodiments of the present disclosure; and

[0028] FIG. 10 illustrates a simplified block diagram of a device that is suitable for implementing embodiments of the present disclosure.

[0029] Throughout the drawings, the same or similar reference numerals represent the same or similar element.DETAILED DESCRIPTION

[0030] Principle of the present disclosure will now be described with reference to some example embodiments. It is to be understood that these embodiments are described only for the purpose of illustration and help those skilled in the art to understand and implement the present disclosure, without suggesting any limitation as to the scope of the disclosure. Embodiments described herein can be implemented in various manners other than the ones described below.

[0031] In the following description and claims, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skills in the art to which this disclosure belongs.

[0032] References in the present disclosure to “one embodiment, ” “an embodiment, ” “an example embodiment, ” and the like indicate that the embodiment described may include a particular feature, structure, or characteristic, but it is not necessary that every embodiment includes the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

[0033] It shall be understood that although the terms “first” and “second” etc. may be used  herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first element could be termed a second element, and similarly, a second element could be termed a first element, without departing from the scope of example embodiments. As used herein, the term “and / or” includes any and all combinations of one or more of the listed terms.

[0034] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of example embodiments. As used herein, the singular forms “a” , “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” , “comprising” , “has” , “having” , “includes” and / or “including” , when used herein, specify the presence of stated features, elements, and / or components etc., but do not preclude the presence or addition of one or more other features, elements, components and / or combinations thereof.

[0035] In some examples, values, procedures, or apparatus are referred to as “best, ” “lowest, ” “highest, ” “minimum, ” “maximum, ” or the like. It will be appreciated that such descriptions are intended to indicate that a selection among many used functional alternatives can be made, and such selections need not be better, smaller, higher, or otherwise preferable to other selections.

[0036] As used herein, the term “communication network” refers to a network following any suitable communication standards or technologies, such as New Radio (NR) , Long Term Evolution (LTE) , LTE-Advanced (LTE-A) , Code Divided Multiple Address (CDMA) , Frequency Divided Multiple Address (FDMA) , Time Divided Multiple Address (TDMA) , Frequency Divided Duplexer (FDD) , Time Divided Duplexer (TDD) , Multiple-Input Multiple-Output (MIMO) , Orthogonal Frequency Divided Multiple Access (OFDMA) , cdma2000, Wideband Code Division Multiple Access (WCDMA) , High-Speed Packet Access (HSPA) , Global System for Mobile Communications (GSM) , Narrow Band Internet of Things (NB-IoT) and so on. Furthermore, the communications between a terminal device and a network device in the communication network may be performed according to any suitable generation communication protocols, including, but not limited to, the first generation (1G) , the second generation (2G) , 2.5G, 2.75G, the third generation (3G) , the fourth generation (4G) , 4.5G, the fifth generation (5G) , 5.5G, 5G-Advanced networks, beyond 5G (B5G) , the sixth generation (6G) communication protocols, wireless local network communication protocols such as Institute for Electrical and Electronics Engineers  (IEEE) 802.11 and the like, and / or any other protocols either currently known or to be developed in the future. The techniques described herein may be used for the wireless networks and radio technologies mentioned above as well as other wireless networks and radio technologies. Embodiments of the present disclosure may be applied in various communication systems. Given the rapid development in communications, there will of course also be future type communication technologies and systems with which the present disclosure may be embodied. It should not be seen as limiting the scope of the present disclosure to only the aforementioned system.

[0037] As used herein, the term “terminal device” refers to any device having wireless or wired communication capabilities. Examples of terminal device include, but not limited to, user equipment (UE) , personal computers, desktops, mobile phones, cellular phones, smart phones, personal digital assistants (PDAs) , portable computers, tablets, wearable devices, internet of things (IoT) devices, Ultra-reliable and Low Latency Communications (URLLC) devices, Internet of Everything (IoE) devices, machine type communication (MTC) devices, device on vehicle for V2X communication where X means pedestrian, vehicle, or infrastructure / network, devices for Integrated Access and Backhaul (IAB) , Space borne vehicles or Air borne vehicles in Non-terrestrial networks (NTN) including Satellites and High Altitude Platforms (HAPs) encompassing Unmanned Aircraft Systems (UAS) , eXtended Reality (XR) devices including different types of realities such as Augmented Reality (AR) , Mixed Reality and Virtual Reality (VR) , the unmanned aerial vehicle (UAV) commonly known as a drone which is an aircraft without any human pilot, devices on high speed train (HST) , or image capture devices such as digital cameras, sensors, gaming devices, music storage and playback appliances, or Internet appliances enabling wireless or wired Internet access and browsing and the like. The ‘terminal device’ can further has ‘multicast / broadcast’ feature, to support public safety and mission critical, V2X applications, transparent IPv4 / IPv6 multicast delivery, IPTV, smart TV, radio services, software delivery over wireless, group communications and IoT applications. It may also be incorporated one or multiple Subscriber Identity Module (SIM) as known as Multi-SIM. The term “terminal device” can be used interchangeably with a UE, a mobile station, a subscriber station, a mobile terminal, a user terminal or a wireless device.

[0038] As used herein, the term “network device” refers to a device which is capable of providing or hosting a cell or coverage where terminal devices can communicate. Examples of a network device include, but not limited to, a satellite, an unmanned aerial systems (UAS)  platform, a Node B (NodeB or NB) , an evolved NodeB (eNodeB or eNB) , a next generation NodeB (gNB) , a transmission reception point (TRP) , a remote radio unit (RRU) , a radio head (RH) , a remote radio head (RRH) , an IAB node, a low power node such as a femto node, a pico node, a reconfigurable intelligent surface (RIS) , and the like.

[0039] In one embodiment, the terminal device may be connected with a first network device and a second network device. One of the first network device and the second network device may be a master node (MN) and the other one may be a secondary node (SN) . The first network device and the second network device may use different radio access technologies (RATs) . In one embodiment, the first network device may be a first RAT device and the second network device may be a second RAT device. In one embodiment, the first RAT device is eNB and the second RAT device is gNB. Information related with different RATs may be transmitted to the terminal device from at least one of the first network device and the second network device. In one embodiment, first information may be transmitted to the terminal device from the first network device and second information may be transmitted to the terminal device from the second network device directly or via the first network device. In one embodiment, information related with configuration for the terminal device configured by the second network device may be transmitted from the second network device via the first network device. Information related with reconfiguration for the terminal device configured by the second network device may be transmitted to the terminal device from the second network device directly or via the first network device.

[0040] The terminal device or the network device may have Artificial intelligence (AI) or machine learning capability. It generally includes a model which has been trained from numerous collected data for a specific function, and can be used to predict some information.

[0041] The terminal device or the network device may work on several frequency ranges, e.g. frequency range 1 (FR1) (410 MHz –7125 MHz) , frequency range 2 (FR2) (24.25GHz to 71GHz) , frequency band larger than 100GHz as well as Tera Hertz (THz) . It can further work on licensed / unlicensed / shared spectrum. The terminal device may have more than one connection with the network device under Multi-Radio Dual Connectivity (MR-DC) application scenario. The terminal device or the network device can work on full duplex, flexible duplex and cross division duplex modes.

[0042] The embodiments of the present disclosure may be performed in test equipment, e.g., signal generator, signal analyzer, spectrum analyzer, network analyzer, test terminal device,  test network device, or channel emulator.

[0043] The embodiments of the present disclosure may be performed according to any generation communication protocols either currently known or to be developed in the future. Examples of the communication protocols include, but not limited to, the 1G, 2G, 2.5G, 2.75G, 3G, 4G, 4.5G, 5G, 5.5G, 5G-Advanced networks, or 6G networks.

[0044] The term “circuitry” used herein may refer to hardware circuits and / or combinations of hardware circuits and software. For example, the circuitry may be a combination of analog and / or digital hardware circuits with software / firmware. As a further example, the circuitry may be any portions of hardware processors with software including digital signal processor (s) , software, and memory (ies) that work together to cause an apparatus, such as a terminal device or a network device, to perform various functions. In a still further example, the circuitry may be hardware circuits and or processors, such as a microprocessor or a portion of a microprocessor, that requires software / firmware for operation, but the software may not be present when it is not needed for operation. As used herein, the term circuitry also covers an implementation of merely a hardware circuit or processor (s) or a portion of a hardware circuit or processor (s) and its (or their) accompanying software and / or firmware.

[0045] As used herein, the singular forms “a” , “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. The term “includes” and its variants are to be read as open terms that mean “includes, but is not limited to. ” The term “based on” is to be read as “based at least in part on. ” The term “one embodiment” and “an embodiment” are to be read as “at least one embodiment. ” The term “another embodiment” is to be read as “at least one other embodiment. ” The terms “first, ” “second, ” and the like may refer to different or same objects. Other definitions, explicit and implicit, may be included below.

[0046] In some examples, values, procedures, or apparatus are referred to as “best, ” “lowest, ” “highest, ” “minimum, ” “maximum, ” or the like. It will be appreciated that such descriptions are intended to indicate that a selection among many used functional alternatives can be made, and such selections need not be better, smaller, higher, or otherwise preferable to other selections.

[0047] UCI consists of three messages: hybrid automatic repeat request acknowledgement (HARQ-ACK) , channel state information (CSI) and scheduling request (SR) . Among them, HARQ-ACK and CSI can be transmitted over PUSCH, while SR is usually not transmitted  over PUSCH. In some cases, HARQ-ACK and CSI can also be multiplexed over PUSCH if physical uplink control channel (PUCCH) resources are insufficient.

[0048] For handheld devices, multiple repetitions are required to meet the uplink coverage requirement, e.g. for voice over internet protocol (VoIP) , 20 repetitions within 20ms are required for sub-carrier spacing (SCS) = 15 kHz.

[0049] The PUSCH repetitions might occupy all the uplink resources, and the UCI have to be transmitted by being multiplexed on PUSCH.

[0050] HARQ-ACK transmission: HARQ-ACK messages can be sent over PUCCH or PUSCH. When sending HARQ-ACK on PUSCH, a HARQ-ACK codebook, represented by multi-bit, is typically used. This codebook contains multiple bits to indicate whether the received downlink packet was successfully decoded or not. When the UE receives a physical downlink shared channel (PDSCH) for physical downlink control channel (PDCCH) scheduling, a corresponding HARQ-ACK message is generated; if there is no corresponding PDCCH indication, a downlink Semi Persistent Scheduling (DL SPS) PDSCH scheduling or SPS release scenario may be involved.

[0051] CSI Transmission: CSI can be divided into two parts: CSI Part 1 and CSI Part 2. CSI Part 1 is typically mapped to the beginning of the first non-demodulation reference signal (non-DMRS) symbol on the PUSCH. In some cases, CSI can be mapped to the beginning of the first non-DMRS symbol on the PUSCH. If the message bits of the HARQ-ACK are less than some threshold and there are reserved resources, CSI Part 1 will not be mapped on the reserved resources, while CSI Part 2 can be mapped. The mapping of CSI is rate-matched mapping, i.e., the transmission rate of CSI is adjusted according to the actual channel conditions to ensure effective transmission.

[0052] PUSCH Scheduling mechanism: In NR, the PUSCH is used to transmit the UE's uplink transport block (TB) data as well as the UCI (e.g., HARQ-ACK / CSI) . The PUSCH transmission can be dynamically scheduled via the downlink control information (DCI) format (DCI 0_0  / 0_1  / 0_2) in the PDCCH or, for the Random Access process, the MSG3 PUSCH transmission is scheduled via the Random Access Response (RAR) during the 4-step RA process, or during the 2-step RA process, the UE determines the MSGA PUSCH transmission via the radio resource control (RRC) high-level configuration parameters carried in the system information block (SIB) , and when the decoding of the MSGA PUSCH fails in the 2-step RA process on the base station side, then the 2-step RA falls back to the 4- step RA process, and scheduling of the MSG3 PUSCH transmission is done through fallbackRAR. PUSCH retransmission (non-PUSCH repeat count transmission) is dynamically scheduled by PDCCH or triggered by a retransmission timer. In addition to dynamically scheduled PUSCH transfers, semi-static PUSCH transfers, i.e., configured grant type, are also supported; for configured grant type 1, the RRC configures all parameters of the PUSCH transfer to take effect immediately; while for configured grant type 2, the RRC configures a portion of the high-level parameters of the PUSCH transfer. High-level parameters of the PUSCH transport and the remaining parameters are indicated when activated via the DCI format.

[0053] HARQ-ACK is multiplexed to PUSCH: When the number of bits in the HARQ-ACK is less than or equal to 2, HARQ-ACK is multiplexed to the PUSCH using puncture. When the number of bits in the HARQ-ACK is greater than 2, HARQ-ACK is multiplexed to PUSCH using rate matching.

[0054] The CSI is multiplexed to the PUSCH: A CSI may be multiplexed with a PUSCH if certain conditions are met; otherwise, the CSI is discarded. Specifically, CSIs include non-periodic CSIs, periodic CSIs, and periodic CSIs sent on the PUCCH channel.

[0055] UCI Multiplexing on PUSCH: The HARQ-ACK (if any) and CSI (if any) is encoded and multiplexed with or without encoded UL-SCH data, and then transmitted on a PUSCH. The encoded data, encoded HARQ-ACK, encoded CSI part 1, and encoded CSI part 2 are multiplexed to form a codeword.

[0056] The UCI is transmitted in only the OFDM symbols that are unused for demodulation reference signal (DM-RS) transmission. In any OFDM symbol used for UCI transmission for a UCI type, the mapping of that UCI type depends on the number of resource elements (REs) available for UCI transmission and the remaining REs required for that UCI type. If the number of remaining REs required for that UCI type in an OFDM symbol is greater than half of the available REs for the UCI transmission, the mapping of the UCI type is contiguous. Otherwise, the mapping is uniformly distributed across available REs in an OFDM symbol to achieve the diversity gain. The number of coded bits that are occupied in an RE for UCI or data transmission, is equal to the product of the modulation order and the number of layers.

[0057] The coded HARQ-ACK bits are placed from the OFDM symbol, after the first consecutive DM-RS OFDM symbols. The coded CSI part 1 or part 2 bits are placed at the starting OFDM symbol that is unused for DM-RS in the shared channel symbol allocation.  The multiplexing operation depends on the number of HARQ-ACK bits. When the number of HARQ-ACK bits is less than or equal to 2, the coded HARQ-ACK bits are punctured. Otherwise, the coded HARQ-ACK bits are rate-matched.

[0058] Multiplexing involves these processing steps.

[0059] Step 1: When the number of HARQ-ACK bits is less than or equal to 2, find the reserved HARQ-ACK locations.

[0060] Step 2: When the number of HARQ-ACK bits is greater than 2, map the coded HARQ-ACK bits (if any) .

[0061] Step 3: Map the coded CSI part 1 and CSI part 2 bits (if any) .

[0062] Step 4: Map the coded UL-SCH bits (if any) .

[0063] Step 5: When the number of HARQ-ACK bits is less than or equal to 2, map the coded HARQ-ACK bits (if any) .

[0064] Step 6: Form the codeword.

[0065] OCC schemes, including inter-slot OCC and inter-symbols OCC, are discussed in Rel-19 related to NR NTN. When multiplexing UCI with PUSCH, how to guarantee the orthogonal property of PUSCH should be studied.

[0066] Embodiments of the present disclosure provide a solution of communication. In the solution, a terminal device may encode the UCI with uplink data on PUSCH together to generate encoded code words, and further transmit the PUSCH based on OCC-based PUSCH configuration. As such, the UCI can be multiplexed with PUSCH, and the UCI and the uplink data can be jointly encoded. Therefore, PUSCH coverage performance and orthogonal property of PUSCH can be guaranteed. Principles and implementations of the present disclosure will be described in detail below with reference to the figures.

[0067] FIG. 1A illustrates an example communication network 100 in which some embodiments of the present disclosure can be implemented. The communication network 100 may also be called as a network environment, a network system, a communication system, a communication environment, or the like, the present disclosure does not limit this aspect. The communication network 100 includes a network device 110 and a terminal device 120 which may communicate with each other. The communication network 100 may also include a core network (CN) which is not illustrated in FIG. 1A, and the CN may involve a variety of network functions or entities.

[0068] In the communication network 100, the network device 110 and the terminal device 120 can communicate data and control information to each other, and the communications in the communication network may be implemented according to any proper communication protocol (s) .

[0069] Embodiments of the present disclosure can be applied to any suitable scenarios. For example, embodiments of the present disclosure can be implemented at reduced capability NR devices. Alternatively, embodiments of the present disclosure can be implemented in one of the followings: NR multiple-input and multiple-output (MIMO) , NR sidelink enhancements, NR systems with frequency above 52.6GHz, an extending NR operation up to 71GHz, narrow band-Internet of Thing (NB-IOT)  / enhanced Machine Type Communication (eMTC) over non-terrestrial networks (NTN) , terrestrial networks (TN) , UE power saving enhancements, NR coverage enhancement, NB-IoT and LTE-MTC, Integrated Access and Backhaul (IAB) , NR Multicast and Broadcast Services, or enhancements on Multi-Radio Dual-Connectivity.

[0070] It is to be understood that the numbers of devices and their connection relationships and types shown in FIG. 1A are only for the purpose of illustration without suggesting any limitation. For example, there may be multiple terminal devices connecting to the network device 110, for example the network 100 may include any suitable numbers of devices adapted for implementing embodiments of the present disclosure.

[0071] The network device 110 may be implemented as an on-board network device, such as a gNB deployed at a satellite. In some implementations, the network 100 may be implemented as an NTN, which refers to a network or segment of networks using RF resources on board a satellite or a UAS platform. A satellite (or UAS platform) may implement either a transparent or a regenerative (with on board processing) payload. The satellite (or UAS platform) generate beams typically over a given service area bounded by its field of view. The footprints of the beams are typically of elliptic shape. The field of view of a satellite (or UAS platform) depends on the on board antenna diagram and min elevation angle.

[0072] FIG. 1B illustrates an NTN typical scenario based on transparent payload. A transparent payload may refer to Radio Frequency filtering, Frequency conversion and amplification. Hence, the waveform signal repeated by the payload is un-changed.

[0073] FIG. 1C illustrates an NTN typical scenario based on regenerative payload. A  regenerative payload may refer to Radio Frequency filtering, Frequency conversion and amplification as well as demodulation / decoding, switch and / or routing, coding / modulation. This is effectively equivalent to having all or part of base station functions (e.g. gNB, eNB) on board the satellite (or UAS platform) .

[0074] Table 1 below describes some parameters for some kinds of satellite.

[0075] Table 1

[0076] In the present disclosure, the term “OCC” is used for referring to a coding technique used in wireless communication systems to mitigate interference and improve overall system performance. OCC is particularly effective in scenarios where multiple users or devices are transmitting simultaneously (Code Domain Multiplexing (CDM) technique) , such as in cellular networks or wireless local area networks (WLANs) .

[0077] In coding theory, orthogonal codes refer to sets of sequences that have desirable properties. These codes have the property that their inner product is zero, except when two identical sequences are multiplied together, in which case the inner product is equal to the length of the sequence.

[0078] For example, CDM may be applied in time domain (TD) , in frequency domain (FD) , or in TD and FD together, for example, FIG. 1D illustrates a comparison 104 of some CDMs with a no-CDM scheme. For example, some basic operations may include spreading and multiplexing.

[0079] It is agreed that for the normative phase, at least one of the OCC techniques will be specified:

[0080] - Inter-slot time-domain OCC with PUSCH repetition Type A with OCC length 2 or 4;

[0081] - Inter-symbol (s) time domain OCC with OCC length 2 or 4;

[0082] - Intra-symbol pre-DFT-sOCC (comb-like structure as in PUSCH format 4) with OCC length 2 or 4.

[0083] It is agreed that RAN1 should further study some potential specification aspects on OCC techniques, and the potential aspects at least include UCI multiplexing. However, multiplexing UCI with PUSCH with impact the PUSCH coverage performance, and a legacy UCI mapping rule for multiplexing UCI with PUSCH will break the orthogonal property of inter-slot time-domain OCC or inter-symbol (s) time domain OCC.

[0084] The present disclosure related some relational operators, such as greater than (>) , smaller than (<) , not greater than (≤) , and not smaller than (≥) . The operator “not greater than (≤) ” is also referred to as “smaller than or equal to” , and the operator “not smaller than (≥) ” is also referred to as “greater than or equal to” . It is to be noted that the operators greater than (>) and not smaller than (≥) may be interchangeably used with each in some cases, and the operators smaller than (<) and not greater than (≤) may be interchangeably used with each in some cases. For example, the operator “smaller than (<) ” in some examples below may be replaced by “not greater than (≤) ” , vice versa. For example, the operator “greater than (>) ” in some examples below may be replaced by “not smaller than (≥) ” vice versa.

[0085] Reference is now made to FIG. 2, which illustrates a signalling chart illustrating communication process 200 in accordance with some example embodiments of the present disclosure. The process 200 may involve a network device 110 and a terminal device 120 as shown in FIG. 1A. It would be appreciated that the process 200 may be applied to other communication scenarios, which will not be described in detail.

[0086] In process 200, the network device 110 may transmit, and the terminal device120 may receive, an OCC-based PUSCH configuration at 205. In some implementations, the OCC-based PUSCH configuration may be transmitted from the network device 110 to a group of terminal devices, i.e., a group of UEs which includes the terminal device 120. In some example embodiments, the OCC-based PUSCH configuration may indicate to the group of UEs to perform PUSCH transmission with OCC on a same physical resource.

[0087] In some embodiments, the network device 110 may transmit a multiplexing indication to the terminal device 120, where the multiplexing indication may indicate to the  terminal device 120 to report UCI with the PUSCH. In some examples, the multiplexing indication may be included in the OCC-based PUSCH configuration. In some other examples, the multiplexing indication may be included in another message which is different from the OCC-based PUSCH configuration.

[0088] In the process 200, the terminal device 120 encodes a UCI with uplink data together on PUSCH at 210. For example, the UCI may include HARQ-ACK, CSI Part 1, CSI Part 2, or SR.

[0089] In some implementations, if the UCI needs to be multiplexed on a PUSCH with the uplink data, the terminal device 120 may determine to encode the UCI with the uplink data together. For example, a joint encoding may be performed by the terminal device 120.

[0090] In the present disclosure, the uplink data may refer to data to be transmitted from the terminal device 120 to the network device 110, the uplink data may also be referred to as a UL-SCH, user data, PUSCH, or the like. In the present disclosure, joint encoding may also be called as a joint channel coding of UCI with uplink data.

[0091] In some implementations, the joint encoding may be performed if one or multiple of conditions are met. In some embodiments, the conditions may be referred to as predefined criteria, e.g., for joint encoding. In some examples, the conditions may be configured by the OCC-based PUSCH configuration at 205, or may be configured by another message independent from the OCC-based PUSCH configuration, the present disclosure does not limit for this aspect. In some embodiments, the conditions may include: a size of the UCI is larger than a first threshold, a size of the UCI is in a range from a second threshold to the first threshold, a modulation and coding scheme (MCS) of the UCI is same as that of the uplink data, or a priority of the UCI is lower than that of the uplink data.

[0092] For example, the size of the UCI may also be called as a UCI size, which may be a number of UCI bits. For example, a size of the UCI is in a range from a second threshold to the first threshold may refers to the UCI size is not smaller than the second threshold and not larger than the first threshold. However, some other example may also applied, for example, a size of the UCI is in a range from a second threshold to the first threshold may refers to one of the following: the UCI size is larger than the second threshold and smaller than the first threshold, the UCI size is not smaller than the second threshold and smaller than the first threshold, or the UCI size is larger than the second threshold and not larger than the first threshold. For example, the following formula may be used: second threshold < (or ≤)  UCI size < (or ≤) first threshold. For example, the first threshold is larger than the second threshold. As an example, the first threshold may be 11, the second threshold may be 3. It should be noted that some other values are also applied for the first and / or second threshold (s) , and the present disclosure does not limit for this aspect.

[0093] In some implementations, the UCI and the uplink data may be connected, and then a coding scheme may be used for the connected information. FIG. 3A illustrates an example schematic of joint channel coding 310 in accordance with some embodiments of the present disclosure. For example, if the UCI includes K1 bits and the uplink data includes K2 bits, they may be joint encoding to obtain encoded bits C (K1+K2) , where C may refer to a channel coding method. For instance, the channel coding method C may be indicated by channel coding parameters for PUSCH. For instance, the channel coding method C may be a default one, such as low-density parity check (LDPC) or Polar code.

[0094] In some other implementations, concatenated coding may be used during the joint encoding. In some embodiments, the terminal device 120 first encodes the UCI using first coding information, and then encodes the first encoded UCI with the uplink data using second coding information. In some examples, the first encoding for UCI independently may refer to an outer coding, and the second encoding for the UCI and the uplink data together may refer to an inner coding. It is understood that concatenated codes are error-correcting codes that are combinations of two or more simpler codes designed to achieve good performance and low complexity through rational design.

[0095] FIG. 3B illustrates an example schematic of joint channel coding 320 in accordance with some embodiments of the present disclosure. For example, if the UCI includes K1 bits and the uplink data includes K2 bits, an outer coding may be performed on K1 bits to generate C1 (K1) , where C1 refers to an outer channel coding method. In addition, C1 (K1) and the uplink data (K2 bits) may be further encoded together to obtain encoded bits C2 (C1 (K1) +K2) , where C2 may refer to an inner channel coding method.

[0096] In some embodiments, the first coding information may include an outer channel coding method. For example, the outer channel coding method includes a first outer channel coding method (e.g., repetition code, simplex code) used for the UCI with a size smaller than the second threshold; a second outer channel coding method (e.g., Reed-Muller (RM) code) used for the UCI with a size not smaller than the second threshold but not larger than a first threshold; and a third outer channel coding method (e.g., Polar code) used for the  UCI with a size larger than the first threshold. For instance, the first threshold is 11 and the second threshold is 3, the first outer channel coding method is used for the UCI with size <3, the second outer channel coding method is used for the UCI with 3≤size≤11, and the third outer channel coding method is used for the UCI with size>11.

[0097] In some embodiments, the second coding information may include inner coding parameters. In some examples, the inner coding parameters include a first set of parameters used for the UCI with a size smaller than the second threshold, a second set of parameters used for the UCI with a size not smaller than the second threshold but not larger than the first threshold, and a third set of parameters used for the UCI with a size larger than the first threshold. For example, the first set of parameters may include a first inner channel coding method used for the UCI with size <3, the second set of parameters may include a second inner channel coding method used for the UCI with 3≤size≤11, and the third set of parameters may include a third inner channel coding method used for the UCI with size>11.

[0098] In some cases, a size of the UCI may be smaller than the second threshold (such as 3) , the terminal device 120 may encode the UCI using the first coding information (e.g., including a first outer channel coding method) to generate a first encoded UCI, then the terminal device 120 may encode the uplink data and the first encoded UCI using the first set of parameters (e.g., including a first inner channel coding method) . In some examples, the first set of parameters may include modulation order of PUSCH, channel coding parameters for PUSCH. For example, the first outer channel coding method may be determined based on an existing configuration parameters, or may be determined based on dedicated parameters (e.g., configured for OCC) . For example, the first inner channel coding method may be determined based on channel coding parameters for PUSCH.

[0099] In some cases, a size of the UCI may be not smaller than the second threshold (such as 3) and not larger than the first threshold (such as 11) , the terminal device 120 may encode the UCI using the first coding information (e.g., including a second outer channel coding method) to generate a first encoded UCI, then the terminal device 120 may encode the uplink data and the first encoded UCI using the second set of parameters (e.g., including a second inner channel coding method) . In some examples, the second set of parameters may include modulation order of PUSCH, channel coding parameters for PUSCH. For example, the second outer channel coding method may be determined based on an existing configuration parameters, or may be determined based on dedicated parameters (e.g., configured for OCC) .  For example, the second inner channel coding method may be determined based on channel coding parameters for PUSCH.

[0100] In some cases, a size of the UCI may be larger than the first threshold (such as 11) , the terminal device 120 may encode the UCI using the first coding information (e.g., including a third outer channel coding method) to generate a first encoded UCI, then the terminal device 120 may encode the uplink data and the first encoded UCI using the third set of parameters (e.g., including a third inner channel coding method) . For example, the third outer channel coding method may be determined based on dedicated parameters (e.g., configured for OCC) . For instance, the third outer channel coding method may be Polar coding method, and the dedicated parameters further includes corresponding coding length and / or coding rate. For example, the third inner channel coding method may be determined based on channel coding parameters for PUSCH.

[0101] It is to be noted that although three outer channel coding methods and three sets of parameters are discussed based on a size of the UCI, in an actual case, more or less outer channel coding methods and sets of parameters may be applied for a different range of UCI size, the present disclosure does not limit for this aspect. For example, the outer channel coding method may include: an outer channel coding method 1 (such as repetition code) used for the UCI with size=1, an outer channel coding method 2 (such as simplex code) used for the UCI with size=2, an outer channel coding method 3 (such as RM code) used for the UCI with 3≤size≤11, and outer channel coding method 4 (such as Polar code) used for the UCI with size>11.

[0102] In some embodiments, concatenated coding parameters may be configured to the terminal device 120 by the network device 110, and the concatenated coding parameters may be regarded as dedicated parameters for determining at least part of the third set of parameters (e.g., including a third inner channel coding method) . In some examples, the concatenated coding parameters may include the first coding information and the second coding information. For example, the concatenated coding parameters may include the first coding information and the third set of parameters discussed above, while the first set of parameters and the second set of parameters may be indicated by channel coding parameters for PUSCH.

[0103] In some examples, the concatenated coding parameters include an indication indicating that a concatenated coding is enabled, for example, the indication may be a concatenating-enabled indication. In some examples, the concatenated coding parameters  include one or more of the following: a concatenated coding manner, a concatenated coding scheme, a coding length, or a coding rate. For example, the concatenated coding manner may indicate which part (s) will be encoded using first encoding information (such as an outer channel coding method) , and / or how the joint-coding is performed. For instance, an example of how the joint-coding is performed may refer to the coding manner with reference to info1, info2, and info 3 below. For example, the concatenated coding scheme may indicate a combination of an outer channel coding method and an inner channel coding method, e.g., a combination of one or more of the following: RM code, Polar code, LDPC, Repetition code, Simplex code, Turbo code, etc.

[0104] In some examples, the concatenated coding parameters may be transmitted by at least one of: a DCI, a medium access control (MAC) control element (CE) , or RRC signalling. In some examples, the concatenated coding parameters may be included in the OCC-based configuration at 205, or be included in another message different from the OCC-based configuration.

[0105] As a specific example, the inner coding parameters (e.g., the second inner channel coding method mentioned above) may be indicated by a beta_offset indicator with the beta_offset value provided by a higher layer (e.g., RRC) . Table 2 below gives an example of beta_offset indicator.

[0106] Table 2

[0107] For example, for HARQ-ACK bits length larger than 11, the network device 110 may indicate the configuration by or  (HARQ-ACK with a priority  “0” ) or  (HARQ-ACK with a priority “1” ) with beta_offset indicator ( “11” ) , and the beta_offset value is the 4th offset value provided by higher layers.

[0108] For example, for CSI Part 1 bits length larger than 11, the network device 110 may indicate the configuration by with beta_offset indicator ( “11” or “10” ) , and the beta_offset value is the 3rd or 4th offset value provided by higher layer.

[0109] For example, for CSI Part 2 bits length larger than 11, the network device 110 may indicate the configuration by with beta_offset indicator ( “11” or “10” ) , and the beta_offset value is the 3rd or 4th offset value provided by higher layerss.

[0110] Referring back to FIG. 2, the terminal device 120 transmits the PUSCH at 220, and accordingly the network device 110 received the PUSCH. It is understood that the PUSCH includes joint-coded UCI and uplink data, with or without concatenated coding.

[0111] In the process 200, the network device 110 decodes the PUSCH at 230, to obtain the UCI and the uplink data. In some implementations, if multiple PUSCHs are received from multiple terminal devices in the same physical resource, the network device 110 may de-multiplex the PUSCHs for multiple terminal devices.

[0112] According to embodiments with reference to FIGS. 2-3B, the terminal device may perform a joint channel coding of the UCI (e.g., HARQ-ACK, CSI Part 1, CSI Part 2, or SR) with uplink data, for multiplexing the UCI on PUSCH. Since joint channel coding is used, there is no need for puncturing the first / second information, and accordingly the code rate loss can be avoided and the throughput can be guaranteed. No code rate loss is subjected and the user data throughput can be ensured. In addition, the UCI is multiplexed on the PUSCH by joint coding with uplink data, thus an orthogonal property can be guaranteed for potential OCC scheme (s) . In some examples, concatenated coding may be employed to further balance the reliability of the UCI and uplink data.

[0113] It is to be appreciated that although FIG. 3B is illustrated based on a joint channel coding for UCI and uplink data, it may be used for a joint channel coding for any number of pieces of information. The present disclosure may provide a joint channel coding method for a plurality of pieces of information. The terminal device may perform a joint channel coding for the plurality of pieces of information to generate a joint-encoded information. In addition or alternatively, the terminal device may further transmit the joint-encoded information to the network device. In some instances, the plurality of pieces of information  may be uplink information or downlink information or sidelink information. For instance, the plurality of pieces of information may include DCI and DL-SCH, with or without OCC. For instance, the plurality of pieces of information may include UCI and UL-SCH, with or without OCC.

[0114] In some examples, the joint-encoded information may be generated by using a channel encoding configuration on first information and second information, or on a first information, second information and third information. For example, the first information (or the second or third information) may be one piece of the plurality of pieces of information, or be part of one piece of the plurality of pieces of information. For example, the first information (or the second or third information) may be encoded information of one piece of the plurality of pieces of information, or be encoded information of part of piece of the plurality of pieces of information. For example, the first information (or the second or third information) may be encoded information of two or more pieces of the plurality of pieces of information.

[0115] Take a specific example, assuming the plurality of pieces of information includes info1, info2 and info3, then the joint-encoded information may be any of the following:

[0116] – C0 (C1 (info1) +info2+info3) ,

[0117] – C0 (C1 (info1) +C2 (info2) +info3) ,

[0118] – C0 (C1 (info1) +C2 (info2) +C3 (info3) ) ,

[0119] – C0 (C2 (C1 (info1) +info2) +info3) ,

[0120] – C0 (C1 (info) +C2 (info2+info3) ) ,

[0121] – C0 (C2 (C1 (info1) +info2) +C3 (info3) ) , or

[0122] – C0 (C4 (C1 (info1) +C2 (info2) ) +C3 (info3) ) .

[0123] It should be noted that the above examples for the joint-encoded information are only for illustration without any limitation. For example, info1 may be replaced by a portion of info1, and info2 may be replaced by a combination of another portion of info1 and info2. For example, more pieces of information may be included. As such, the reliability of at least one piece of information (such as info1) is enhanced. The joint channel coding could best use the channel coding gain to improve the system performance.

[0124] Reference is further made to FIG. 4, which illustrates a signalling chart illustrating  communication process 400 in accordance with some example embodiments of the present disclosure. The process 400 may involve a network device 110 and a terminal device 120 as shown in FIG. 1A. It would be appreciated that the process 400 may be applied to other communication scenarios, which will not be described in detail.

[0125] In the process 400, the network device 110 may transmit, and the terminal device120 may receive, an OCC-based PUSCH configuration at 405. In some implementations, the OCC-based PUSCH configuration may be transmitted from the network device 110 to a group of terminal devices, i.e., a group of UEs which includes the terminal device 120. In some example embodiments, the OCC-based PUSCH configuration may indicate to the group of UEs to perform PUSCH transmission with OCC on a same physical resource.

[0126] In some embodiments, the network device 110 may transmit a multiplexing indication to the terminal device 120, where the multiplexing indication may indicate to the terminal device 120 to report UCI with the PUSCH. For example, the UCI may include HARQ-ACK, CSI Part 1, CSI Part 2, or SR. In some examples, the multiplexing indication may be included in the OCC-based PUSCH configuration. In some other examples, the multiplexing indication may be included in another message which is different from the OCC-based PUSCH configuration.

[0127] In some embodiments, the network device 110 may indicate, to the terminal device 120, an OCC scheme, such as an inter-slot level OCC or an inter-symbol (s) level OCC. In some examples, the OCC-based PUSCH configuration may indicate the inter-slot level OCC. In some other examples, when the OCC scheme is an inter-symbol (s) level OCC, a starting symbol for the first demodulation reference signal (DMRS) of the PUSCH may be further indicated. For example, the OCC-based PUSCH configuration may indicate the inter-symbol (s) level OCC and that the starting symbol for the first DMRS of the PUSCH is with a specific symbol index, such as index #2 (l0=2) .

[0128] In the process 400, the terminal device 120 determines an OCC unit at 410. For example, the OCC unit may be determined so that all OCC code words (related to OCC length and OCC index) will be applied at least once in the OCC unit.

[0129] It should be noted that although one OCC unit is discussed in some embodiments, a plurality of OCC units may be determined at 410 and the present disclosure does not limit for this aspect. For example, a plurality of OCC units may be determined, and the terminal  device 120 may multiplex the same UCI with PUSCH for all PUSCH repetitions at least within the first OCC unit among the plurality of OCC units.

[0130] In some examples, for the OCC unit, all the OCC code words for a specific OCC length and OCC index configuration will be used at least once. In some examples, the terminal device 120 could ensure phase continuity and power consistency of the uplink transmission during an OCC unit.

[0131] In some implementations, the OCC unit may be determined if one or multiple of conditions are met. In some embodiments, the conditions may be referred to as predefined criteria, e.g., for OCC unit determination. In some examples, the conditions may be configured by the OCC-based PUSCH configuration at 405, or may be configured by another message independent from the OCC-based PUSCH configuration, the present disclosure does not limit for this aspect. In some embodiments, the conditions may include: a size of the UCI is smaller than or not larger than a threshold, an MCS of the UCI is lower than that of the uplink data, or a priority of the UCI is higher than that of the uplink data.

[0132] For example, the size of the UCI may also be called as a UCI size, which may be a number of UCI bits. For example, the UCI size may be smaller than or not larger than a threshold.

[0133] In some implementations, the OCC unit may be determined based on: an actual TDW, and an OCC length, and a length of a PUSCH repetition. In some examples, an actual TDW may be a concept used during PUSCH transmission, e.g., defined and standardized in the context of joint channel estimation. During PUSCH transmission, the terminal device should ensure phase continuity and power consistency within any actual TDW to facilitate the network to do joint channel estimation. For example, an actual TDW may be determined based on information reported from the terminal deice 120 and additional configuration information from the network device 110, e.g., actualTDW=4 slots. It is understood that the terminal device 120 and the network device 110 may determine the actual TDW following a same rule. For example, the OCC length may be 2 or 4. For example, the length of the PUSCH repetition may be related to one slot duration.

[0134] In the present disclosure, the length of the PUSCH repetition may be also referred to as a PUSCH repetition duration. In some examples, the length of the PUSCH repetition may be a plurality of symbols, e.g., represented by K2 symbols, in some examples, a symbol  group including the plurality of symbols (e.g., K2 symbols) may also be used to represent the length of the PUSCH repetition.

[0135] In some embodiments, if a first function of the actual TDW, the OCC length, and the length of the PUSCH repetition is satisfied, the OCC unit may be determined based on a second function of the actual TDW, the OCC length, and the length of the PUSCH repetition.

[0136] In some examples, the first function and the second function may be represented by (1) and (2) respectively: floor {actualTDW /  (OCClength*one pusch repetition duration) } > 0    (1) OCC unit = floor {actualTDW /  (OCClength*one pusch repetition duration) } *  OCClength*one pusch repetition duration      (2)

[0137] For example, the one PUSCH repetition duration may be determined based on a length of a slot (i.e., one slot duration) and a predefined parameter. For example, the one PUSCH repetition duration may be determined based on a length of a symbol (i.e., one symbol duration) and a predefined parameter.

[0138] For inter-slot OCC, the PUSCH repetition duration (i.e., “one pusch repetition duration” in the function (1) or (2) ) may be determined by: one pusch repetition duration = one slot duration *N     (3)

[0139] where N isthe predefined parameter, and N=1, or N is indicated by the network as a number of slots used for transport block size (TBS) determination when TBoMS (TB processing over multi-slot, or TB processing over multi-slot PUSCH) is enabled, e.g., indicated by IE “numberOfSlotsTBoMS” .

[0140] TB processing over multi-slot is specified for coverage enhancement by combining multiple slots to determine the TBS.

[0141] For TB processing over multiple slots, when transmitting PUSCH scheduled by DCI format 0_1, 0_2 or 0_3 in PDCCH with CRC scrambled with C-RNTI, MCS-C-RNTI, or CS-RNTI with NDI=1,

[0142] - the number of slots used for TBS determination N is indicated by numberOfSlotsTBoMS; and

[0143] - the number of repetitions (represented as K) of the number of slots N used for TBS determination is determined as:

[0144] ■ if numberOfRepetitions is present in the resource allocation table, the number of repetitions K is equal to numberOfRepetitions;

[0145] ■ otherwise, K=1.

[0146] - when the terminal device 120 supports repetition of TB processing over multiple slots, the terminal device 120 does not expect that N·K is larger than 32.

[0147] For inter-symbol (s) OCC, the PUSCH repetition duration (i.e., “one pusch repetition duration” in the function (1) or (2) ) may be determined by the following equation (4) or (5) : one pusch repetition duration = K1*one slot duration    (4) one pusch repetition duration = K2*one symbol duration    (5)

[0148] where K1 or K2 may be the predefined parameter. For example, K1=0.5 for a coverage-limited scenario such as NTN, and K1<0.5 for a good coverage scenario such as TN. For example, K2 is an integer with 1≤K2≤7. For instance, K2=7 for a coverage-limited scenario such as NTN, in other words, a length of the PUSCH repetition (the number of symbols for the PUSCH repetition) is 7 symbols. For instance, 1≤K2<7 for a good coverage scenario such as TN, in other words, a of the PUSCH repetition (the number of symbols for the PUSCH repetition) is less than 7 symbols.

[0149] In some examples, the OCC-based PUSCH configuration may include the predefined parameter, which may be used by the terminal device 120 to determine the length of PUSCH repetition. In some other examples, the OCC-based PUSCH configuration may include the length of PUSCH repetition directly, e.g., 7 symbols.

[0150] As such, the terminal device 120 can determine the OCC unit at 410 based on the second function (2) . It should be noted that if the first function (1) is not satisfied, there may be no way to do the PUSCH transmission with OCC, no matter with or without UCI. In this case, the network device 110 will not schedule a terminal device without a valid OCC unit to transmit PUSCH with inter-slot / inter-symbol (s) level OCC. A terminal device without a valid OCC will not expect to be scheduled to transmit PUSCH with inter-slot / inter-symbol (s) level OCC.

[0151] In addition or alternatively, after determining the OCC unit at 410, the terminal device 120 may further update a length of the actual TDW, for example, an updated actual TDW may equal to the OCC unit. In some examples, the terminal device 120 may restart the actual TDW after each OCC unit. For example, the OCC transmission may be regarded  as a new event for determining (or updating) the actual TDW. For example, the end of OCC unit may be a new event for determining (or updating) the actual TDW.

[0152] In the process 400, the terminal device 120 multiplexes the UCI with the uplink data for a plurality of PUSCH repetitions within the OCC unit at 420. In some examples, the terminal device 120 multiplexes the same UCI with PUSCH for all the PUSCH repetitions at least once within one OCC unit. For example, all the OCC code words with the OCC sequence corresponding to the configured OCC length and OCC index will be applied at least once within one OCC unit.

[0153] In the process 400, the terminal device 120 transmits, and the network device 110 receives, the PUSCH at 430.

[0154] In some implementations, the terminal device 120 transmits the PUSCH with OCC following the OCC-based PUSCH configuration. In some implementations, the PUSCH multiplexed with UCI is determined based on a mapping rule to ensure an orthogonal property of each multiplexed part.

[0155] In some embodiments, for inter-symbol (s) level OCC, alternatively, the terminal device 120 may perform, at 425, mirror mapping in a slot. In some examples, the terminal device 120 may multiplex the UCI with the uplink data in the first half of a slot, and then map symbols in the first half of the slot to the second half of a slot. In some examples, the mirror mapping is performed for each slot in one OCC unit.

[0156] FIG. 5A illustrates an example schematic of mirrored mapping 510 with an OCC length being 2 in accordance with some embodiments of the present disclosure. As illustrated, for slot #0, an OCC code word #1 is applied to a symbol group #1 which includes the first half (i.e., symbol#0 to symbol#6) of the slot, and an OCC code word #2 is applied to a symbol group #2 which includes the second half (i.e., symbol#7 to symbol#13) of the slot. According to the mirror mapping, the content on #0 symbol may be the same as the content on #13 symbol, the content on #1 symbol may be the same as the content on #12 symbol, the content on #2 symbol (DMRS) may be the same as the content on #11 symbol (DMRS) , the content on #3 symbol may be the same as the content on #10 symbol, the content on #4 symbol may be the same as the content on #9 symbol, the content on #5 symbol may be the same as the content on #8 symbol, and the content on #6 symbol may be the same as the content on #7 symbol. It is understood that the first DMRS of the PUSCH will be on symbol #2 according to the configuration.

[0157] FIG. 5B illustrates an example schematic of mirrored mapping 520 with an OCC length being 4 in accordance with some embodiments of the present disclosure. As illustrated, an OCC code word #1 is applied to a symbol group #1 which includes the first half (i.e., symbol#0 to symbol#6) of slot #0, an OCC code word #2 is applied to a symbol group #2 which includes the second half (i.e., symbol#7 to symbol#13) of slot #0, an OCC code word #1 is applied to a symbol group #3 which includes the first half (i.e., symbol#0 to symbol#6) of slot #1, an OCC code word #2 is applied to a symbol group #4 which includes the second half (i.e., symbol#7 to symbol#13) of slot #1. The mirror mapping is performed similar with that in FIG. 5A, details of which will not be repeated herein.

[0158] It should be noted that although each symbol in FIGS. 5A-5B carries information, the present disclosure does not limit for this aspect. For example, there may be no PUSCH data on some symbols, e.g., #0 symbol and #13 symbol are used for other physical channels or signals.

[0159] Referring back to FIG. 4, in the process 400, the network device 110 decodes the PUSCH at 440, to obtain the UCI and the uplink data. In some implementations, if multiple PUSCHs are received from multiple terminal devices in the same physical resource, the network device 110 may de-multiplex the PUSCHs for multiple terminal devices.

[0160] As illustrated, the network device 110 may determine an OCC unit at 415, details of which is similar as that discussed with reference to the operation 410, thus will not be repeated herein.

[0161] In some implementations, for inter-slot level OCC, the network device 110 may de-multiplex of the received signals within each OCC unit. The network device 110 may perform joint channel estimation within each OCC unit. The network device 110 may coherent combine the PUSCH of each repetition before decoding, and then may perform soft combining of the decoding results across each OCC unit and do further decoding.

[0162] In some implementations, for inter-symbol (s) level OCC, the network device 110 may de-multiplex of the received signals within each OCC unit. The network device 110 may perform joint channel estimation within each OCC unit. The network device 110 may de-interleave the symbol order, e.g., by de-interleaving an order of symbols in a slot based on a mapping from symbols in the first half of the slot to a second half of the slot in a mirrored manner. For example, with reference to FIG. 5A, the order may be re-determined as: #0, #1, #2, #3, #4, #5, #6, #13, #12, #11, #10, #9, #8, #7. The network device 110 may coherent  combine the PUSCH of each repetition before decoding, and then may perform soft combining of the decoding results across each OCC unit and do further decoding.

[0163] For example, the operation of coherent combining may exploit the phase information of the received signal to enhance the received signal quality for better decoding results. For example, the operation of soft combining may exploit the channel decoder output of the likelihood of each PUSCH repetition, and output the UCI and PUSCH user data separately.

[0164] According to embodiments with reference to FIGS. 4-5B, an OCC unit may be determined, and all OCC code words may be applied at least once within the OCC unit. For example, the terminal device may multiplex the same UCI with PUSCH for a plurality of PUSCH repetitions at least with one OCC unit, so as to maximize the coherent combined gain and enhance the system performance. Accordingly, the orthogonal property of the PUSCH can be guaranteed, when the UCI is reported multiplexed with the PUSCH.

[0165] It is to be appreciated that the processes described above are only for illustration without any limitation. In some examples, one or more steps may be omitted or combined or modified. In some examples, one or more additional steps may be added. One or more steps in a process may be combined into another process. It is to be understood that some further embodiments may be obtained and are still in the protection scope of the present disclosure.

[0166] FIG. 6 illustrates a flowchart of an example method 600 implemented at a terminal device in accordance with some embodiments of the present disclosure. For the purpose of discussion, the terminal device which may perform the method 600 can be the terminal device 120 discussed above.

[0167] At block 610, in accordance with a determination that a UCI needs to be multiplexed on a PUSCH with uplink data and OCC parameters are configured, the terminal device 120 encodes the UCI with the uplink data together to generate encoded code words. At block 620, the terminal device 120 transmits, to a network device, the PUSCH comprising the encoded code words based on an OCC-based PUSCH configuration.

[0168] It should be noted that the method 600 may include various other operations which may be performed by the terminal device 120 as described above with reference to FIG. 2.

[0169] FIG. 7 illustrates a flowchart of an example method 700 implemented at a terminal device in accordance with some embodiments of the present disclosure. For the purpose of  discussion, the terminal device which may perform the method 700 can be the terminal device 120 mentioned above.

[0170] At block 710, in accordance with a determination that a UCI needs to be multiplexed on a PUSCH with uplink data and OCC parameters are configured, the terminal device 120 determines an OCC unit based on an actual TDW, an OCC length, and a length of a PUSCH repetition. At block 720, the terminal device 120 multiplexes the UCI with the uplink data for a plurality of PUSCH repetitions within the OCC unit. At block 730, the terminal device 120 transmits, to a network device, the PUSCH comprising multiplexed UCI and uplink data based on an OCC-based PUSCH configuration.

[0171] It should be noted that the method 700 may include various other operations which may be performed by the terminal device 120 as described above with reference to FIGS. 4-5B.

[0172] FIG. 8 illustrates a flowchart of an example method 800 implemented at a network device in accordance with some embodiments of the present disclosure. For the purpose of discussion, the network device which may perform the method 800 can be the network device 110 discussed above.

[0173] At block 810, the network device 110 receives, from a terminal device, a PUSCH comprising encoded code words based on an OCC-based PUSCH configuration. At block 820, the network device 110 decodes the encoded code words to obtain UCI and uplink data which are encoded together.

[0174] It should be noted that the method 800 may include various other operations which may be performed by the network device 110 as described above with reference to FIG. 2.

[0175] FIG. 9 illustrates a flowchart of an example method 900 implemented at a network device in accordance with some embodiments of the present disclosure. For the purpose of discussion, the network device which may perform the method 900 can be the network device 110 discussed above.

[0176] At block 910, the network device 110 receives, from a terminal device, a PUSCH comprising multiplexed UCI and uplink data based on an OCC-based PUSCH configuration. At block 920, the network device 110 decodes the PUSCH to obtain the UCI and the uplink data which are multiplexed for a plurality of PUSCH repetitions within an OCC unit, wherein the OCC unit is determined based on: an actual TDW, an OCC length, and a length of a PUSCH repetition.

[0177] It should be noted that the method 900 may include various other operations which may be performed by the network device 110 as described above with reference to FIGS. 4-5B.

[0178] Details of some embodiments according to the present disclosure have been described with reference to FIGS. 1A-9. Now an example implementation of the terminal device and the network device will be discussed below.

[0179] In some example embodiments, a terminal device comprises circuitry configured to: in accordance with a determination that a UCI needs to be multiplexed on a PUSCH with uplink data and OCC parameters are configured, encode the UCI with the uplink data together to generate encoded code words; and transmit, to a network device, the PUSCH comprising the encoded code words based on an OCC-based PUSCH configuration. It should be noted that the terminal device comprises circuitry configured to perform various other operations as described above with reference to FIG. 2.

[0180] In some example embodiments, a terminal device comprises circuitry configured to: in accordance with a determination that a UCI needs to be multiplexed on a PUSCH with uplink data and OCC parameters are configured, determine an OCC unit based on an actual TDW, an OCC length, and a length of a PUSCH repetition; multiplex the UCI with the uplink data for a plurality of PUSCH repetitions within the OCC unit; and transmit, to a network device, the PUSCH comprising multiplexed UCI and uplink data based on an OCC-based PUSCH configuration. It should be noted that the terminal device comprises circuitry configured to perform various other operations as described above with reference to FIG. 4.

[0181] In some example embodiments, a network device comprises circuitry configured to: receive, from a terminal device, a PUSCH comprising encoded code words based on an OCC-based PUSCH configuration; and decode the encoded code words to obtain UCI and uplink data which are encoded together. It should be noted that the network device comprises circuitry configured to perform various other operations as described above with reference to FIG. 2.

[0182] In some example embodiments, a network device comprises circuitry configured to: receive, from a terminal device, a PUSCH comprising multiplexed UCI and uplink data based on an OCC-based PUSCH configuration; and decode the PUSCH to obtain the UCI and the uplink data which are multiplexed for a plurality of PUSCH repetitions within an OCC unit, wherein the OCC unit is determined based on: an actual TDW, an OCC length, and a length  of a PUSCH repetition. It should be noted that the network device comprises circuitry configured to perform various other operations as described above with reference to FIG. 4.

[0183] FIG. 10 illustrates a simplified block diagram of a device 1000 that is suitable for implementing embodiments of the present disclosure. The device 1000 can be considered as a further example implementation of the terminal device 120 and the network device 110 as described above. Accordingly, the device 1000 can be implemented at or as at least a part of the terminal device or the network device.

[0184] As shown, the device 1000 includes a processor 1010, a memory 1020 coupled to the processor 1010, a suitable transceiver 1040 coupled to the processor 1010, and a communication interface coupled to the transceiver 1040. The memory 1020 stores at least a part of a program 1030. The transceiver 1040 may be for bidirectional communications or a unidirectional communication based on requirements. The transceiver 1040 may include at least one of a transmitter and a receiver. The transmitter and the receiver may be functional modules or physical entities. The transceiver 1040 has at least one antenna to facilitate communication, though in practice an Access Node mentioned in this application may have several ones. The communication interface may represent any interface that is necessary for communication with other network elements, such as X2 / Xn interface for bidirectional communications between eNBs / gNBs, S1 / NG interface for communication between a Mobility Management Entity (MME)  / Access and Mobility Management Function (AMF)  / SGW / UPF and the eNB / gNB, Un interface for communication between the eNB / gNB and a relay node (RN) , or Uu interface for communication between the eNB / gNB and a terminal device.

[0185] The program 1030 is assumed to include program instructions that, when executed by the associated processor 1010, enable the device 1000 to operate in accordance with the embodiments of the present disclosure, as discussed herein with reference to FIGS. 1A-9. The embodiments herein may be implemented by computer software executable by the processor 1010 of the device 1000, or by hardware, or by a combination of software and hardware. The processor 1010 may be configured to implement various embodiments of the present disclosure. Furthermore, a combination of the processor 1010 and memory 1020 may form processing means 1050 adapted to implement various embodiments of the present disclosure.

[0186] The memory 1020 may be of any type suitable to the local technical network and  may be implemented using any suitable data storage technology, such as a non-transitory computer readable storage medium, semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory, as non-limiting examples. While only one memory 1020 is shown in the device 1000, there may be several physically distinct memory modules in the device 1000. The processor 1010 may be of any type suitable to the local technical network, and may include one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on multicore processor architecture, as non-limiting examples. The device 1000 may have multiple processors, such as an application specific integrated circuit chip that is slaved in time to a clock which synchronizes the main processor.

[0187] In summary, embodiments of the present disclosure may provide the following solutions.

[0188] The present disclosure provides a terminal device, comprising at least one processor configured to cause the terminal device at least to: in accordance with a determination that a UCI needs to be multiplexed on a PUSCH with uplink data and OCC parameters are configured, encode the UCI with the uplink data together to generate encoded code words; and transmit, to a network device, the PUSCH comprising the encoded code words based on an OCC-based PUSCH configuration.

[0189] In one embodiment, the terminal device as above, the at least one processor is configured to cause the terminal device to encode the UCI with the uplink data together by: encoding the UCI independently using first coding information to generate an encoded UCI; and encoding the encoded UCI and the uplink data together using second coding information.

[0190] In one embodiment, the terminal device as above, the at least one processor is configured to cause the terminal device to: receive, from the network device, concatenated coding parameters by at least one of: DCI, MAC CE, or RRC signalling, wherein the concatenated coding parameters comprise the first coding information.

[0191] In one embodiment, the terminal device as above, the second coding information is comprised in channel coding parameters for PUSCH or in the concatenated coding parameters.

[0192] In one embodiment, the terminal device as above, the concatenated coding parameters comprise at least one of: an indication indicating that a concatenated coding is  enabled, a concatenated coding manner, a concatenated coding scheme, a coding length, or a coding rate.

[0193] In one embodiment, the terminal device as above, the second coding information comprises: a first set of parameters for a size of the UCI being smaller than a second threshold, a second set of parameters for a size of the UCI being not smaller than the second threshold and not larger than a first threshold, or a third set of parameters for a size of the UCI being larger than the first threshold.

[0194] In one embodiment, the terminal device as above, the at least one processor is configured to cause the terminal device to: receive, from the network device, the OCC-based PUSCH configuration, wherein the OCC-based PUSCH configuration indicates that a group of terminal devices should perform a PUSCH transmission with OCC on a same physical resource.

[0195] In one embodiment, the terminal device as above, the at least one processor is configured to cause the terminal device to: in accordance with at least one of the following conditions is met, encode the UCI with the uplink data together: a size of the UCI is larger than or not smaller than a first threshold, a size of the UCI is in a range from a second threshold to the first threshold, an MCS of the UCI is same as that of the uplink data, or a priority of the UCI is lower than that of the uplink data.

[0196] In one embodiment, the terminal device as above, the UCI comprises at least one of: HARQ-ACK, CSI part 1, CSI part 2, or SR.

[0197] The present disclosure provides a terminal device, comprising at least one processor configured to cause the terminal device at least to: in accordance with a determination that a UCI needs to be multiplexed on a PUSCH with uplink data and OCC parameters are configured, determine an OCC unit based on an actual TDW, an OCC length, and a length of a PUSCH repetition; multiplex the UCI with the uplink data for a plurality of PUSCH repetitions within the OCC unit; and transmit, to a network device, the PUSCH comprising multiplexed UCI and uplink data based on an OCC-based PUSCH configuration.

[0198] In one embodiment, the terminal device as above, the at least one processor is configured to cause the terminal device to determine the OCC unit by: in accordance with a determination that a first function of the actual TDW, the OCC length, and the length of the PUSCH repetition is satisfied, determining the OCC unit based on a second function of the actual TDW, the OCC length, and the length of the PUSCH repetition.

[0199] In one embodiment, the terminal device as above, the length of the PUSCH repetition is determined based on a predefined parameter and a length of a slot.

[0200] In one embodiment, the terminal device as above, the OCC comprises an inter-slot level OCC, and the predefined parameter is associated with a number of slots used for TBS determination.

[0201] In one embodiment, the terminal device as above, the OCC comprises an inter-symbols level OCC, and the predefined parameter is 0.5 for a coverage-limited scenario or is less than 0.5 for a good coverage scenario.

[0202] In one embodiment, the terminal device as above, the OCC comprises an inter-symbols level OCC, and the OCC-based PUSCH configuration indicates that the length of the PUSCH repetition is 7 symbols.

[0203] In one embodiment, the terminal device as above, the OCC comprises an inter-symbols level OCC, and the OCC-based PUSCH configuration indicates that a starting symbol for a first DMRS of the PUSCH is with a specific symbol index.

[0204] In one embodiment, the terminal device as above, the OCC comprises an inter-symbols level OCC, and wherein the at least one processor is configured to cause the terminal device to multiplex the UCI with the uplink data by: multiplexing the UCI with the uplink data in a first half of a slot; and mapping symbols in the first half of the slot to a second half of the slot in a mirrored manner.

[0205] In one embodiment, the terminal device as above, the at least one processor is configured to cause the terminal device to: receive, from the network device, the OCC-based PUSCH configuration, wherein the OCC-based PUSCH configuration indicates that a group of terminal devices should perform a PUSCH transmission with OCC on a same physical resource.

[0206] In one embodiment, the terminal device as above, the at least one processor is configured to cause the terminal device to: in accordance with at least one of the following conditions is met, determine the OCC unit: a size of the UCI is smaller than or not larger than a first threshold, an MCS of the UCI is lower than that of the uplink data, or a priority of the UCI is higher than that of the uplink data.

[0207] In one embodiment, the terminal device as above, the UCI comprises at least one of: HARQ-ACK, CSI part 1, CSI part 2, or SR.

[0208] The present disclosure provides a network device, comprising at least one processor configured to cause the network device at least to: receive, from a terminal device, a PUSCH comprising encoded code words based on an OCC-based PUSCH configuration; and decode the encoded code words to obtain a UCI and uplink data which are encoded together.

[0209] In one embodiment, the network device as above, the at least one processor is configured to cause the network device to: transmit, to a group of terminal devices, the OCC-based PUSCH configuration, wherein the OCC-based PUSCH configuration indicates that the group of terminal devices should perform a PUSCH transmission with OCC on a same physical resource.

[0210] In one embodiment, the network device as above, the at least one processor is configured to cause the network device to: transmit, to the terminal device, concatenated coding parameters by at least one of: DCI, MAC CE, or RRC signalling, wherein the concatenated coding parameters comprise first coding information for encoding the UCI independently.

[0211] In one embodiment, the network device as above, the concatenated coding parameters comprise second coding information for encoding the UCI and the uplink data together.

[0212] In one embodiment, the network device as above, the at least one processor is configured to cause the network device to: transmit, to the terminal device, channel coding parameters for PUSCH comprising second coding information for encoding the UCI and the uplink data together.

[0213] In one embodiment, the network device as above, the concatenated coding parameters comprise at least one of: an indication indicating that a concatenated coding is enabled, a concatenated coding manner, a concatenated coding scheme, a coding length, or a coding rate.

[0214] In one embodiment, the network device as above, the second coding information comprises: a first set of parameters for a size of the UCI being smaller than a second threshold, a second set of parameters for a size of the UCI being not smaller than the second threshold and not larger than a first threshold, or a third set of parameters for a size of the UCI being larger than the first threshold.

[0215] In one embodiment, the network device as above, the UCI comprises at least one of: HARQ-ACK, CSI part 1, CSI part 2, or SR.

[0216] In one embodiment, the network device as above, at least one of the following conditions is met: a size of the UCI is larger than or not smaller than a first threshold, a size of the UCI is in a range from a second threshold to the first threshold, an MCS of the UCI is same as that of the uplink data, or a priority of the UCI is lower than that of the uplink data.

[0217] The present disclosure provides a network device, comprising at least one processor configured to cause the network device at least to: receive, from a terminal device, a PUSCH comprising multiplexed UCI and uplink data based on an OCC-based PUSCH configuration; and decode the PUSCH to obtain the UCI and the uplink data which are multiplexed for a plurality of PUSCH repetitions within an OCC unit, wherein the OCC unit is determined based on: an actual TDW, an OCC length, and a length of a PUSCH repetition.

[0218] In one embodiment, the network device as above, the at least one processor is configured to cause the network device to: in accordance with a determination that a first function of an actual TDW, an OCC length, and the length of the PUSCH repetition is satisfied, determine the OCC unit based on a second function of the actual TDW, the OCC length, and the length of the PUSCH repetition.

[0219] In one embodiment, the network device as above, the length of the PUSCH repetition is determined based on a predefined parameter and a length of a slot.

[0220] In one embodiment, the network device as above, the OCC comprises an inter-slot level OCC, and the predefined parameter is associated with a number of slots used for TBS determination.

[0221] In one embodiment, the network device as above, the OCC comprises an inter-symbols level OCC, and the predefined parameter is 0.5 for a coverage-limited scenario or is less than 0.5 for a good coverage scenario.

[0222] In one embodiment, the network device as above, the OCC comprises an inter-symbols level OCC, and the OCC-based PUSCH configuration indicates that the length of the PUSCH repetition is 7 symbols.

[0223] In one embodiment, the network device as above, the OCC comprises an inter-symbols level OCC, and the OCC-based PUSCH configuration indicates that a starting symbol for a first DMRS of the PUSCH is with a specific symbol index.

[0224] In one embodiment, the network device as above, the at least one processor is configured to cause the network device to: transmit, to a group of terminal devices, the OCC- based PUSCH configuration, wherein the OCC-based PUSCH configuration indicates that the group of terminal devices should perform a PUSCH transmission with OCC on a same physical resource.

[0225] In one embodiment, the network device as above, the OCC comprises an inter-symbols level OCC, and wherein the at least one processor is configured to cause the network device to: de-interleave an order of symbols in a slot unit based on a mapping from symbols in the first half of the slot to a second half of the slot in a mirrored manner.

[0226] In one embodiment, the network device as above, the UCI comprises at least one of: HARQ-ACK, CSI part 1, CSI part 2, or SR.

[0227] The present disclosure provides a method of communication, comprising the operations implemented at the terminal device or at a network device discussed above.

[0228] The present disclosure provides a terminal device, comprising: a processor; and a memory storing computer program codes; the memory and the computer program codes configured to, with the processor, cause the terminal device to perform the method implemented at the terminal device discussed above.

[0229] The present disclosure provides a network device, comprising: a processor; and a memory storing computer program codes; the memory and the computer program codes configured to, with the processor, cause the network device to perform the method implemented at the network device discussed above.

[0230] The present disclosure provides a non-transitory computer readable medium having instructions stored thereon, the instructions, when executed by a processor of an apparatus, causing the apparatus to perform the method implemented at a terminal device or at a network device discussed above.

[0231] Generally, various embodiments of the present disclosure may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. Some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device. While various aspects of embodiments of the present disclosure are illustrated and described as block diagrams, flowcharts, or using some other pictorial representation, it will be appreciated that the blocks, apparatus, systems, techniques or methods described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller  or other computing devices, or some combination thereof.

[0232] The present disclosure also provides at least one computer program product tangibly stored on a non-transitory computer readable storage medium. The computer program product includes computer-executable instructions, such as those included in program modules, being executed in a device on a target real or virtual processor, to carry out the process or method as described above. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, or the like that perform particular tasks or implement particular abstract data types. The functionality of the program modules may be combined or split between program modules as desired in various embodiments. Machine-executable instructions for program modules may be executed within a local or distributed device. In a distributed device, program modules may be located in both local and remote storage media.

[0233] Program code for carrying out methods of the present disclosure may be written in any combination of one or more programming languages. These program codes may be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the program codes, when executed by the processor or controller, cause the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code 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.

[0234] The above program code may be embodied on a machine readable medium, which 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 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.

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

[0236] Although the present disclosure has been described in language specific to structural features and / or methodological acts, it is to be understood that the present disclosure defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

1.A terminal device comprising at least one processor configured to cause the terminal device to:in accordance with a determination that uplink control information (UCI) needs to be multiplexed on a physical uplink shared channel (PUSCH) with uplink data and orthogonal cover code (OCC) parameters are configured, encode the UCI with the uplink data together to generate encoded code words; andtransmit, to a network device, the PUSCH comprising the encoded code words based on an OCC-based PUSCH configuration.2.The terminal device of claim 1, wherein the at least one processor is configured to cause the terminal device to encode the UCI with the uplink data together by:encoding the UCI independently using first coding information to generate an encoded UCI; andencoding the encoded UCI and the uplink data together using second coding information.3.The terminal device of claim 2, wherein the at least one processor is configured to cause the terminal device to:receive, from the network device, concatenated coding parameters by at least one of: downlink control information (DCI) , a medium access control (MAC) control element (CE) , or radio resource control (RRC) signalling, wherein the concatenated coding parameters comprise the first coding information.4.The terminal device of claim 3, wherein the second coding information is comprised in channel coding parameters for PUSCH or in the concatenated coding parameters.5.The terminal device of claim 3, wherein the concatenated coding parameters comprise at least one of:an indication indicating that a concatenated coding is enabled,a concatenated coding manner,a concatenated coding scheme,a coding length, ora coding rate.6.The terminal device of claim 2, wherein the second coding information comprises:a first set of parameters for a size of the UCI being smaller than a second threshold,a second set of parameters for a size of the UCI being not smaller than the second threshold and not larger than a first threshold, ora third set of parameters for a size of the UCI being larger than the first threshold.7.The terminal device of claim 1, wherein the at least one processor is configured to cause the terminal device to:receive, from the network device, the OCC-based PUSCH configuration, wherein the OCC-based PUSCH configuration indicates that a group of terminal devices should perform a PUSCH transmission with OCC on a same physical resource.8.The terminal device of claim 1, wherein the at least one processor is configured to cause the terminal device to:in accordance with at least one of the following conditions is met, encode the UCI with the uplink data together:a size of the UCI is larger than or not smaller than a first threshold,a size of the UCI is in a range from a second threshold to the first threshold,a modulation and coding scheme (MCS) of the UCI is same as that of the uplink data, ora priority of the UCI is lower than that of the uplink data.9.The terminal device of claim 1, wherein the UCI comprises at least one of: hybrid automatic repeat request acknowledgement (HARQ-ACK) , channel state information (CSI) part 1, CSI part 2, or a scheduling request (SR) .10.A terminal device comprising at least one processor configured to cause the terminal device to:in accordance with a determination that uplink control information (UCI) needs to be multiplexed on a physical uplink shared channel (PUSCH) with uplink data and orthogonal cover code (OCC) parameters are configured, determine an OCC unit based on an actual time domain window (TDW) , an OCC length, and a length of a PUSCH repetition;multiplex the UCI with the uplink data for a plurality of PUSCH repetitions within the OCC unit; andtransmit, to a network device, the PUSCH comprising multiplexed UCI and uplink data based on an OCC-based PUSCH configuration.11.The terminal device of claim 10, wherein the at least one processor is configured to cause the terminal device to determine the OCC unit by:in accordance with a determination that a first function of the actual TDW, the OCC length, and the length of the PUSCH repetition is satisfied, determining the OCC unit based on a second function of the actual TDW, the OCC length, and the length of the PUSCH repetition.12.The terminal device of claim 10, wherein the length of the PUSCH repetition is determined based on a predefined parameter and a length of a slot.13.The terminal device of claim 12, wherein the OCC comprises an inter-slot level OCC, and the predefined parameter is associated with a number of slots used for transport block size (TBS) determination.14.The terminal device of claim 12, wherein the OCC comprises an inter-symbols level OCC, and the predefined parameter is 0.5 for a coverage-limited scenario or is less than 0.5 for a good coverage scenario.15.The terminal device of claim 10, wherein the OCC comprises an inter-symbols level OCC, and the OCC-based PUSCH configuration indicates that the length of the PUSCH repetition is 7 symbols.16.The terminal device of claim 10, wherein the OCC comprises an inter-symbols level OCC, and the OCC-based PUSCH configuration indicates that a starting symbol for a first demodulation reference signal (DMRS) of the PUSCH is with a specific symbol index.17.The terminal device of claim 10, wherein the OCC comprises an inter-symbols  level OCC, and wherein the at least one processor is configured to cause the terminal device to multiplex the UCI with the uplink data by:multiplexing the UCI with the uplink data in a first half of a slot; andmapping symbols in the first half of the slot to a second half of the slot in a mirrored manner.18.The terminal device of claim 10, wherein the at least one processor is configured to cause the terminal device to:receive, from the network device, the OCC-based PUSCH configuration, wherein the OCC-based PUSCH configuration indicates that a group of terminal devices should perform a PUSCH transmission with OCC on a same physical resource.19.The terminal device of claim 10, wherein the at least one processor is configured to cause the terminal device to:in accordance with at least one of the following conditions is met, determine the OCC unit:a size of the UCI is smaller than or not larger than a first threshold,a modulation and coding scheme (MCS) of the UCI is lower than that of the uplink data, ora priority of the UCI is higher than that of the uplink data.20.The terminal device of claim 10, wherein the UCI comprises at least one of: hybrid automatic repeat request acknowledgement (HARQ-ACK) , channel state information (CSI) part 1, CSI part 2, or a scheduling request (SR) .21.A method for communication, comprising:in accordance with a determination that uplink control information (UCI) needs to be multiplexed on a physical uplink shared channel (PUSCH) with uplink data and orthogonal cover code (OCC) parameters are configured, encoding, at a terminal device, the UCI with the uplink data together to generate encoded code words; andtransmitting, to a network device, the PUSCH comprising the encoded code words based on an OCC-based PUSCH configuration.22.A method for communication, comprising:in accordance with a determination that uplink control information (UCI) needs to be multiplexed on a physical uplink shared channel (PUSCH) with uplink data and orthogonal cover code (OCC) parameters are configured, determining, at a terminal device, an OCC unit based on an actual time domain window (TDW) , an OCC length, and a length of a PUSCH repetition;multiplexing the UCI with the uplink data for a plurality of PUSCH repetitions within the OCC unit; andtransmitting, to a network device, the PUSCH comprising multiplexed UCI and uplink data based on an OCC-based PUSCH configuration.

Images