Wireless communication method and related products

Abstract

Provided are a wireless communication method and related products. The method includes: receiving, by a terminal device, first downlink control information (DCI) from a network device, where the first DCI is indicative of whether joint coding is enabled for first data and is indicative of scheduling information of the first data; receiving, by the terminal device, the first data from the network device according to the first DCI; performing, by the terminal device, decoding on the received first data according to the first DCI. With the wireless communication method and related products of the present disclosure, a success rate of decoding of the first data and reliability thereof can be improved and a code rate can be reduced, resulting in an improved performance.

Description

WIRELESS COMMUNICATION METHOD AND RELATED PRODUCTS

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to US provisional patent application No. 63 / 505, 555 entitled “HARQ PROCEDURE FOR MIXED TRAFFIC” and filed on June 01, 2023, which is hereby incorporated by reference in its entirety.TECHNICAL FIELD

[0003] The present disclosure relates generally to the field of communication technologies and, in particular, to wireless communication methods and related products.BACKGROUND

[0004] Resilience is a fundamental feature that needs to be addressed in a sixth generation (6G) mobile communications technology. Two trends are observed toward 6G. From the technological perspective, mmWave and massive multiple-input multiple-output (MIMO) will be more prevalent because they can significantly expand the current bandwidth resource. From the service perspective, a single device will need to support multiple services with different latency and reliability requirements.

[0005] A potential scenario emerges as multiple services converges into one physical wireless link. The purpose is to deliver multiple quality of service (QoS) to multiple services within one wireless link. Given the high carrier frequency and massive antennas, beamforming can be done more aggressively, enabling the convergence of multiple services in one wireless link. Meanwhile, these services may have very diverse key performance indicators (KPIs) . This is challenging because different KPIs must be supported under the same wireless channel.

[0006] This background information is provided to reveal information believed by the applicant to be of possible relevance to the present disclosure. No admission is necessarily intended, nor should be construed, that any of the  preceding information constitutes prior art against the present disclosure.SUMMARY

[0007] In a first aspect, an embodiment of the present disclosure provides a wireless communication method, where the method includes:

[0008] receiving, by a terminal device, first downlink control information (DCI) from a network device, where the first DCI is indicative of whether joint coding is enabled for first data and is indicative of scheduling information of the first data;

[0009] receiving, by the terminal device, the first data from the network device according to the first DCI;

[0010] performing, by the terminal device, decoding on the received first data according to the first DCI.

[0011] Since joint coding can be enabled and whether the joint coding is enabled for the first data is indicated, a success rate of decoding of the first data and reliability thereof can be improved and a code rate can be reduced, resulting in an improved performance.

[0012] In a possible implementation of the first aspect, in a case that the first DCI is indicative of the joint coding being enabled for the first data, the first data includes a first data portion and a second data portion, and the joint coding is enabled for the first data portion and at least part of the second data portion;

[0013] in a case that the first DCI is indicative of the joint coding being not enabled for the first data, the first data includes one or multiple data portions which are separately coded by the network device.

[0014] By considering different cases of whether the joint coding is enabled or not, the different cases can be indicated to the terminal device and flexible scheduling for the different cases can be realized.

[0015] In a possible implementation of the first aspect, the scheduling information is indicative of a first HARQ process identity (ID) and first decoding information for the first data portion, and a second HARQ process ID and second decoding information for the second data portion.

[0016] Separate HARQ processes can be used for the two data portions subject to the joint coding, thus more flexible scheduling and more accurate feedback can be realized for respective data portions.

[0017] In a possible implementation of the first aspect, the first DCI includes a first HARQ-related field and a second HARQ-related field, and the second HARQ-related field includes M HARQ-related subfields, where a value of M is configured by the network device or is predefined; the first HARQ process ID and the first decoding information for the first data portion are carried in the first HARQ-related field;

[0018] in a case that spatial multiplexing is enabled for the second data portion, the second HARQ process ID and decoding information of the second data portion are carried in the M HARQ-related subfields; in a case that spatial multiplexing is not enabled for the second data portion, the second HARQ process ID and decoding information of the second data portion are carried in a predefined HARQ-related subfield among the M HARQ-related subfields.

[0019] In a possible implementation of the first aspect, a HARQ process ID and decoding information of the one or multiple data portions are carried in the first HARQ-related field and / or the second HARQ-related field based on a predefined rule or a radio resource control (RRC) configuration.

[0020] Scheduling information is provided by respective fields in the first DCI, which can support not only different cases of whether the joint coding is enabled or not, but also different cases of whether spatial multiplexing is enabled or not, thereby further improving flexibility of scheduling.

[0021] In a possible implementation of the first aspect, the first DCI further includes a joint coding indication field for indicating whether the joint coding is enabled for the first data.

[0022] Indication of whether the joint coding is enabled can be implemented explicitly by the joint coding indication field in the first DCI, the terminal device can learn whether the joint coding is enabled faster and easier, thereby improving efficiency of decoding.

[0023] In a possible implementation of the first aspect, the scheduling information is indicative of a third HARQ process ID for the first data portion and the second data portion, first decoding information for the first data portion and second decoding information for the second data portion.

[0024] A shared HARQ process can be used for the two data portions subject to the joint coding, thus more convenient scheduling and reduced signaling can be realized.

[0025] In a possible implementation of the first aspect, the first DCI includes a third HARQ process field, a fifth HARQ-related field and a sixth HARQ-related field; the third HARQ process ID is carried in the third HARQ process field; first decoding information for the first data portion is carried in the fifth HARQ-related field and second decoding information for the second data portion is carried in the sixth HARQ-related field.

[0026] In a possible implementation of the first aspect, decoding information of the one or multiple data portions are carried in the fifth HARQ-related field and / or the sixth HARQ-related field based on a predefined rule or an RRC configuration.

[0027] Scheduling information is provided by respective fields in the first DCI, which can support different  cases of whether the joint coding is enabled or not, thereby further improving flexibility of scheduling.

[0028] In a possible implementation of the first aspect, the one or multiple data portions include a third data portion and a fourth data portion; both of the third data portion and the fourth data portion use the third HARQ process ID; or, the third data portion uses the third HARQ process ID, and the fourth portion uses a fourth HARQ process ID determined based on the third HARQ process ID.

[0029] For the case where the joint coding is not enabled, separate HARQ processes or a shared HARQ process can be used for the data portions, thus more flexible scheduling and reduced signaling can be realized.

[0030] In a possible implementation of the first aspect, the joint coding is enabled for the first data portion and the second data portion; the scheduling information of the first data is indicative of a joint HARQ process ID and joint decoding information for the first data.

[0031] In this implementation, the joint coding can be enabled by multiplexing information bits of the two data portions in a MAC layer and a joint HARQ process ID and joint decoding information can be indicated, which can reduce the re-design complexity of the physical layer for joint coding.

[0032] In a possible implementation of the first aspect, the scheduling information of the first data is indicative of skipping feedback of the first data portion of the first data and performing feedback on the second data portion of the first data by the terminal device.

[0033] In this implementation, the network device can assume that the first data portion is successfully decoded by self-decoding and joint decoding, thus HARQ feedback procedure and related signaling for the joint coding can be simplified.

[0034] In a possible implementation of the first aspect, the scheduling information of the first data is indicative of performing feedback on both of the first data portion of the first data and the second data portion of the first data by the terminal device.

[0035] In a possible implementation of the first aspect, the scheduling information of the first data is indicative of respective feedback resource information and respective feedback timing information for the first data portion of the first data and the second data portion of the first data.

[0036] By providing feedback for both of the first data portion and the second data portion, accuracy of HARQ feedback can be ensured. Further, by allowing the first data portion and the second data portion to provide feedback at respective timings, faster HARQ feedback for one of them can be realized.

[0037] In a possible implementation of the first aspect, the performing, by the terminal device, decoding on the  received first data according to the first DCI includes: performing, by the terminal device, self-decoding on the first data portion according to the first DCI; performing, by the terminal device, joint decoding on the first data according to a self-decoding result of the first data portion and the first DCI.

[0038] By using self-decoding and joint-decoding, a success rate of decoding of the two data portions and reliability thereof can be improved.

[0039] In a possible implementation of the first aspect, the receiving, by the terminal device, the first data from the network device according to the first DCI includes: receiving, by the terminal device, the first data on a physical downlink shared channel (PDSCH) scheduled by the first DCI; and the method further includes: sending, by the terminal device, a first physical uplink control channel (PUCCH) carrying a result of PDSCH processing for the first data portion; sending, by the terminal device, a second PUCCH carrying a result of PDSCH processing for the second data portion.

[0040] In a possible implementation of the first aspect, the second data portion of the first data includes an initial part and a remaining part, and the joint coding is enabled for the first data portion and the initial part of the second data portion; where the sending of the first PUCCH starts not earlier than first processing time after an end of a time unit of the initial part, and the sending of the second PUCCH starts not earlier than second processing time after an end of a time unit of the remaining part, or, not earlier than third processing time after the end of the time unit of the remaining part, where the third processing time equals to the second processing time plus a time offset; where the first processing time and / or the second processing time is reported by the terminal device to the network device or is predefined.

[0041] A HARQ procedure and related scheduling are provided for scenarios involving the joint coding, and PDSCH processing delay is considered, thus accuracy and reliability of HARQ ACK / NACK feedback can be ensured.

[0042] In a possible implementation of the first aspect, the first data portion has a smaller payload size than the second data portion.

[0043] By using self-decoding and joint-decoding for the first data portion with smaller payload size and joint-decoding, a success rate of decoding and reliability of the first data portion can be improved.

[0044] In a possible implementation of the first aspect, the method further includes: receiving, by the terminal device, second DCI from the network device, where the second DCI is used for scheduling a physical uplink shared channel (PUSCH) ; sending, by the terminal device, the PUSCH to the network device according to a processing  capability of joint coding for data to be transmitted on the PUSCH and the second DCI.

[0045] By considering the processing capability of the terminal device, the processing delay for PUSCH processing under the scenario of joint coding can be considered, thereby ensuring accuracy and reliability of the PUSCH transmission.

[0046] In a possible implementation of the first aspect, the processing capability includes first preparing time for joint coding and second preparing time for non-joint coding;

[0047] in a case that the joint coding is enabled for the data to be transmitted on the PUSCH, the sending of the PUSCH starts not earlier than the first preparing time after an end of a time unit of the second DCI;

[0048] in a case that the joint coding is not enabled for the data to be transmitted on the PUSCH, the sending of the PUSCH starts not earlier than the second preparing time after the end of the time unit of the second DCI.

[0049] In a possible implementation of the first aspect, the processing capability includes a first time offset for joint coding and a second time offset for non-joint coding;

[0050] in a case that the joint coding is enabled for the data to be transmitted on the PUSCH, the sending of the PUSCH starts not earlier than first preparing time after an end of a time unit of the second DCI, where the first preparing time equals to a predefined preparing time plus the first time offset;

[0051] in a case that the joint coding is not enabled for the data to be transmitted on the PUSCH, the sending of the PUSCH starts not earlier than second preparing time after the end of the time unit of the second DCI, where the second preparing time equals to the predefined preparing time plus the second time offset.

[0052] By providing solutions for the processing delay for PUSCH processing, accuracy and reliability of the PUSCH transmission can be ensured.

[0053] In a second aspect, an embodiment of the present disclosure provides a wireless communication method, where the method includes:

[0054] sending, by a network device, first downlink control information (DCI) to a terminal device, where the first DCI is indicative of whether joint coding is enabled for first data and is indicative of scheduling information of the first data;

[0055] sending, by the network device, the first data to the terminal device, to enable the terminal device to perform decoding on the first data according to the first DCI.

[0056] Since joint coding can be enabled and whether the joint coding is enabled for the first data is indicated, a success rate of decoding of the first data and reliability thereof can be improved and a code rate can be reduced,  resulting in an improved performance.

[0057] In a possible implementation of the second aspect, the method further includes:

[0058] performing, by the network device, joint coding on a first data portion and at least part of a second data portion to generate the first data including the first data portion and the second data portion, where the first DCI is indicative of the joint coding being enabled for the first data; or

[0059] performing, by the network device, coding on one or multiple data portions separately to generate the first data including the one or multiple data portions, where the first DCI is indicative of the joint coding being not enabled for the first data.

[0060] By considering different cases of whether the joint coding is enabled or not, the different cases can be indicated to the terminal device and flexible scheduling for the different cases can be realized.

[0061] In a possible implementation of the second aspect, the scheduling information is indicative of a first HARQ process identity (ID) and first decoding information for the first data portion, and a second HARQ process ID and second decoding information for the second data portion.

[0062] Separate HARQ processes can be used for the two data portions subject to the joint coding, thus more flexible scheduling and more accurate feedback can be realized for respective data portions.

[0063] In a possible implementation of the second aspect, the first DCI includes a first HARQ-related field and a second HARQ-related field, and the second HARQ-related field includes M HARQ-related subfields, where a value of M is configured by the network device or is predefined; the first HARQ process ID and the first decoding information for the first data portion are carried in the first HARQ-related field;

[0064] in a case that spatial multiplexing is enabled for the second data portion, the second HARQ process ID and decoding information of the second data portion are carried in the M HARQ-related subfields; in a case that spatial multiplexing is not enabled for the second data portion, the second HARQ process ID and decoding information of the second data portion are carried in a predefined HARQ-related subfield among the M HARQ-related subfields.

[0065] In a possible implementation of the second aspect, a HARQ process ID and decoding information of the one or multiple data portions are carried in the first HARQ-related field and / or the second HARQ-related field based on a predefined rule or a radio resource control (RRC) configuration.

[0066] Scheduling information is provided by respective fields in the first DCI, which can support not only different cases of whether the joint coding is enabled or not, but also different cases of whether spatial multiplexing  is enabled or not, thereby further improving flexibility of scheduling.

[0067] In a possible implementation of the second aspect, the first DCI further includes a joint coding indication field for indicating whether the joint coding is enabled for the first data.

[0068] Indication of whether the joint coding is enabled can be implemented explicitly by the joint coding indication field in the first DCI, the terminal device can learn whether the joint coding is enabled faster and easier, thereby improving efficiency of decoding.

[0069] In a possible implementation of the second aspect, the scheduling information is indicative of a third HARQ process ID for the first data portion and the second data portion, first decoding information for the first data portion and second decoding information for the second data portion.

[0070] A shared HARQ process can be used for the two data portions subject to the joint coding, thus more convenient scheduling and reduced signaling can be realized.

[0071] In a possible implementation of the second aspect, the first DCI includes a third HARQ process field, a fifth HARQ-related field and a sixth HARQ-related field; the third HARQ process ID is carried in the third HARQ process field; first decoding information for the first data portion is carried in the fifth HARQ-related field and second decoding information for the second data portion is carried in the sixth HARQ-related field.

[0072] In a possible implementation of the second aspect, decoding information of the one or multiple data portions are carried in the fifth HARQ-related field and / or the sixth HARQ-related field based on a predefined rule or an RRC configuration.

[0073] Scheduling information is provided by respective fields in the first DCI, which can support different cases of whether the joint coding is enabled or not, thereby further improving flexibility of scheduling.

[0074] In a possible implementation of the second aspect, the one or multiple data portions include a third data portion and a fourth data portion; the third HARQ process ID is scheduled by the network device for both of the third data portion and the fourth data portion; or, the third HARQ process ID is scheduled by the network device for the third data portion, and a fourth HARQ process ID for the fourth portion is determined based on the third HARQ process ID.

[0075] For the case where the joint coding is not enabled, separate HARQ processes or a shared HARQ process can be used for the data portions, thus more flexible scheduling and reduced signaling can be realized.

[0076] In a possible implementation of the second aspect, the performing, by the network device, joint coding on the first data portion and at least part of the second data portion includes: performing, by the network device, joint  coding on the first data portion and the second data portion; where the scheduling information of the first data is indicative of a joint HARQ process ID and joint decoding information for the first data.

[0077] In this implementation, the joint coding can be enabled by multiplexing information bits of the two data portions in a MAC layer and a joint HARQ process ID and joint decoding information can be indicated, which can reduce the re-design complexity of the physical layer for joint coding.

[0078] In a possible implementation of the second aspect, the scheduling information of the first data is indicative of skipping feedback of the first data portion of the first data and performing feedback on the second data portion of the first data by the terminal device.

[0079] In this implementation, the network device can assume that the first data portion is successfully decoded by self-decoding and joint decoding, thus HARQ feedback procedure and related signaling for the joint coding can be simplified.

[0080] In a possible implementation of the second aspect, the scheduling information of the first data is indicative of performing feedback on both of the first data portion of the first data and the second data portion of the first data by the terminal device.

[0081] In a possible implementation of the second aspect, the scheduling information of the first data is indicative of respective feedback resource information and respective feedback timing information for the first data portion of the first data and the second data portion of the first data.

[0082] By providing feedback for both of the first data portion and the second data portion, accuracy of HARQ feedback can be ensured. Further, by allowing the first data portion and the second data portion to provide feedback at respective timings, faster HARQ feedback for one of them can be realized.

[0083] In a possible implementation of the second aspect, the first data portion is self-decodable by the terminal device according to the first DCI, and the first data is jointly-decodable by the terminal device according to a self-decoding result of the first data portion and the first DCI.

[0084] By using self-decoding and joint-decoding, a success rate of decoding of the two data portions and reliability thereof can be improved.

[0085] In a possible implementation of the second aspect, the second data portion of the first data includes an initial part and a remaining part; the performing, by the network device, joint coding on the first data portion and at least part of the second data portion includes: performing, by the network device, joint coding on the first data portion and the initial part of the second data portion; the sending, by the network device, the first data to the terminal device  includes: sending, by the network device, the first data to the terminal device on a physical downlink shared channel (PDSCH) scheduled by the first DCI.

[0086] In a possible implementation of the second aspect, the method further includes: receiving, by the network device, a first physical uplink control channel (PUCCH) which carries a result of PDSCH processing for the first data portion and is sent by the terminal device; receiving, by the network device, a second PUCCH which carries a result of PDSCH processing for the second data portion and is sent by the terminal device; where sending of the first PUCCH by the terminal device starts not earlier than first processing time after an end of a time unit of the initial part, and sending of the second PUCCH by the terminal device starts not earlier than second processing time after an end of a time unit of the remaining part, or, not earlier than third processing time after the end of the time unit of the remaining part, where the third processing time equals to the second processing time plus a time offset; where the first processing time and / or the second processing time is reported by the terminal device to the network device or is predefined.

[0087] A HARQ procedure and related scheduling are provided for scenarios involving the joint coding, and PDSCH processing delay is considered, thus accuracy and reliability of HARQ ACK / NACK feedback can be ensured.

[0088] In a possible implementation of the second aspect, the first data portion has a smaller payload size than the second data portion.

[0089] By using self-decoding and joint-decoding for the first data portion with smaller payload size and joint-decoding, a success rate of decoding and reliability of the first data portion can be improved.

[0090] In a possible implementation of the second aspect, the method further includes: sending, by the network device, second DCI to the terminal device, where the second DCI is used for scheduling a physical uplink shared channel (PUSCH) ; receiving, by the network device, the PUSCH sent by the terminal device according to a processing capability of joint coding for data to be transmitted on the PUSCH and the second DCI.

[0091] By considering the processing capability of the terminal device, the processing delay for PUSCH processing under the scenario of joint coding can be considered, thereby ensuring accuracy and reliability of the PUSCH transmission.

[0092] In a possible implementation of the second aspect, before sending, by the network device, the second DCI to the terminal device, the method further includes: receiving, by the network device, the processing capability reported by the terminal device; determining, by the network device, time for scheduling the PUSCH according to  the reported processing capability.

[0093] By reporting the processing capability of the terminal device to the network device, the network device can determine the time for scheduling the PUSCH according to the reported processing capability. In this way, the processing delay for PUSCH processing under the scenario of joint coding can be considered based on the processing capability, thereby ensuring accuracy and reliability of the PUSCH transmission.

[0094] In a possible implementation of the second aspect, the processing capability includes first preparing time for joint coding and second preparing time for non-joint coding;

[0095] in a case that the joint coding is enabled for the data to be transmitted on the PUSCH, the sending of the PUSCH by the terminal device starts not earlier than the first preparing time after an end of a time unit of the second DCI;

[0096] in a case that the joint coding is not enabled for the data to be transmitted on the PUSCH, the sending of the PUSCH by the terminal device starts not earlier than the second preparing time after the end of the time unit of the second DCI.

[0097] In a possible implementation of the second aspect, the processing capability includes a first time offset for joint coding and a second time offset for non-joint coding;

[0098] in a case that the joint coding is enabled for the data to be transmitted on the PUSCH, the sending of the PUSCH by the terminal device starts not earlier than first preparing time after an end of a time unit of the second DCI, where the first preparing time equals to a predefined preparing time plus the first time offset;

[0099] in a case that the joint coding is not enabled for the data to be transmitted on the PUSCH, the sending of the PUSCH by the terminal device starts not earlier than second preparing time after the end of the time unit of the second DCI, where the second preparing time equals to the predefined preparing time plus the second time offset.

[0100] By providing solutions for the processing delay for PUSCH processing, accuracy and reliability of the PUSCH transmission can be ensured.

[0101] In a third aspect, an embodiment of the present disclosure provides a wireless communication apparatus, the apparatus includes various modules configured to execute the wireless communication method according to the first aspect or any possible implementation of the first aspect.

[0102] In a fourth aspect, an embodiment of the present disclosure provides a wireless communication apparatus, the apparatus includes various modules configured to execute the wireless communication method according to the second aspect or any possible implementation of the second aspect.

[0103] In a fifth aspect, an embodiment of the present disclosure provides a terminal device including processing circuitry for executing the wireless communication method according to the first aspect or any possible implementation of the first aspect.

[0104] In a sixth aspect, an embodiment of the present disclosure provides a network device including processing circuitry for executing the wireless communication method according to the second aspect or any possible implementation of the second aspect.

[0105] In a seventh aspect, an embodiment of the present disclosure provides a wireless communication system, including the terminal device according to the fifth aspect and the network device according to the sixth aspect.

[0106] In an eighth aspect, an embodiment of the present disclosure provides a computer-readable medium storing computer execution instructions which, when executed by a processor, causes the processor to execute the wireless communication method according to the first aspect or any possible implementation of the first aspect or according to the second aspect or any possible implementation of the second aspect.

[0107] In a ninth aspect, an embodiment of the present disclosure provides a computer program product including computer execution instructions which, when executed by a processor, causes the processor to execute the wireless communication method according to the first aspect or any possible implementation of the first aspect or according to the second aspect or any possible implementation of the second aspect.

[0108] The present disclosure provides a wireless communication method and related products. The joint coding can be enabled for first data on a PDSCH or data to be transmitted on a PUSCH and the jointly-coded data can be scheduled by first DCI or second DCI, a success rate of decoding of the data and reliability thereof can be improved and a code rate can be reduced, resulting in an improved performance. In addition, a HARQ procedure and related scheduling are provided for scenarios involving the joint coding, accuracy and reliability of HARQ ACK / NACK feedback can be ensured. Further, by providing solutions for the processing delay for PUSCH processing, accuracy and reliability of the PUSCH transmission can be ensured.BRIEF DESCRIPTION OF DRAWINGS

[0109] Reference will now be made, by way of example, to the accompanying drawings which show example embodiments of the present disclosure, and in which:

[0110] FIG. 1 is a simplified schematic illustration of a communication system according to one or more embodiments of the present disclosure.

[0111] FIG. 2 is a schematic illustration of an example communication system according to one or more embodiments of the present disclosure.

[0112] FIG. 3 is a schematic illustration of a basic component structure of a communication system according to one or more embodiments of the present disclosure.

[0113] FIG. 4 illustrates a block diagram of a device in a communication system according to one or more embodiments of the present disclosure.

[0114] FIG. 5 is a schematic illustration of a 6G multi-service scenario according to one or more embodiments of the present disclosure.

[0115] FIG. 6a and FIG. 6b are schematic illustrations of self-decoding and joint-decoding according to one or more embodiments of the present disclosure.

[0116] FIG. 7 is a schematic illustration of joint coding according to one or more embodiments of the present disclosure.

[0117] FIG. 8 is another schematic illustration of joint coding according to one or more embodiments of the present disclosure.

[0118] FIG. 9 is a schematic flowchart of a wireless communication method according to one or more embodiments of the present disclosure.

[0119] FIG. 10 is a schematic flowchart of another wireless communication method according to one or more embodiments of the present disclosure.

[0120] FIG. 11 is a schematic flowchart of still another wireless communication method according to one or more embodiments of the present disclosure.

[0121] FIG. 12 is a schematic diagram of an example of joint coding according to one or more embodiments of the present disclosure.

[0122] FIG. 13 is a schematic diagram of an example of joint coding with separate HARQ processes according to one or more embodiments of the present disclosure.

[0123] FIG. 14 is a schematic diagram of another example of joint coding according to one or more embodiments of the present disclosure.

[0124] FIG. 15 is a schematic diagram of still another example of joint coding according to one or more embodiments of the present disclosure.

[0125] FIG. 16 is a schematic diagram of yet another example of joint coding according to one or more  embodiments of the present disclosure.

[0126] FIG. 17 is a schematic diagram of an example of HARQ ACK / NACK feedback for joint coding according to one or more embodiments of the present disclosure.

[0127] FIG. 18 is a schematic flowchart of yet another wireless communication method according to one or more embodiments of the present disclosure.

[0128] FIG. 19 is a schematic diagram of an example of PDSCH processing for joint coding according to one or more embodiments of the present disclosure.

[0129] FIG. 20 is a schematic flowchart of a wireless communication method for PUSCH transmission according to one or more embodiments of the present disclosure.

[0130] FIG. 21 is a schematic diagram of an example of PUSCH processing according to one or more embodiments of the present disclosure.

[0131] FIG. 22 is a schematic structural diagram of a wireless communication apparatus according to one or more embodiments of the present disclosure.

[0132] FIG. 23 is a schematic structural diagram of another wireless communication apparatus according to one or more embodiments of the present disclosure.DESCRIPTION OF EMBODIMENTS

[0133] In the following description, reference is made to the accompanying figures, which form part of the present disclosure, and which show, by way of illustration, specific aspects of embodiments of the present disclosure or specific aspects in which embodiments of the present disclosure may be used. It is understood that embodiments of the present disclosure may be used in other aspects and include structural or logical changes not depicted in the figures. The following detailed description, therefore, is not to be taken in a limiting sense, and the scope of the present disclosure is defined by the appended claims.

[0134] To assist in understanding the present disclosure, examples of wireless communication systems and devices are described below.

[0135] Example communication systems and devices

[0136] Referring to FIG. 1, as an illustrative example without limitation, a simplified schematic illustration of a communication system is provided. The communication system 100 includes a radio access network 120. The radio access network 120 may be a next generation (e.g., sixth generation (6G) or later) radio access network, or a legacy  (e.g., 5G, 4G, 3G or 2G) radio access network. One or more communication electric device (ED) 110a-120j (generically referred to as 110) may be interconnected to one another or connected to one or more network nodes (170a, 170b, generically referred to as 170) in the radio access network 120. A core network 130 may be a part of the communication system and may be dependent or independent of the radio access technology used in the communication system 100. Also, the communication system 100 includes a public switched telephone network (PSTN) 140, the internet 150, and other networks 160.

[0137] FIG. 2 illustrates an example communication system 100. In general, the communication system 100 enables multiple wireless or wired elements to communicate data and other content. The purpose of the communication system 100 may be to provide content, such as voice, data, video, and / or text, via broadcast, multicast and unicast, etc. The communication system 100 may operate by sharing resources, such as carrier spectrum bandwidth, between its constituent elements. The communication system 100 may include a terrestrial communication system and / or a non-terrestrial communication system. The communication system 100 may provide a wide range of communication services and applications (such as earth monitoring, remote sensing, passive sensing and positioning, navigation and tracking, autonomous delivery and mobility, etc. ) . The communication system 100 may provide a high degree of availability and robustness through a joint operation of the terrestrial communication system and the non-terrestrial communication system. For example, integrating a non-terrestrial communication system (or components thereof) into a terrestrial communication system can result in what may be considered a heterogeneous network including multiple layers. Compared to conventional communication networks, the heterogeneous network may achieve better overall performance through efficient multi-link joint operation, more flexible functionality sharing, and faster physical layer link switching between terrestrial networks and non-terrestrial networks.

[0138] The terrestrial communication system and the non-terrestrial communication system could be considered sub-systems of the communication system. In the example shown, the communication system 100 includes electronic devices (ED) 110a-110d (generically referred to as ED 110) , radio access networks (RANs) 120a-120b, non-terrestrial communication network 120c, a core network 130, a public switched telephone network (PSTN) 140, the internet 150, and other networks 160. The RANs 120a-120b include respective base stations (BSs) 170a-170b, which may be generically referred to as terrestrial transmit and receive points (T-TRPs) 170a-170b. The non-terrestrial communication network 120c includes an access node 120c, which may be generically referred to as a non-terrestrial transmit and receive point (NT-TRP) 172.

[0139] Any ED 110 may be alternatively or additionally configured to interface, access, or communicate with any other T-TRP 170a-170b and NT-TRP 172, the internet 150, the core network 130, the PSTN 140, the other networks 160, or any combination of the preceding. In some examples, ED 110a may communicate an uplink and / or downlink transmission over an interface 190a with T-TRP 170a. In some examples, the EDs 110a, 110b and 110d may also communicate directly with one another via one or more sidelink air interfaces 190b. In some examples, ED 110d may communicate an uplink and / or downlink transmission over an interface 190c with NT-TRP 172.

[0140] The air interfaces 190a and 190b may use similar communication technology, such as any suitable radio access technology. For example, the communication system 100 may implement one or more channel access methods, such as code division multiple access (CDMA) , time division multiple access (TDMA) , frequency division multiple access (FDMA) , orthogonal FDMA (OFDMA) , or single-carrier FDMA (SC-FDMA) in the air interfaces 190a and 190b. The air interfaces 190a and 190b may utilize other higher dimension signal spaces, which may involve a combination of orthogonal and / or non-orthogonal dimensions.

[0141] The air interface 190c can enable communication between the ED 110d and one or multiple NT-TRPs 172 via a wireless link or simply a link. In some examples, the link is a dedicated connection for unicast transmission, a connection for broadcast transmission, or a connection between a group of EDs and one or multiple NT-TRPs for multicast transmission.

[0142] The RANs 120a and 120b are in communication with the core network 130 to provide the EDs 110a 110b, and 110c with various services such as voice, data, and other services. The RANs 120a and 120b and / or the core network 130 may be in direct or indirect communication with one or more other RANs (not shown) , which may or may not be directly served by core network 130, and may or may not employ the same radio access technology as RAN 120a, RAN 120b or both. The core network 130 may also serve as a gateway access between (i) the RANs 120a and 120b or EDs 110a 110b, and 110c or both, and (ii) other networks (such as the PSTN 140, the internet 150, and the other networks 160) . In addition, some or all of the EDs 110a 110b, and 110c may include functionality for communicating with different wireless networks over different wireless links using different wireless technologies and / or protocols. Instead of wireless communication (or in addition thereto) , the EDs 110a 110b, and 110c may communicate via wired communication channels to a service provider or switch (not shown) , and to the internet 150. PSTN 140 may include circuit switched telephone networks for providing plain old telephone service (POTS) . Internet 150 may include a network of computers and subnets (intranets) or both, and incorporate protocols, such as Internet Protocol (IP) , Transmission Control Protocol (TCP) , User Datagram Protocol (UDP) . EDs 110a 110b, and  110c may be multimode devices capable of operation according to multiple radio access technologies, and incorporate multiple transceivers necessary to support such.

[0143] Basic component structure

[0144] FIG. 3 illustrates another example of an ED 110 and a base station 170a, 170b and / or 170c. The ED 110 is used to connect persons, objects, machines, etc. The ED 110 may be widely used in various scenarios, for example, cellular communications, device-to-device (D2D) , vehicle to everything (V2X) , peer-to-peer (P2P) , machine-to-machine (M2M) , machine-type communications (MTC) , internet of things (IOT) , virtual reality (VR) , augmented reality (AR) , industrial control, self-driving, remote medical, smart grid, smart furniture, smart office, smart wearable, smart transportation, smart city, drones, robots, remote sensing, passive sensing, positioning, navigation and tracking, autonomous delivery and mobility, etc.

[0145] Each ED 110 represents any suitable end user device for wireless operation and may include such devices (or may be referred to) as a user equipment / device (UE) , a wireless transmit / receive unit (WTRU) , a mobile station, a fixed or mobile subscriber unit, a cellular telephone, a station (STA) , a machine type communication (MTC) device, a personal digital assistant (PDA) , a smartphone, a laptop, a computer, a tablet, a wireless sensor, a consumer electronics device, a smart book, a vehicle, a car, a truck, a bus, a train, or an IoT device, an industrial device, or apparatus (e.g. communication module, modem, or chip) in the forgoing devices, among other possibilities. Future generation EDs 110 may be referred to using other terms. The base station 170a and 170b is a T-TRP and will hereafter be referred to as T-TRP 170. Also shown in FIG. 3, a NT-TRP will hereafter be referred to as NT-TRP 172. Each ED 110 connected to T-TRP 170 and / or NT-TRP 172 can be dynamically or semi-statically turned-on (i.e., established, activated, or enabled) , turned-off (i.e., released, deactivated, or disabled) and / or configured in response to one of more of: connection availability and connection necessity.

[0146] The ED 110 includes a transmitter 201 and a receiver 203 coupled to one or more antennas 204. Only one antenna 204 is illustrated. One, some, or all of the antennas may alternatively be panels. The transmitter 201 and the receiver 203 may be integrated, e.g. as a transceiver. The transceiver is configured to modulate data or other content for transmission by at least one antenna 204 or network interface controller (NIC) . The transceiver is also configured to demodulate data or other content received by the at least one antenna 204. Each transceiver includes any suitable structure for generating signals for wireless or wired transmission and / or processing signals received wirelessly or by wire. Each antenna 204 includes any suitable structure for transmitting and / or receiving wireless or wired signals.

[0147] The ED 110 includes at least one memory 208. The memory 208 stores instructions and data used, generated, or collected by the ED 110. For example, the memory 208 could store software instructions or modules configured to implement some or all of the functionality and / or embodiments described herein and that are executed by the processing unit (s) 210. Each memory 208 includes any suitable volatile and / or non-volatile storage and retrieval device (s) . Any suitable type of memory may be used, such as random access memory (RAM) , read only memory (ROM) , hard disk, optical disc, subscriber identity module (SIM) card, memory stick, secure digital (SD) memory card, on-processor cache, and the like.

[0148] The ED 110 may further include one or more input / output devices (not shown) or interfaces (such as a wired interface to the internet 150 in FIG. 1) . The input / output devices permit interaction with a user or other devices in the network. Each input / output device includes any suitable structure for providing information to or receiving information from a user, such as a speaker, microphone, keypad, keyboard, display, or touch screen, including network interface communications.

[0149] The ED 110 further includes a processor 210 for performing operations including those related to preparing a transmission for uplink transmission to the NT-TRP 172 and / or T-TRP 170, those related to processing downlink transmissions received from the NT-TRP 172 and / or T-TRP 170, and those related to processing sidelink transmission to and from another ED 110. Processing operations related to preparing a transmission for uplink transmission may include operations such as encoding, modulating, transmit beamforming, and generating symbols for transmission. Processing operations related to processing downlink transmissions may include operations such as receive beamforming, demodulating and decoding received symbols. Depending upon the embodiment, a downlink transmission may be received by the receiver 203, possibly using receive beamforming, and the processor 210 may extract signaling from the downlink transmission (e.g. by detecting and / or decoding the signaling) . An example of signaling may be a reference signal transmitted by NT-TRP 172 and / or T-TRP 170. In some embodiments, the processor 276 implements the transmit beamforming and / or receive beamforming based on the indication of beam direction, e.g. beam angle information (BAI) , received from T-TRP 170. In some embodiments, the processor 210 may perform operations relating to network access (e.g. initial access) and / or downlink synchronization, such as operations relating to detecting a synchronization sequence, decoding and obtaining the system information, etc. In some embodiments, the processor 210 may perform channel estimation, e.g. using a reference signal received from the NT-TRP 172 and / or T-TRP 170.

[0150] Although not illustrated, the processor 210 may form part of the transmitter 201 and / or receiver 203.  Although not illustrated, the memory 208 may form part of the processor 210.

[0151] The processor 210, and the processing components of the transmitter 201 and receiver 203 may each be implemented by the same or different one or more processors that are configured to execute instructions stored in a memory (e.g. in memory 208) . Alternatively, some or all of the processor 210, and the processing components of the transmitter 201 and receiver 203 may be implemented using dedicated circuitry, such as a programmed field-programmable gate array (FPGA) , a graphical processing unit (GPU) , or an application-specific integrated circuit (ASIC) .

[0152] The T-TRP 170 may be known by other names in some implementations, such as a base station, a base transceiver station (BTS) , a radio base station, a network node, a network device, a device on the network side, a transmit / receive node, a Node B, an evolved NodeB (eNodeB or eNB) , a Home eNodeB, a next Generation NodeB (gNB) , a transmission point (TP) ) , a site controller, an access point (AP) , or a wireless router, a relay station, a remote radio head, a terrestrial node, a terrestrial network device, or a terrestrial base station, base band unit (BBU) , remote radio unit (RRU) , active antenna unit (AAU) , remote radio head (RRH) , central unit (CU) , distribute unit (DU) , positioning node, among other possibilities. The T-TRP 170 may be macro BSs, pico BSs, relay node, donor node, or the like, or combinations thereof. The T-TRP 170 may refer to the forging devices or apparatus (e.g. communication module, modem, or chip) in the forgoing devices.

[0153] In some embodiments, the parts of the T-TRP 170 may be distributed. For example, some of the modules of the T-TRP 170 may be located remote from the equipment housing the antennas of the T-TRP 170, and may be coupled to the equipment housing the antennas over a communication link (not shown) sometimes known as front haul, such as common public radio interface (CPRI) . Therefore, in some embodiments, the term T-TRP 170 may also refer to modules on the network side that perform processing operations, such as determining the location of the ED 110, resource allocation (scheduling) , message generation, and encoding / decoding, and that are not necessarily part of the equipment housing the antennas of the T-TRP 170. The modules may also be coupled to other T-TRPs. In some embodiments, the T-TRP 170 may actually be a plurality of T-TRPs that are operating together to serve the ED 110, e.g. through coordinated multipoint transmissions.

[0154] The T-TRP 170 includes at least one transmitter 252 and at least one receiver 254 coupled to one or more antennas 256. Only one antenna 256 is illustrated. One, some, or all of the antennas may alternatively be panels. The transmitter 252 and the receiver 254 may be integrated as a transceiver. The T-TRP 170 further includes a processor 260 for performing operations including those related to: preparing a transmission for downlink transmission to the  ED 110, processing an uplink transmission received from the ED 110, preparing a transmission for backhaul transmission to NT-TRP 172, and processing a transmission received over backhaul from the NT-TRP 172. Processing operations related to preparing a transmission for downlink or backhaul transmission may include operations such as encoding, modulating, precoding (e.g. MIMO precoding) , transmit beamforming, and generating symbols for transmission. Processing operations related to processing received transmissions in the uplink or over backhaul may include operations such as receive beamforming, and demodulating and decoding received symbols. The processor 260 may also perform operations relating to network access (e.g. initial access) and / or downlink synchronization, such as generating the content of synchronization signal blocks (SSBs) , generating the system information, etc. In some embodiments, the processor 260 also generates the indication of beam direction, e.g. BAI, which may be scheduled for transmission by scheduler 253. The processor 260 performs other network-side processing operations described herein, such as determining the location of the ED 110, determining where to deploy NT-TRP 172, etc. In some embodiments, the processor 260 may generate signaling, e.g. to configure one or more parameters of the ED 110 and / or one or more parameters of the NT-TRP 172. Any signaling generated by the processor 260 is sent by the transmitter 252. Note that “signaling” , as used herein, may alternatively be called control signaling. Dynamic signaling may be transmitted in a control channel, e.g. a physical downlink control channel (PDCCH) , and static or semi-static higher layer signaling may be included in a packet transmitted in a data channel, e.g. in a physical downlink shared channel (PDSCH) .

[0155] A scheduler 253 may be coupled to the processor 260. The scheduler 253 may be included within or operated separately from the T-TRP 170, which may schedule uplink, downlink, and / or backhaul transmissions, including issuing scheduling grants and / or configuring scheduling-free ( “configured grant” ) resources. The T-TRP 170 further includes a memory 258 for storing information and data. The memory 258 stores instructions and data used, generated, or collected by the T-TRP 170. For example, the memory 258 could store software instructions or modules configured to implement some or all of the functionality and / or embodiments described herein and that are executed by the processor 260.

[0156] Although not illustrated, the processor 260 may form part of the transmitter 252 and / or receiver 254. Also, although not illustrated, the processor 260 may implement the scheduler 253. Although not illustrated, the memory 258 may form part of the processor 260.

[0157] The processor 260, the scheduler 253, and the processing components of the transmitter 252 and receiver 254 may each be implemented by the same or different one or more processors that are configured to execute  instructions stored in a memory, e.g. in memory 258. Alternatively, some or all of the processor 260, the scheduler 253, and the processing components of the transmitter 252 and receiver 254 may be implemented using dedicated circuitry, such as a FPGA, a GPU, or an ASIC.

[0158] Although the NT-TRP 172 is illustrated as a drone only as an example, the NT-TRP 172 may be implemented in any suitable non-terrestrial form. Also, the NT-TRP 172 may be known by other names in some implementations, such as a non-terrestrial node, a non-terrestrial network device, or a non-terrestrial base station. The NT-TRP 172 includes a transmitter 272 and a receiver 274 coupled to one or more antennas 280. Only one antenna 280 is illustrated. One, some, or all of the antennas may alternatively be panels. The transmitter 272 and the receiver 274 may be integrated as a transceiver. The NT-TRP 172 further includes a processor 276 for performing operations including those related to: preparing a transmission for downlink transmission to the ED 110, processing an uplink transmission received from the ED 110, preparing a transmission for backhaul transmission to T-TRP 170, and processing a transmission received over backhaul from the T-TRP 170. Processing operations related to preparing a transmission for downlink or backhaul transmission may include operations such as encoding, modulating, precoding (e.g. MIMO precoding) , transmit beamforming, and generating symbols for transmission. Processing operations related to processing received transmissions in the uplink or over backhaul may include operations such as receive beamforming, and demodulating and decoding received symbols. In some embodiments, the processor 276 implements the transmit beamforming and / or receive beamforming based on beam direction information (e.g. BAI) received from T-TRP 170. In some embodiments, the processor 276 may generate signaling, e.g. to configure one or more parameters of the ED 110. In some embodiments, the NT-TRP 172 implements physical layer processing, but does not implement higher layer functions such as functions at the medium access control (MAC) or radio link control (RLC) layer. As this is only an example, more generally, the NT-TRP 172 may implement higher layer functions in addition to physical layer processing.

[0159] The NT-TRP 172 further includes a memory 278 for storing information and data. Although not illustrated, the processor 276 may form part of the transmitter 272 and / or receiver 274. Although not illustrated, the memory 278 may form part of the processor 276.

[0160] The processor 276 and the processing components of the transmitter 272 and receiver 274 may each be implemented by the same or different one or more processors that are configured to execute instructions stored in a memory, e.g. in memory 278. Alternatively, some or all of the processor 276 and the processing components of the transmitter 272 and receiver 274 may be implemented using dedicated circuitry, such as a programmed FPGA, a  GPU, or an ASIC. In some embodiments, the NT-TRP 172 may actually be a plurality of NT-TRPs that are operating together to serve the ED 110, e.g. through coordinated multipoint transmissions.

[0161] The T-TRP 170, the NT-TRP 172, and / or the ED 110 may include other components, but these have been omitted for the sake of clarity.

[0162] Basic module structure

[0163] One or more steps of the embodiment methods provided herein may be performed by corresponding units or modules, according to FIG. 4. FIG. 4 illustrates units or modules in a device, such as in ED 110, in T-TRP 170, or in NT-TRP 172. For example, a signal may be transmitted by a transmitting unit or a transmitting module. For example, a signal may be transmitted by a transmitting unit or a transmitting module. A signal may be received by a receiving unit or a receiving module. A signal may be processed by a processing unit or a processing module. Other steps may be performed by an artificial intelligence (AI) or machine learning (ML) module. The respective units or modules may be implemented using hardware, one or more components or devices that execute software, or a combination thereof. For instance, one or more of the units or modules may be an integrated circuit, such as a programmed FPGA, a GPU, or an ASIC. It will be appreciated that where the modules are implemented using software for execution by a processor for example, they may be retrieved by a processor, in whole or part as needed, individually or together for processing, in single or multiple instances, and that the modules themselves may include instructions for further deployment and instantiation.

[0164] Additional details regarding the EDs 110, T-TRP 170, and NT-TRP 172 are known to those of skill in the art. As such, these details are omitted here.

[0165] 6G intelligent air interface

[0166] An air interface generally includes a number of components and associated parameters that collectively specify how a transmission is to be sent and / or received over a wireless communications link between two or more communicating devices. For example, an air interface may include one or more components defining the waveform (s) , frame structure (s) , multiple access scheme (s) , protocol (s) , coding scheme (s) and / or modulation scheme (s) for conveying information (e.g. data) over a wireless communications link. The wireless communications link may support a link between a radio access network and user equipment (e.g. a “Uu” link) , and / or the wireless communications link may support a link between device and device, such as between two user equipments (e.g. a “sidelink” ) , and / or the wireless communications link may support a link between a non-terrestrial (NT) -communication network and user equipment (UE) . The followings are some examples for the above components:

[0167] A waveform component may specify a shape and form of a signal being transmitted. Waveform options may include orthogonal multiple access waveforms and non-orthogonal multiple access waveforms. Non-limiting examples of such waveform options include Orthogonal Frequency Division Multiplexing (OFDM) , Filtered OFDM (f-OFDM) , Time windowing OFDM, Filter Bank Multicarrier (FBMC) , Universal Filtered Multicarrier (UFMC) , Generalized Frequency Division Multiplexing (GFDM) , Wavelet Packet Modulation (WPM) , Faster Than Nyquist (FTN) Waveform, and low Peak to Average Power Ratio Waveform (low PAPR WF) .

[0168] A frame structure component may specify a configuration of a frame or group of frames. The frame structure component may indicate one or more of a time, frequency, pilot signature, code, or other parameter of the frame or group of frames. More details of frame structure will be discussed below.

[0169] A multiple access scheme component may specify multiple access technique options, including technologies defining how communicating devices share a common physical channel, such as: Time Division Multiple Access (TDMA) , Frequency Division Multiple Access (FDMA) , Code Division Multiple Access (CDMA) , Single Carrier Frequency Division Multiple Access (SC-FDMA) , Low Density Signature Multicarrier Code Division Multiple Access (LDS-MC-CDMA) , Non-Orthogonal Multiple Access (NOMA) , Pattern Division Multiple Access (PDMA) , Lattice Partition Multiple Access (LPMA) , Resource Spread Multiple Access (RSMA) , and Sparse Code Multiple Access (SCMA) . Furthermore, multiple access technique options may include: scheduled access vs. non-scheduled access, also known as grant-free access; non-orthogonal multiple access vs. orthogonal multiple access, e.g., via a dedicated channel resource (e.g., no sharing between multiple communicating devices) ; contention-based shared channel resources vs. non-contention-based shared channel resources, and cognitive radio-based access.

[0170] A hybrid automatic repeat request (HARQ) protocol component may specify how a transmission and / or a re-transmission is to be made. Non-limiting examples of transmission and / or re-transmission mechanism options include those that specify a scheduled data pipe size, a signaling mechanism for transmission and / or re-transmission, and a re-transmission mechanism.

[0171] A coding and modulation component may specify how information being transmitted may be encoded / decoded and modulated / demodulated for transmission / reception purposes. Coding may refer to methods of error detection and forward error correction. Non-limiting examples of coding options include turbo trellis codes, turbo product codes, fountain codes, low-density parity check codes, and polar codes. Modulation may refer, simply, to the constellation (including, for example, the modulation technique and order) , or more specifically to various types of advanced modulation methods such as hierarchical modulation and low PAPR modulation.

[0172] In some embodiments, the air interface may be a “one-size-fits-all concept” . For example, the components within the air interface cannot be changed or adapted once the air interface is defined. In some implementations, only limited parameters or modes of an air interface, such as a cyclic prefix (CP) length or a multiple input multiple output (MIMO) mode, can be configured. In some embodiments, an air interface design may provide a unified or flexible framework to support below 6GHz and beyond 6GHz frequency (e.g., mmWave) bands for both licensed and unlicensed access. As an example, flexibility of a configurable air interface provided by a scalable numerology and symbol duration may allow for transmission parameter optimization for different spectrum bands and for different services / devices. As another example, a unified air interface may be self-contained in a frequency domain, and a frequency domain self-contained design may support more flexible radio access network (RAN) slicing through channel resource sharing between different services in both frequency and time.

[0173] Frame structure

[0174] A frame structure is a feature of the wireless communication physical layer that defines a time domain signal transmission structure, e.g. to allow for timing reference and timing alignment of basic time domain transmission units. Wireless communication between communicating devices may occur on time-frequency resources governed by a frame structure. The frame structure may sometimes instead be called a radio frame structure.

[0175] Depending upon the frame structure and / or configuration of frames in the frame structure, frequency division duplex (FDD) and / or time-division duplex (TDD) and / or full duplex (FD) communication may be possible. FDD communication is when transmissions in different directions (e.g. uplink vs. downlink) occur in different frequency bands. TDD communication is when transmissions in different directions (e.g. uplink vs. downlink) occur over different time durations. FD communication is when transmission and reception occurs on the same time-frequency resource, i.e. a device can both transmit and receive on the same frequency resource concurrently in time.

[0176] One example of a frame structure is a frame structure in long-term evolution (LTE) having the following specifications: each frame is 10ms in duration; each frame has 10 subframes, which are each 1ms in duration; each subframe includes two slots, each of which is 0.5ms in duration; each slot is for transmission of 7 OFDM symbols (assuming normal CP) ; each OFDM symbol has a symbol duration and a particular bandwidth (or partial bandwidth or bandwidth partition) related to the number of subcarriers and subcarrier spacing; the frame structure is based on OFDM waveform parameters such as subcarrier spacing and CP length (where the CP has a fixed length or limited length options) ; and the switching gap between uplink and downlink in TDD has to be the integer time of OFDM symbol duration.

[0177] Another example of a frame structure is a frame structure in new radio (NR) having the following specifications: multiple subcarrier spacings are supported, each subcarrier spacing corresponding to a respective numerology; the frame structure depends on the numerology, but in any case the frame length is set at 10ms, and consists of ten subframes of 1ms each; a slot is defined as 14 OFDM symbols, and slot length depends upon the numerology. For example, the NR frame structure for normal CP 15 kHz subcarrier spacing ( “numerology 1” ) and the NR frame structure for normal CP 30 kHz subcarrier spacing ( “numerology 2” ) are different. For 15 kHz subcarrier spacing a slot length is 1ms, and for 30 kHz subcarrier spacing a slot length is 0.5ms. The NR frame structure may have more flexibility than the LTE frame structure.

[0178] Another example of a frame structure is an example flexible frame structure, e.g. for use in a 6G network or later. In a flexible frame structure, a symbol block may be defined as the minimum duration of time that may be scheduled in the flexible frame structure. A symbol block may be a unit of transmission having an optional redundancy portion (e.g. CP portion) and an information (e.g. data) portion. An OFDM symbol is an example of a symbol block. A symbol block may alternatively be called a symbol. Embodiments of flexible frame structures include different parameters that may be configurable, e.g. frame length, subframe length, symbol block length, etc. A non-exhaustive list of possible configurable parameters in some embodiments of a flexible frame structure include:

[0179] (1) Frame: The frame length need not be limited to 10ms, and the frame length may be configurable and change over time. In some embodiments, each frame includes one or multiple downlink synchronization channels and / or one or multiple downlink broadcast channels, and each synchronization channel and / or broadcast channel may be transmitted in a different direction by different beamforming. The frame length may be more than one possible value and configured based on the application scenario. For example, autonomous vehicles may require relatively fast initial access, in which case the frame length may be set as 5ms for autonomous vehicle applications. As another example, smart meters on houses may not require fast initial access, in which case the frame length may be set as 20ms for smart meter applications.

[0180] (2) Subframe duration: A subframe might or might not be defined in the flexible frame structure, depending upon the implementation. For example, a frame may be defined to include slots, but no subframes. In frames in which a subframe is defined, e.g. for time domain alignment, then the duration of the subframe may be configurable. For example, a subframe may be configured to have a length of 0.1 ms or 0.2 ms or 0.5 ms or 1 ms or 2 ms or 5 ms, etc. In some embodiments, if a subframe is not needed in a particular scenario, then the subframe length may be defined to be the same as the frame length or not defined.

[0181] (3) Slot configuration: A slot might or might not be defined in the flexible frame structure, depending upon the implementation. In frames in which a slot is defined, then the definition of a slot (e.g. in time duration and / or in number of symbol blocks) may be configurable. In one embodiment, the slot configuration is common to all UEs or a group of UEs. For this case, the slot configuration information may be transmitted to UEs in a broadcast channel or common control channel (s) . In other embodiments, the slot configuration may be UE specific, in which case the slot configuration information may be transmitted in a UE-specific control channel. In some embodiments, the slot configuration signaling can be transmitted together with frame configuration signaling and / or subframe configuration signaling. In other embodiments, the slot configuration can be transmitted independently from the frame configuration signaling and / or subframe configuration signaling. In general, the slot configuration may be system common, base station common, UE group common, or UE specific.

[0182] (4) Subcarrier spacing (SCS) : SCS is one parameter of scalable numerology which may allow the SCS to possibly range from 15 KHz to 480 KHz. The SCS may vary with the frequency of the spectrum and / or maximum UE speed to minimize the impact of the Doppler shift and phase noise. In some examples, there may be separate transmission and reception frames, and the SCS of symbols in the reception frame structure may be configured independently from the SCS of symbols in the transmission frame structure. The SCS in a reception frame may be different from the SCS in a transmission frame. In some examples, the SCS of each transmission frame may be half the SCS of each reception frame. If the SCS between a reception frame and a transmission frame is different, the difference does not necessarily have to scale by a factor of two, e.g. if more flexible symbol durations are implemented using inverse discrete Fourier transform (IDFT) instead of fast Fourier transform (FFT) . Additional examples of frame structures can be used with different SCSs.

[0183] (5) Flexible transmission duration of basic transmission unit: The basic transmission unit may be a symbol block (alternatively called a symbol) , which in general includes a redundancy portion (referred to as the CP) and an information (e.g. data) portion, although in some embodiments the CP may be omitted from the symbol block. The CP length may be flexible and configurable. The CP length may be fixed within a frame or flexible within a frame, and the CP length may possibly change from one frame to another, or from one group of frames to another group of frames, or from one subframe to another subframe, or from one slot to another slot, or dynamically from one scheduling to another scheduling. The information (e.g. data) portion may be flexible and configurable. Another possible parameter relating to a symbol block that may be defined is ratio of CP duration to information (e.g. data) duration. In some embodiments, the symbol block length may be adjusted according to: channel condition (e.g.  mulit-path delay, Doppler) ; and / or latency requirement; and / or available time duration. As another example, a symbol block length may be adjusted to fit an available time duration in the frame.

[0184] (6) Flexible switch gap: A frame may include both a downlink portion for downlink transmissions from a base station, and an uplink portion for uplink transmissions from UEs. A gap may be present between each uplink and downlink portion, which is referred to as a switching gap. The switching gap length (duration) may be configurable. A switching gap duration may be fixed within a frame or flexible within a frame, and a switching gap duration may possibly change from one frame to another, or from one group of frames to another group of frames, or from one subframe to another subframe, or from one slot to another slot, or dynamically from one scheduling to another scheduling.

[0185] Cells, carriers, bandwidth parts (BWPs) and occupied bandwidth

[0186] A device, such as a base station, may provide coverage over a cell. Wireless communication with the device may occur over one or more carrier frequencies. A carrier frequency will be referred to as a carrier. A carrier may alternatively be called a component carrier (CC) . A carrier may be characterized by its bandwidth and a reference frequency, e.g. the center or lowest or highest frequency of the carrier. A carrier may be on licensed or unlicensed spectrum. Wireless communication with the device may also or instead occur over one or more BWPs. For example, a carrier may have one or more BWPs. More generally, wireless communication with the device may occur over a wireless spectrum. The spectrum may include one or more carriers and / or one or more BWPs.

[0187] A cell may include one or multiple downlink resources and optionally one or multiple uplink resources, or a cell may include one or multiple uplink resources and optionally one or multiple downlink resources, or a cell may include both one or multiple downlink resources and one or multiple uplink resources. As an example, a cell might only include one downlink carrier / BWP, or only include one uplink carrier / BWP, or include multiple downlink carriers / BWPs, or include multiple uplink carriers / BWPs, or include one downlink carrier / BWP and one uplink carrier / BWP, or include one downlink carrier / BWP and multiple uplink carriers / BWPs, or include multiple downlink carriers / BWPs and one uplink carrier / BWP, or include multiple downlink carriers / BWPs and multiple uplink carriers / BWPs. In some embodiments, a cell may instead or additionally include one or multiple sidelink resources, e.g. sidelink transmitting and receiving resources.

[0188] A BWP may be broadly defined as a set of contiguous or non-contiguous frequency subcarriers on a carrier, or a set of contiguous or non-contiguous frequency subcarriers on multiple carriers, or a set of non-contiguous or contiguous frequency subcarriers, which may have one or more carriers.

[0189] In some embodiments, a carrier may have one or more BWPs, e.g. a carrier may have a bandwidth of 20 MHz and consist of one BWP, or a carrier may have a bandwidth of 80 MHz and consist of two adjacent contiguous BWPs, etc. In other embodiments, a BWP may have one or more carriers, e.g. a BWP may have a bandwidth of 40 MHz and consists of two adjacent contiguous carriers, where each carrier has a bandwidth of 20 MHz. In some embodiments, a BWP may include non-contiguous spectrum resources which consists of non-contiguous multiple carriers, where the first carrier of the non-contiguous multiple carriers may be in mmW band, the second carrier may be in a low band (such as 2GHz band) , the third carrier (if it exists) may be in THz band, and the fourth carrier (if it exists) may be in visible light band. Resources in one carrier which belong to the BWP may be contiguous or non-contiguous. In some embodiments, a BWP has non-contiguous spectrum resources on one carrier.

[0190] Wireless communication may occur over an occupied bandwidth. The occupied bandwidth may be defined as the width of a frequency band such that, below the lower and above the upper frequency limits, the mean powers emitted are each equal to a specified percentage β / 2 of the total mean transmitted power, for example, the value of β / 2 is taken as 0.5%.

[0191] The carrier, the BWP, or the occupied bandwidth may be signaled by a network device (e.g. base station) dynamically, e.g. in physical layer control signaling such as DCI, or semi-statically, e.g. in radio resource control (RRC) signaling or in the medium access control (MAC) layer, or be predefined based on the application scenario; or be determined by the UE as a function of other parameters that are known by the UE, or may be fixed, e.g. by a standard.

[0192] Terminal types

[0193] The communication method provided in this embodiment of this disclosure may be applied to various communication scenarios, for example, may be applied to one or more of the following communication scenarios: enhanced mobile broadband (enhanced mobile broadband, eMBB) , ultra-reliable low-latency communication (ultra reliable low latency communication, URLLC) , and machine type communication (machine type communication) . MTC) , Internet of Things (IoT) , narrowband Internet of Things (narrow band internet of thing, NB-IoT) , customer front-end equipment (customer front-end equipment, CPE) , augmented reality (augmented reality, AR) , virtual reality (virtual reality, VR) , mass machine type communications (mMTC) , device to device (D2D) , vehicle to everything (V2X) , vehicle to vehicle (V2V) , etc.

[0194] It should be noted that in this embodiment of this disclosure, IoT (internet of thing, IoT) may include one or more of NB-IoT, MTC, mMTC, and the like. This is not limited.

[0195] The eMBB may be a large-traffic mobile broadband service such as a three-dimensional (three-dimensional, 3D) or ultra-high-definition video. Specifically, the eMBB may further improve performance such as a network speed and user experience based on a mobile broadband service. For example, when a user watches a 4K HD video, the peak network speed can reach 10 Gbit / s.

[0196] URLLC may refer to a service with high reliability, low latency, and extremely high availability. Specifically, the URLLC may include the following communications scenarios and applications: industrial application and control, traffic safety and control, remote manufacturing, remote training, remote surgery, unmanned driving, industrial automation, a security industry, and the like.

[0197] MTC may refer to a low-cost and coverage-enhanced service, and may also be referred to as M2M. mMTC refers to large-scale IoT services.

[0198] NB-IoT may be a service that features wide coverage, a large number of connections, a low rate, a low cost, low power consumption, and an excellent architecture. Specifically, the NB-IoT may include a smart water meter, smart parking, intelligent pet tracking, a smart bicycle, an intelligent smoke detector, an intelligent toilet, an intelligent vending machine, and the like.

[0199] The CPE may refer to a mobile signal access device that receives a mobile signal and forwards the mobile signal by using a wireless fidelity (wireless fidelity, WiFi) signal, or may refer to a device that converts a high-speed 4G or 5G signal into a WiFi signal, and may simultaneously support a relatively large quantity of mobile terminals that access the Internet. CPEs can be widely used for wireless network access in rural areas, towns, hospitals, units, factories, and residential areas, reducing the cost of laying wired networks.

[0200] The V2X can enable communication between vehicles, between vehicles and network devices, and between network devices, to obtain a series of traffic information such as a real-time road condition, road information, and pedestrian information, and provide in-vehicle entertainment information to improve driving safety, reduce congestion, and improve traffic efficiency.

[0201] For example, the terminal type includes an eMBB device, a URLLC device, an NB-IoT device, and a CPE device. The eMBB device is mainly configured to transmit large-packet data, or may be configured to transmit small-packet data, and is generally in a moving state. Requirements for a transmission delay and reliability are general, and both uplink and downlink communication exists. A channel environment is relatively complex and changeable, and indoor communication or outdoor communication may be used. For example, an eMBB device may be a mobile phone. The URLLC device is mainly configured to transmit small packet data, or may transmit medium  packet data. Generally, the URLLC device belongs to a non-moving state, or may move along a fixed route. The URLLC device has a relatively high requirement for a transmission delay and reliability, that is, a low transmission delay and high reliability are required, and both uplink and downlink communications have. The channel environment is stable. For example, the URLLC device may be a factory device. The NB-IoT device is mainly used to transmit small data. The NB-IoT device is generally in a non-moving state, has a known location, has a medium transmission delay and reliability requirement, has a relatively large amount of uplink communication, and has a relatively stable channel environment. For example, the NB-IoT device may be a smart water meter or a sensor. The CPE device is mainly used to transmit large-packet data, is generally in a non-mobile state, or can move over ultra-short distances, has medium requirements on transmission delay and reliability, has both uplink and downlink communication, and has a relatively stable channel environment. For example, The CPE device may be a terminal device, an AR, a VR, or the like in the smart home. When the terminal type of the terminal device is determined, the terminal type may be determined based on a service type, mobility, a transmission delay requirement, a reliability requirement, a channel environment, and a communication scenario of the terminal device. Determining that the terminal type corresponding to the terminal device is an eMBB device, a URLLC device, an NB-IoT device, or a CPE device.

[0202] It should be noted that the eMBB device may alternatively be described as eMBB, the URLLC device may alternatively be described as URLLC, the NB-IoT device may alternatively be described as NB-IoT, and the CPE device may alternatively be described as CPE. The V2X device may also be described as a V2X device, which is not limited.

[0203] Physical uplink control channel (PUCCH) and physical transmit link control channel (PTxCCH)

[0204] A physical uplink control channel (physical uplink control channel, PUCCH) is mainly used to carry uplink control information (uplink control information, UCI) . Specifically, the information may include information about applying for an uplink resource configuration by the terminal device from the network device, information about replying whether the downlink service data is correctly received by the terminal device, and channel state information (channel state information, CSI) of the downlink channel reported by the terminal device.

[0205] In a possible implementation, a physical layer control channel, that is, a physical transmission link control channel (physical transmission link control channel, PTxCCH) , may be introduced. A function of the PTxCCH is similar to that of a PUCCH in LTE and 5G. Specifically, the channel is used by the terminal device to transmit control information, and / or is used by the network device to receive control information. The control information may  include at least one of the following: ACK / NACK information, channel state information, a scheduling request, and the like. It should be understood that, generally, the standard protocol is described from a perspective of a terminal device. Therefore, the physical layer uplink control channel may be described as a physical layer transmit link control channel.

[0206] Physical uplink shared channel (PUSCH) and physical transmit link shared channel (PTxSCH)

[0207] A physical uplink shared channel (physical uplink shared channel, PUSCH) is used to transmit uplink service data. The PUSCH may be dynamically scheduled by using DCI, or may be configured by using a higher layer parameter for scheduling-free transmission, or may be semi-persistent scheduling by using DCI after the higher layer parameter is configured.

[0208] A PUSCH sending procedure may include processes such as scrambling, modulation, layer mapping, conversion precoding, precoding, resource mapping, and symbol generation.

[0209] In a possible implementation, a physical layer data channel, that is, a physical transmission link shared channel (physical transmission link shared channel, PTxSCH) , may be introduced. A function of the PTxSCH is similar to that of a PUSCH in LTE and 5G. Specifically, the channel is used by the terminal device to transmit data, and / or is used by the network device to receive data. It should be understood that, generally, the standard protocol is described from a perspective of a terminal device. Therefore, an uplink data channel at a physical layer may be described as a data sending channel at a physical layer.

[0210] Downlink control information (DCI)

[0211] Downlink control information (DCI) is control information that is transmitted on a PDCCH and that is related to a PDSCH and a PUSCH. The terminal device can correctly process the PDSCH data or the PUSCH data only when the DCI information is correctly decoded.

[0212] Uses of different DCI may be different, for example, DCI used for uplink / downlink transmission resource allocation, DCI used for uplink power control adjustment, and DCI used for downlink dual-stream spatial multiplexing. Different DCI formats may be used for differentiation of DCI for different purposes.

[0213] Specifically, the information included in the DCI may be classified into three types, and the DCI may include at least one of the three types. The first-type information is information used for channel estimation, for example, a time-frequency resource indication or a demodulation reference signal (demodulation reference signal, DMRS) . The second type of information is information used to decode the PDSCH, for example, a modulation and coding scheme (modulation and coding scheme, MCS) , a hybrid automatic repeat request process number (hybrid  automatic repeat request process number, HARQ process number) , and a new data indicator (new data indicator, NDI) . The third type of information is information used to send UCI, for example, a PUCCH resource, transmit power control (Transmit power control, TPC) , code block group transmission information (Code block group transmission information, CBG) configuration, and channel state information (Channel state information) . CSI) trigger information, sounding reference signal (Sounding reference signal, SRS) trigger information, and the like.

[0214] To reduce a quantity of blind detection times of the terminal device, it is proposed that information included in the DCI is transmitted in parts. For example, the first type information is used as the first DCI for transmission, the second type information is used as the second DCI for transmission, and the third type information is used as the third DCI for transmission. Alternatively, for another example, the first-type information and the second-type information are used as first DCI for transmission, and the third-type information is used as second DCI for transmission. Alternatively, for another example, the first type information is used as the first DCI for transmission, and the second type information and the third type information are used as the second DCI for transmission. The information included in the DCI is transmitted in parts, so that the terminal device can process different types of information in parallel, thereby reducing a communication delay.

[0215] Blind detection of terminal devices

[0216] Because the terminal device does not know in advance which format DCI is carried on the received PDCCH, and does not know which candidate PDCCH is used to transmit the DCI, the terminal device must perform PDCCH blind detection to receive corresponding DCI. Before the terminal device successfully decodes the PDCCH, the terminal device may attempt to decode each possible candidate PDCCH until the terminal device successfully detects the PDCCH, or a quantity of DCI expected to be received by the terminal device or a quantity of blind detection times limit of the terminal device is reached.

[0217] In other words, the DCI has a plurality of different formats. When receiving the PDCCH, the terminal device cannot determine a DCI format to which the received DCI belongs, and therefore cannot correctly process data transmitted on a channel such as a PDSCH or a PUSCH. Therefore, the terminal device must perform blind detection on a format of the DCI. Generally, the terminal device does not know a format of the current DCI, and does not know a location of information required by the terminal device. However, the terminal device knows information in a format expected by the terminal device, and expected information in different formats corresponds to different expected RNTIs and CCEs. Therefore, the terminal device may perform CRC check on the received DCI by using the expected RNTI and the expected CCE, so as to know whether the received DCI is required by the  terminal device, and also know a corresponding DCI format and a corresponding modulation scheme, so as to further access the DCI. The foregoing procedure is a blind detection process of the terminal device.

[0218] It should be understood that, a cyclic redundancy check (cyclic redundancy check, CRC) bit is usually added to the information bits of the DCI to implement an error detection function of the terminal device, and different types of radio network identifiers (radio network temporary identifier, RNTI) are used for scrambling in the CRC bits. Thus, the RNTI is implicitly encoded in the CRC bits. It should be further understood that different RNTIs can be used to both identify the terminal device and distinguish purposes of the DCI.

[0219] In addition, for a blind detection process of the terminal device, because the PDCCH includes a plurality of CCEs, or DCI is carried on the plurality of CCEs, the terminal device needs to perform blind detection on the plurality of CCEs. However, if the terminal device performs blind detection one by one at a granularity of CCEs, efficiency is relatively low. Therefore, a search space (search space) is specified in a protocol. The search space may be simply understood as that when the terminal device performs PDCCH blind detection, blind detection is performed by using several CCEs as a granularity. For example, if a value of an aggregation level AL of a CCE defined in the search space is 4 or 8, when the terminal device performs blind detection, Blind detection is performed at a granularity of four CCEs and then at a granularity of eight CCEs.

[0220] Specifically, when the value of the aggregation level AL of the CCE defined in the search space is 4 or 8, when the network device identifies the PDCCH, in addition to using the aggregation level parameter (a value of 4 or 8 is selected) , A CCE location index (CCE index) parameter is further used, where the CCE location index is obtained through calculation based on time-frequency domain information of the PDCCH, an aggregation level, and the like. Because the terminal device cannot accurately know the aggregation level of the CCE occupied by the PDCCH and the start location index of the CCE, the terminal device receives higher layer signaling before receiving the PDCCH, where the higher layer signaling indicates time-frequency domain information of the PDCCH, and the like. In addition, the terminal device determines, based on a protocol, an indication of a network device, or the like, that the aggregation level of the PDCCH may be 4, or may be 8. Therefore, during blind detection, the terminal device may first use the aggregation level 4 and based on the time-frequency domain information of the PDCCH, calculating a position index (including a start position index of a CCE) of the CCE in the PDCCH, and performing blind detection on a corresponding CCE; and; Then, when the expected DCI is not detected or the quantity of DCI that is not expected to be detected reaches, the terminal device may further use the aggregation level 8 and based on the time-frequency domain information of the PDCCH, calculating a start position index (the position index of the  CCE) of the CCE in the PDCCH, and performing blind detection on the corresponding CCE.

[0221] Downlink (DL) HARQ and uplink (UL) HARQ

[0222] For DL HARQ, a MAC (media access control) entity includes a HARQ entity for each serving cell, which maintains a number of parallel HARQ processes. Each HARQ process is associated with a HARQ process identifier (ID) . The HARQ entity directs HARQ information and associated TBs (Transport Blocks) received on a DL-SCH (DL Shared CHannel) to the corresponding HARQ processes. The HARQ process supports one TB when the physical layer is not configured for downlink spatial multiplexing, and the HARQ process supports one or two TBs when the physical layer is configured for downlink spatial multiplexing. When a transmission takes place for the HARQ process, one or two (in case of downlink spatial multiplexing) TBs and the associated HARQ information are received from the HARQ entity.

[0223] For UL HARQ, a MAC entity includes a HARQ entity for each serving cell with configured uplink, which maintains a number of parallel HARQ processes. Each HARQ process supports one TB, and each HARQ process is associated with a HARQ process identifier (ID) . Each HARQ process is associated with a HARQ buffer.

[0224] The above describes possible scenarios or generalized description of the embodiments of the present disclosure, the motivation and technical concepts of the present disclosure are illustrated in the following.

[0225] Resilience is a fundamental feature that needs to be addressed in 6G. With the evolution of Industry 4.0 and many other technology visions, ultra-reliable and low latency wireless communications are pivotal enabler for automated manufacturing on a massive scale.

[0226] Two trends are observed toward 6G. From the technological perspective, mmWave and massive MIMO (Multiple-Input Multiple-Output) will be more prevalent because they can significantly expand the current bandwidth resource. From the service perspective, a single device will need to support multiple services with different latency and reliability requirements. The two trends, together with the more stringent resilience requirement, provides an opportunity to re-design the physical layer.

[0227] A potential scenario emerges as multiple services converges into one physical wireless link. The purpose is to deliver multiple QoS (Quality of Service) to multiple services within only one wireless link. Given the high carrier frequency and massive antennas, beamforming can be done more aggressively, enabling the convergence of multiple services in one wireless link. Meanwhile, these services may have very diverse KPIs (Key Performance Indicators) . As shown in FIG. 5, URLLC (Ultra-Reliable Low-Latency Communications) , mMTC (massive Machine Type Communication) , eMBB (enhanced Mobile Broadband) and Tbps communications may all be integrated in  one beam. This is challenging because different KPIs must be supported under the same wireless channel, SNR (Signal to Interference plus Noise Ratio) , fading, etc.

[0228] For two packets with different payload size and / or reliability / latency requirement, e.g. one eMBB packet with large payload size and another URLLC packet with small payload size and / or with higher reliability requirement, joint coding (or called mixed traffic coding) could be used for the two packets.

[0229] Joint coding (or called mixed traffic coding)

[0230] Joint coding refers to jointly encoding multiple packets (more than 1) into one codeword, e.g., jointly encoding a small packet (e.g., a URLLC packet) and a large packet (e.g., an eMBB packet) into one codeword. That is to say, there are multiple payloads in a joint codeword. For the joint encoding, there are two possible solutions:

[0231] Solution 1: encode multiple payloads into one codeword, where at least one payload is self-decodable (locally decodable) and global decodable.

[0232] Solution 2: encode multiple payloads into one codeword with unequal error protection.

[0233] For Solution 1, a self-decodable joint coding design is given, such that each individual payload (e.g., corresponding to a service) can be self-decoded, and at the same time joint decoding is supported to further enhance performance. Small messages (e.g., URLLC bits) are both locally and globally decodable, and a larger code block (e.g., containing eMBB bits) can be globally decodable. Specifically, local decoding is used as first attempt (lower reliable) . If the local decoding succeeded, the small code can be used for enhancing the larger code since the correctly received small code provides prior information for the decoding of the larger code. If the local decoding failed, global decoding with the larger code is used as second attempt (higher reliable) , that is, in the second attempt, the small code can be globally decoded (jointly decoded) with the larger code.

[0234] FIG. 6a and FIG. 6b are an illustration of self-decoding and joint-decoding (in the event of a self-decoding failure) . As an example, several smaller or shorter messages may be embedded or otherwise combined into a longer code block or payload, also referred to herein as a combined payload. These smaller messages are self-decodable, meaning that they can be decoded after collecting only a subset of code bits, or symbols, or LLRs, associated with a longer codeword rather than the entire, longer codeword. The subset of code bits is also a standalone short code or codeword that is decodable on its own.

[0235] Two or more of such smaller messages are also jointly-decodable. The subsets of code bits corresponding to smaller messages that are jointly-decodable combine into a longer code. This may be accomplished through what is referred to herein as “coupling” between bits from multiple messages. For example, some or all of the bits of a  first message (small code) may be copied and combined with bits of a second message (larger code) . In this example, bits from the first message may be directly copied and appended to or otherwise combined with the bits of the second message. Another possible option is to first transform bits from the first message, by multiplying them with a binary matrix for example, and then appending the transformed bits to, or otherwise combining the transformed bits with, the bits of the second message.

[0236] Although this example refers to information bit (message) coupling, it is feasible to also or instead use coded bits for coupling. In the case of systematic codes, for example, message bits are also part of code bits, and thus the two alternatives, for information bit coupling or code bit coupling, become much the same.

[0237] Some embodiments support multiple decoding attempts before requesting retransmission. Joint decoding, for example, may in effect be inserted or attempted between a decoding failure and a retransmission request. As an example, consider an embodiment that involves a three decoding attempt transmission approach. Referring to FIG. 6a and FIG. 6b, in a first decoding attempt, a receiver receives a codeword and decodes a first self-decodable payload of the codeword after receiving a corresponding minimum of required code bits. If the decoding of the first payload is successful (FIG. 6a) , then the correctly decoded bits can be used to enhance decoding performance for a second payload of the codeword, after a corresponding minimum required number of code bits for decoding of the second payload are received. A second decoding attempt is made if decoding of the first payload fails (FIG. 6b) . Instead of immediately requesting a retransmission, the receiver instead proceeds to attempt to jointly decode the first payload with the second payload. After decoding of the second payload, regardless of whether there is success or failure of the second payload decoding, joint decoding can increase probability that the first payload will be successfully decoded. In this example, if decoding of the first payload still fails after the second (joint) decoding attempt, then the receiver requests a retransmission (not shown) from the transmitter. This will incur some delay, but with a retransmission the receiver can make at least a third decoding attempt. With a retransmitted codeword, multiple decoding attempts may further be made, to self-decode from the retransmitted codeword, jointly decode from parts of the retransmitted codeword, and / or jointly decode using both the previously received codeword and the retransmitted codeword.

[0238] By adopting the above solution, since some or all of the bits of the small code are copied and combined with bits of the larger code due to the joint coding, on one hand, after a successful decoding of a self-decodable code, the code rate of at least another code (e.g., eMBB bits) can be reduced, therefore resulting in an improved performance. That is, an augmented eMBB is achieved. On the other hand, if a self-decodable code (e.g., URLLC)  fails to decode, instead of requesting a retransmission, the receiver proceeds to jointly decode the self-decodable code with the lager code. If the joint decoding is successfully, the code rate of the former can be reduced, resulting in an improved performance. That is, HARQ-less URLLC is achieved.

[0239] For Solution 2, a small URLLC packet is embedded to an eMBB packet. In short, the concept is one single FEC (Forward Error Correction) for multiple packets. In the encoder design, the priority order of the packets is taken into account, ensuring better protection for the packet with higher priority. Priority can be defined with different metrics, such as a reliability priority in terms of target BLER (Block Error Ratio) , a latency priority in terms of latency requirement, a source priority where packets may come from different sources, e.g., in relay and multi-hop scenarios.

[0240] The solution may use separate CRC to allow individual packet decoding. When a packet fails to be decoded, the HARQ scheme would request a retransmission of the joint codeword.

[0241] Solution 2 can be regarded as “priority-based payload mapping” . FIG. 7 is a schematic illustration of joint coding of Solution 2. Specifically, as shown in FIG. 7, payload data (or packets) can be from different applications (or different sources) . First, they are grouped by their QoS requirements and are CRC encoded separately. Then, a priority-based payload mapping procedure is performed to map each packet onto the information bit positions of a codeword according to reliability or latency. The reliability or latency of each bit depends on the specific channel coding scheme and decoding algorithms. FIG. 7 shows joint coding of two packets, i.e., an URLLC payload and an eMBB payload. In practice, there may be more than two packets jointly coded.

[0242] A possible enhancement of the above solution is to additionally protect the URLLC payload with an outer code. FIG. 8 is a schematic illustration of joint coding with the possible enhancement. This can achieve extra reliability for the URLLC payload. This is done by inserting another encoding process between CRC encoding and priority-based mapping, as shown in FIG. 8.

[0243] In the present disclosure, details on air interface designs for joint coding will be given, and the proposed air interface designs for join coding can be used in both of the above solutions.

[0244] Further, in the related art, HARQ procedure and related signaling design has not been given. In view of this, HARQ designs for joint coding will be given in the present disclosure, especially for supporting multiple scenarios of data transmission. For example, by taking joint coding for URLLC and eMBB services as an example, there may be several scenarios: Scenario 1: joint coding for URLLC (initial transmission) and eMBB (initial transmission) ; Scenario 2: joint coding for URLLC (retransmission (reTx) ) and eMBB (initial transmission) ;  Scenario 3: joint coding for URLLC (reTx) and eMBB (reTx) , assuming URLLC and eMBB services are jointly encoded in the previous transmission; Scenario 4: joint coding for URLLC (initial transmission) and eMBB (reTx) . The HARQ designs for joint coding given in the present disclosure can support at least the above Scenario 1, Scenario 2 and Scenario 3. It should be noted that other scenarios may also be supported, and will not be elaborated here for brevity.

[0245] The basic concepts of the present disclosure may be as follows. Two data portions are jointly encoded into one codeword by a network device. The network device will send to a terminal device downlink control information (DCI) which is indicative of whether joint coding is enabled for the codeword and indicative of scheduling information of the codeword. The terminal device can decode the received codeword according to the DCI to obtain one or both of the data portions intended for the terminal device. Further, if the two data portions are both for the terminal device and are put into two HARQ processes, the DCI is also indicative of an association of the two HARQ processes for joint encoding / decoding; and if the two data portions are put into one HARQ process, the DCI needs to be indicative of joint coding being used in this HARQ process. It should be noted that embodiments and examples herein are described by taking joint coding for two kinds of traffic data as examples, which may also be called mixed traffic coding. However, the present disclosure is not limited thereto, for example, the solutions of the present disclosure may also be applied to joint coding for more than two kinds of traffic data, or joint coding for different control information, or joint coding for control information and traffic data.

[0246] The above briefly describes technical concepts of the present disclosure, and then specific embodiments of the present disclosure will be elaborated in the following description.

[0247] FIG. 9 shows a schematic flowchart of a wireless communication method according to one or more embodiments of the present disclosure. The method can be implemented by a terminal device. As shown in FIG. 9, the method can include the following steps.

[0248] S901, a terminal device receives first DCI from a network device, where the first DCI is indicative of whether joint coding is enabled for first data and is indicative of scheduling information of the first data.

[0249] The terminal device may receive the first DCI from the network device. The first DCI is used for scheduling the first data. The first data may include one or multiple data portions (or payloads) . From the perspective of a source of the first data, the data portions in the first data may be from different services, for example, a data portion may be URLLC data, and another data portion may be eMBB data, etc. The data portions in the first data may also be from the same service. From the perspective of a destination of the first data, in an implementation, all  of the data portions in the first data are for the terminal device. In another implementation, depending on scheduling by the network device, the data portions in the first data may be for different terminal devices, and at least one of the data portions is for the terminal device receiving the first DCI.

[0250] Joint coding may be enabled for the first data, for example, for at least two data portions in the first data. The first DCI is indicative of whether the joint coding is enabled for the first data. Indication of whether the joint coding is enabled for the first data may be implemented explicitly. For example, the first DCI may include a joint coding indication field for indicating whether the joint coding is enabled for the first data. The indication of whether the joint coding is enabled for the first data may also be implemented implicitly. For example, some fields (e.g., HARQ-related fields) in the first DCI may be set as predefined values (e.g., invalid values) to indicate whether the joint coding is enabled or disabled. As an example, if all values in a HARQ process ID field, all values in a RV (redundancy version) field and all values in a NDI (new data indicator) field are set to ‘0’s, it means that the joint coding is disabled; otherwise, it means that the joint coding is enabled. It can be understood that the predefined values may be configured according to actual needs. If the joint coding is disabled, the network device may send the one or multiple data portions to the terminal device, or send one portion (e.g., URLLC data or eMBB data) of the one or multiple data portions to the terminal device.

[0251] In a case that the joint coding is enabled for the first data, the first DCI is indicative of the joint coding being enabled for the first data. In this case, the first data may include a first data portion and a second data portion, and the joint coding is enabled for the first data portion and at least part of the second data portion. In an implementation, the first data portion may have a smaller payload size than the second data portion. For example, the first data portion may be URLLC data, and the second data portion may be eMBB data. In an example, the first data portion may also have a higher reliability requirement than the second data portion. The first data portion may be jointly coded with a part of the second data portion, or jointly coded with the whole second data portion. As for which part of the second data portion is jointly coded with the first data portion, it may be configured (e.g., through an RRC signaling) or predefined, or may be indicated in the first DCI. In an implementation, Solution 1 or Solution 2 of the joint coding as described above may be applied for the joint coding for the first data, in which the first data portion may be the URLLC data of Solution 1 and Solution 2 and the second data portion may be the eMBB data of Solution 1 and Solution 2. In a specific implementation, information bits of the first data portion and information bits of the second data portion may be multiplexed in a MAC layer and then encoded, which also enables joint coding.

[0252] It should be noted that the solutions of the present disclosure can be applied to specific solutions where  the first data includes one or multiple data portions (or payloads) , and the first data portion and the second data portion thereof are jointly coded, and can also be applied to specific solutions where a first MAC PDU (Protocol Data Unit) and a second MAC PDU are jointly coded. In the following, implementations for the specific solutions where the first data portion and the second data portion are jointly coded will be described as examples, and it should be noted that they could also be applied to the specific solutions where the first MAC PDU and the second MAC PDU are jointly coded.

[0253] In an implementation, the first data portion and at least part of the second data portion are jointly encoded into a joint codeword. The joint codeword includes a plurality of encoded blocks generated by encoding the first data portion and the at least part of the second data portion with an error correction code, and the plurality of encoded blocks include a self-decodable encoded block corresponding to the first data portion. The self-decodable encoded block is decodable independently of other encoded blocks of the plurality of encoded blocks of the joint codeword, and the self-decodable encoded block is further decodable jointly with one or more of the other encoded blocks of the plurality of encoded blocks of the joint codeword.

[0254] The first DCI may be indicative of scheduling information of the first data. In an implementation, the scheduling information is indicative of resource information, decoding information (e.g., MCS, DMRS, etc. ) , HARQ-related information (HARQ process ID, NDI, RV, feedback resource information, feedback timing information, etc. ) and other information for the first data portion and the second data portion. In an implementation, two separate HARQ processes may be used for the first data portion and the second data portion, respectively. The first DCI may be indicative of an association of the two HARQ processes for the joint coding. For example, the scheduling information of the first data is indicative of a first HARQ process ID and first decoding information for the first data portion, and a second HARQ process ID and second decoding information for the second data portion. The first HARQ process ID and the second HARQ process ID may be different. In another implementation, the first data portion and the second data portion may share a HARQ process. For example, the scheduling information of the first data is indicative of a third HARQ process ID for the first data portion and the second data portion, first decoding information for the first data portion and second decoding information for the second data portion. In still another implementation where the information bits of the first data portion and the information bits of the second data portion are multiplexed in the MAC layer and then encoded, the scheduling information of the first data may be indicative of a joint HARQ process ID and joint decoding information for the first data.

[0255] In an implementation, the scheduling information of the first data may be further indicative of a feedback  manner for the first data. As an example, the scheduling information of the first data may be indicative of skipping feedback of the first data portion and performing feedback on the second data portion by the terminal device. As another example, the scheduling information of the first data may be indicative of performing feedback on both of the first data portion and the second data portion by the terminal device. In this example, the scheduling information of the first data may be indicative of respective feedback resource information and respective feedback timing information for the first data portion and the second data portion, or indicative of joint feedback resource information and joint feedback timing information for the first data portion and the second data portion.

[0256] In a case that the joint coding is not enabled for the first data, the first DCI is indicative of the joint coding being not enabled for the first data. In this case, the one or multiple data portions in the first data may be from the same or different services, and may all be for the terminal device. The one or multiple data portions may be separately coded by the network device. In this case, the first DCI may be indicative of resource information, decoding information (e.g., MCS, DMRS, etc. ) , HARQ-related information (HARQ process ID, NDI, RV, feedback resource information, feedback timing information, etc. ) and other information for respective data portions.

[0257] For example, the one or multiple data portions may include a third data portion and a fourth data portion. In an implementation, two separate HARQ processes may be used for the third data portion and the fourth data portion, respectively. The scheduling information of the first data may be indicative of the first HARQ process ID and third decoding information for the third data portion, and the second HARQ process ID and fourth decoding information for the fourth data portion. The first HARQ process ID and the second HARQ process ID may be different. Alternatively, the scheduling information of the first data may be indicative of the third HARQ process ID for the third data portion, and a fourth HARQ process ID for the fourth data portion may be determined based on the third HARQ process ID. In another implementation, the third data portion and the fourth data portion may share a HARQ process. For example, the scheduling information of the first data may be indicative of the third HARQ process ID for the third data portion and the fourth data portion, the third decoding information for the third data portion and the fourth decoding information for the fourth data portion.

[0258] S902, the terminal device receives the first data from the network device according to the first DCI.

[0259] The terminal device receives the first data from the network device according to the first DCI. Specifically, the terminal device may receive the first data on a physical downlink shared channel (PDSCH) scheduled by the first DCI.

[0260] S903, the terminal device performs decoding on the received first data according to the first DCI.

[0261] After receiving the first data, the terminal device may perform decoding on the received first data according to the first DCI. For example, the first DCI may be indicative of scheduling information of the first data, and the scheduling information may be indicative of resource information, decoding information (e.g., RV, NDI, MCS, etc. ) and other information for the first data.

[0262] In a case that the joint coding is enabled for the first data, the first data portion may be self-decodable by the terminal device according to the first DCI, and the first data may be jointly-decodable by the terminal device according to a self-decoding result of the first data portion and the first DCI.

[0263] In an implementation, the terminal device may make multiple decoding attempts before requesting retransmission. In a first decoding attempt, the terminal device performs self-decoding on the first data portion according to the first DCI. Specifically, the self-decoding on the first data portion may be performed after receiving a corresponding minimum of required code bits of the first data portion. If a self-decoding result of the first data portion is that the self-decoding of the first data portion is successful, then the correctly decoded bits can be used to enhance decoding performance for the second data portion, after a corresponding minimum of required code bits of the second data portion are received. A second decoding attempt will be made if the self-decoding result of the first data portion is that the self-decoding of the first data portion fails. Instead of immediately requesting a retransmission, the terminal device may instead proceed to attempt to jointly decode the first data portion with the second data portion. After the joint decoding, regardless of whether the second data portion is decoded successfully or not, the joint decoding can increase a probability that the first data portion will be successfully decoded. In this example, if the decoding of the first data portion still fails after the second (joint) decoding attempt, then the terminal device may request a retransmission from the network device. With a retransmission, the terminal device can make at least a third decoding attempt. It should be noted that with the retransmitted data, multiple decoding attempts may further be made, for example, to perform self-decoding from the retransmitted data, perform joint decoding from parts of the retransmitted data, and / or perform joint decoding using both the previously received first data and the retransmitted data.

[0264] In a case that a data portion (e.g., the first data portion or the second data portion) obtained by the decoding is not for the terminal device, the terminal device may discard the data portion which is not for the terminal device.

[0265] It should be noted that the above embodiments are described by taking joint coding for two data portions (two kinds of traffic data) as examples, which may also be called mixed traffic coding. However, the above  embodiments may also be applied to joint coding for different control information, or joint coding for control information and traffic data.

[0266] With the wireless communication method provided by the present disclosure, the terminal device receives the first DCI from the network device, where the first DCI is indicative of whether joint coding is enabled for the first data and is indicative of the scheduling information of the first data; the terminal device receives the first data from the network device, and performs decoding on the received first data according to the first DCI. Since joint coding is involved and whether the joint coding is enabled for the first data is indicated, a success rate of decoding of the first data and reliability thereof can be improved and a code rate can be reduced, resulting in an improved performance.

[0267] In the above, the wireless communication method of the present disclosure is described from the perspective of the terminal device in combination with FIG. 9. In the following, a wireless communication method of the present disclosure will be described from the perspective of a network device in combination with FIG. 10. FIG. 10 shows a schematic flowchart of another wireless communication method according to one or more embodiments of the present disclosure. The method can be implemented by a network device. As shown in FIG. 10, the method can include the following steps.

[0268] S1001, a network device sends first DCI to a terminal device, where the first DCI is indicative of whether joint coding is enabled for first data and is indicative of scheduling information of the first data.

[0269] S1002, the network device sends the first data to the terminal device, to enable the terminal device to perform decoding on the first data according to the first DCI.

[0270] For S1001 and S1002, reference may be made to the description for S901-S903, which will not be repeated here.

[0271] Further, before S1001 and S1002, the network device may determine whether to enable joint coding for data portions to be transmitted, e.g., due to actual needs. If the joint coding is needed, the network device may perform joint coding on a first payload and at least part of a second payload to generate the first data including the first data portion and the second data portion, where the first data portion corresponds to the first payload and is self-decodable, and the second data portion corresponds to the second payload. For specific implementations of joint code, reference may be made to the above description in section “Joint coding (or called mixed traffic coding) ” in combination with FIG. 6a, FIG. 6b, FIG. 7 and FIG. 8. In this case, the first DCI is indicative of the joint coding being enabled for the first data.

[0272] If the joint coding is not needed, the network device may perform coding on the one or multiple data portions separately to generate the first data, and the generated first data includes the one or multiple data portions. In this case, the first DCI is indicative of the joint coding being not enabled for the first data.

[0273] With the wireless communication method provided by the present disclosure, the network device sends the first DCI to the terminal device, where the first DCI is indicative of whether joint coding is enabled for the first data and is indicative of the scheduling information of the first data; and the network device sends the first data to the terminal device, to enable the terminal device to perform decoding on the received first data according to the first DCI. Since joint coding is involved and whether the joint coding is enabled for the first data is indicated, a success rate of decoding of the first data and reliability of the first data can be improved and a code rate can be reduced, resulting in an improved performance.

[0274] In order to elaborate the wireless communication methods of the present disclosure more clearly, in the following, taking the first data portion being URLLC data and the second data portion being eMBB data as an example, the method will be described in more details.

[0275] FIG. 11 is a schematic flowchart of still another wireless communication method according to one or more embodiments of the present disclosure. This method includes the following steps.

[0276] S1101, a network device sends first DCI to a terminal device, where the first DCI is indicative of whether joint coding is enabled for first data and is indicative of scheduling information of the first data.

[0277] S1102, the terminal device receives the first DCI from the network device.

[0278] The first DCI may be used for scheduling the first data. The first data may include one or multiple data portions (or payloads) . From the perspective of a source of the first data, the data portions in the first data may be from different services, for example, a data portion may be URLLC data, and another data portion may be eMBB data, etc. The data portions in the first data may also be from the same service. From the perspective of a destination of the first data, in an implementation, all of the data portions in the first data are for the terminal device. In another implementation, depending on scheduling by the network device, the data portions in the first data may be for different terminal devices, and at least one of the data portions is for the terminal device receiving the first DCI.

[0279] Joint coding may be enabled for the first data, for example, for at least two data portions in the first data. Before S1101, the network device may first determine whether to enable joint coding for data portions to be transmitted, e.g., due to actual needs. If the joint coding is needed, the network device may perform joint coding on a first payload and at least part of a second payload to generate the first data including the first data portion and the  second data portion, where the first data portion corresponds to the first payload and is self-decodable, and the second data portion corresponds to the second payload. In an implementation, the first data portion (corresponding to the first payload) may have a smaller payload size than the second data portion (corresponding to the second payload) . In an example, the first data portion (corresponding to the first payload) may also have a higher reliability requirement than the second data portion (corresponding to the second payload) . In the following description, URLLC data will be taken as an example of the first data portion (or the first payload) , and eMBB data will be taken as an example of the second data portion (or the second payload) . The first DCI may schedule one TB (transport block) for the URLLC data (also referred to as a URLLC packet) , and may schedule one or two TBs for the eMBB data (also referred to as an eMBB packet) . When two TBs of the eMBB data are scheduled, spatial multiplexing may be employed. Each TB may correspond to one or multiple CBs (code blocks) . In some examples, the first DCI may schedule one or multiple TBs for the URLLC data and one or multiple TBs for the eMBB data, where the TBs of the URLLC data may be jointly coded with part of the TBs of the eMBB data. If the joint coding is not needed, the network device may perform coding on one or multiple data portions separately to generate the first data, and the generated first data includes the one or multiple data portions. Or, if the joint coding is disabled, the network device may perform coding on one portion (e.g., URLLC data or eMBB data) of the one or multiple data portions and send the one portion to the terminal device.

[0280] The first DCI is indicative of whether the joint coding is enabled for the first data. Indication of whether the joint coding is enabled for the first data may be implemented explicitly. For example, the first DCI may include a joint coding indication field for indicating whether the joint coding is enabled for the first data.

[0281] In a case that the joint coding is enabled for the first data, the first DCI is indicative of the joint coding being enabled for the first data. The joint coding may be enabled for the URLLC data and at least part of the eMBB data. The URLLC data and at least part of the eMBB data may be jointly encoded into one codeword, and the codeword may correspond to one or multiple CBs. Specifically, the URLLC data may be jointly coded with a part of the eMBB, or jointly coded with the whole eMBB data. As for which part of the eMBB data is jointly coded with the URLLC data, it may be configured (e.g., through an RRC signaling) or predefined, or may be indicated in the first DCI. For example, the URLLC CB may be jointly encoded with one or multiple CBs of the eMBB data, which can be configured or predefined. In an implementation, Solution 1 or Solution 2 of the joint coding as described above may be applied for the joint coding for the first data. In a specific implementation, information bits of the URLLC data and information bits of the eMBB data may be multiplexed in a MAC layer and then encoded, which  also enables joint coding. It should be noted that the solutions of the present disclosure can be applied to specific solutions where the first data includes one or multiple data portions (or payloads) , and the first data portion and the second data portion thereof are jointly coded, and can also be applied to specific solutions where a first MAC PDU and a second MAC PDU are jointly coded. For the implementation of the joint coding, there may be two manners as follows.

[0282] Manner 1: the URLLC data and one CB of the eMBB data may be jointly encoded into a joint codeword, where a corresponding CB index for the CB of the eMBB data for forming the joint codeword may be predefined or indicated (e.g., by DCI) or configured (e.g., through an RRC (radio resource control) signaling) . That is, which part of the eMBB data is used for forming the joint codeword and further which part is specifically jointly coded with the URLLC data may be configured (e.g., through an RRC signaling) or predefined, or may be indicated in the first DCI.

[0283] In an example, as shown in FIG. 12, which shows a schematic diagram of an example of joint coding, the CB of the URLLC data is jointly encoded with CB0 (as predefined, for example) of the eMBB data to form a joint codeword. In this example, after receiving the joint codeword, the terminal device could perform self-decoding and / or joint decoding to derive the URLLC data. In another example (not shown) , CB0 and CB1 of the eMBB data may be used for forming the joint codeword, and the URLLC data is jointly encoded with CB0. It could be understood that in this case, the joint codeword also includes information of CB1 which is used for forming the joint codeword but is not jointly coded with the URLLC data. In still another example (not shown) , CB0-CBN of the eMBB data may be used for forming the joint codeword, and the URLLC data is jointly encoded with CB0. Similarly, in this case, the joint codeword also includes information of CB1-CBN which are used for forming the joint codeword but are not jointly coded with the URLLC data. For ease of description, the joint codeword (or the first codeword) in this case will also be called jointly code data or joint codeword in the present disclosure.

[0284] In a specific implementation of Manner 1, a limitation of maximum encoded information length in channel coding is considered, and it is assumed that the maximum encoded information length is to be reached, e.g., with the total number of information bits being Nmax. When the URLLC data and a CB of the eMBB data are jointly encoded, the URLLC data may occupy some of the information bits, resulting in the length of codable information of the CB being smaller than Nmax. Thus, in an example of the present disclosure, different CBs of the eMBB data may have different payload sizes, for example, a payload size of CB0 may be smaller than payload sizes of CB1-CBN, and in this case, CB0 with the smaller payload size is jointly coded with the URLLC data.

[0285] In an implementation, the joint codeword includes a plurality of encoded blocks generated by encoding the URLLC data and the part of the eMBB data with an error correction code, and the plurality of encoded blocks include a self-decodable encoded block corresponding to the URLLC data. The self-decodable encoded block is decodable independently of other encoded blocks of the plurality of encoded blocks of the joint codeword, and the self-decodable encoded block is further decodable jointly with one or more of the other encoded blocks of the plurality of encoded blocks of the joint codeword.

[0286] Continuing with the above example of FIG. 12, the CB of the URLLC data and the CB0 of the eMBB data are jointly encoded into a codeword (i.e., the joint codeword) . The CB of the URLLC data (as shown in the shaded area of FIG. 12) in the joint codeword is self-decodable. The CB of the URLLC data represents URLLC information, the CB0 of the eMBB data represents eMBB data, and after the joint coding, the joint codeword contains information of URLLC data and eMBB data. It should be noted that data in the spotted area of FIG. 12 includes not only information of the CB0 of the eMBB data (e.g., corresponding to the larger code of FIG. 6a and FIG. 6b) but also information of some or all of bits of the URLLC data embedded by joint coding. In this way, after a successful self-decoding of the URLLC data in the shaded area, the URLLC data can be used for enhancing the decoding of the CB0 of the eMBB data, since the correctly decoded URLLC data provides prior information for the decoding of the data in the spotted area which includes information of the CB0 of the eMBB data and some or all of bits of the URLLC data that are already decoded correctly. Thus, augmented eMBB is achieved. However, for ease of description, the data in the spotted area will be simply called the eMBB data (or the second data portion) in the following description, and it should be understood that the data also includes some or all bits of the URLLC data embedded.

[0287] Manner 2: the URLLC data and more than one CBs of the eMBB data may be jointly encoded into a joint codeword (not shown) , where the number of CBs subject to the joint coding and corresponding CB indexes may be predefined or indicated (e.g., by DCI) or configured (e.g., through an RRC signaling) . For example, the CB of the URLLC data may be jointly encoded with the whole eMBB data, i.e., CB0-CBN (the n-th CB) of the eMBB data, to form a joint codeword. Specifically, the URLLC data and N+1 CBs may be jointly encoded into N+1 encoded blocks, each encoded block including the URLLC data. Manner 2 can be beneficial for further improving URLLC reliability, e.g. the URLLC data can be repeated and jointly encoded with multiple CBs.

[0288] In the following description, Manner 1 will be taken as an example of the implementation of the joint coding. It should be understood that Manner 2 could also be applied.

[0289] The first DCI may be indicative of scheduling information of the first data. In an implementation, the scheduling information is indicative of resource information, decoding information (e.g., MCS, DMRS, etc. ) , HARQ-related information (HARQ process ID, NDI, RV, feedback resource information, feedback timing information, etc. ) and other information for the URLLC data and the eMBB data.

[0290] In a first implementation, two separate HARQ processes may be used for the URLLC data and the eMBB data, respectively. In this implementation, a TB for the URLLC data (high reliability data) in one HARQ process and another TB for the eMBB data (low reliability data) in another HARQ process may be jointly encoded, in which the URLLC data can be locally self-decoded and globally decoded, and the eMBB data can be globally decoded. The first DCI may be indicative of an association of the two HARQ processes for the joint coding. For example, the scheduling information of the first data is indicative of a first HARQ process ID and first decoding information for the URLLC data, and a second HARQ process ID and second decoding information for the eMBB data. The first HARQ process ID and the second HARQ process ID may be different. FIG. 13 shows a schematic diagram of an example of joint coding with separate HARQ processes. As shown in FIG. 13, the CB of the URLLC data is jointly encoded with the CB0 of the eMBB data. A HARQ process with HARQ process ID1 is used for the URLLC data, and a HARQ process with HARQ process ID2 is used for the eMBB data. HARQ process ID1 and HARQ process ID2 are different.

[0291] In a specific implementation, the first DCI may include a first HARQ-related field and a second HARQ-related field, and the second HARQ-related field may include M HARQ-related subfields, where a value of M is configured by the network device or is predefined. For example, the value of M may be the number of spatial multiplexed parts of the eMBB data. As an example, if two TBs of the eMBB data are scheduled by the first DCI and are spatial multiplexed, the value of M may be 2. The first HARQ process ID and the first decoding information for the URLLC data may be carried in the first HARQ-related field. For the eMBB data, due to a spatial multiplexing situation, different cases will be considered. In a case that spatial multiplexing is enabled for the eMBB data, the second HARQ process ID and decoding information of the eMBB data may be carried in the M HARQ-related subfields. In an example, each of the M HARQ-related subfields may carry decoding information of one of the spatial multiplexed parts of the eMBB data, and the second HARQ process ID may be carried in one of the M HARQ-related subfields, e.g., based on an RRC configuration or an agreement. In another example, the second HARQ-related field may further include a HARQ process ID field for carrying the second HARQ process ID. In a case that spatial multiplexing is not enabled for the eMBB data, the second HARQ process ID and decoding information of  the eMBB data may be carried in a predefined HARQ-related subfield among the M HARQ-related subfields.

[0292] This specific implementation may be applied to Case 1-1 in which the first DCI could schedule one TB for the URLLC data and two TBs for the eMBB data, where one URLLC TB and one eMBB TB are jointly encoded. Example 1 of Case 1-1 will be briefly described here.

[0293] In Example 1, the first DCI may include a joint coding indication field (or called joint coding indicator) for indicating whether joint coding is enabled for the data (on a PDSCH or a PUSCH) scheduled by the first DCI. For example, the joint coding indication field may have 1 bit, whose value being ‘1’ may indicate that the joint coding is enabled, and whose value being ‘0’ may indicate that the joint coding is disabled.

[0294] In this example, the first DCI may also include a HARQ process number-1 (HARQ process ID-1) related field (corresponding to the first HARQ-related field) and a HARQ process number-2 (HARQ process ID-2) related field (corresponding to the second HARQ-related field) .

[0295] If the joint coding is enabled, the HARQ process ID-1 related field may be used for the URLLC data (one TB) . The terminal device assumes joint coding of the TB with HARQ process ID-1 and the TB with HARQ process ID-2. The HARQ process with HARQ process ID-1 is for the URLLC TB. The TB in this HARQ process is self-decodable, and if failed, can be jointly decoded with the TB with HARQ process ID-2. The HARQ process ID-1 related field may also include redundancy version information (RV-1) , modulation code scheme information (MCS-1) and a new data indicator (NDI-1) for the TB with HARQ process ID-1. Exemplarily, the self-decodable TB (or CB) may be put in the HARQ process with HARQ process ID-1 by default.

[0296] The HARQ process ID-2 related field may be used for the eMBB data (one or two TBs) . The HARQ process with HARQ process ID-2 is for the eMBB TB (s) . If spatial multiplexing is not enabled (e.g. by RRC configuration) , up to one TB could be scheduled. The HARQ process ID-2 related field may include redundancy version information (RV-2) , modulation code scheme information (MCS-2) and a new data indicator (NDI-2) for the TB with HARQ process ID-2. If spatial multiplexing is enabled (e.g. by RRC configuration) , up to two TBs could be scheduled. At this time, the HARQ process ID-2 related field may include redundancy version information (RV-2) , modulation code scheme information (MCS-2) and a new data indicator (NDI-2) for the first TB with HARQ process ID-2 (RV-2) , as well as redundancy version information (RV-3) , modulation code scheme information (MCS-3) and a new data indicator (NDI-3) for the second TB associated to HARQ process ID-2.

[0297] In another specific implementation, the first DCI may include a third HARQ-related field and a fourth HARQ-related field. The first HARQ process ID and the first decoding information for the URLLC data may be  carried in the third HARQ-related field, and the second HARQ process ID and the second decoding information for the eMBB data may be carried in the fourth HARQ-related field.

[0298] This specific implementation may be applied to Case 1-2 in which the first DCI could schedule one TB for the URLLC data and one TB for the eMBB data, or could schedule two TBs for the eMBB data. Example 2 of Case 1-2 will be briefly described here.

[0299] In Example 2, the first DCI may include a joint coding indication field (or called joint coding indicator) for indicating whether joint coding is enabled for the data (PDSCH or PUSCH) scheduled by the first DCI. For example, the joint coding indication field may have 1 bit, whose value being ‘1’ may indicate that the joint coding is enabled, and whose value being ‘0’ may indicate that the joint coding is disabled.

[0300] In this example, the first DCI may also include a HARQ process number-1 (HARQ process ID-1) related field (corresponding to the third HARQ-related field) and a HARQ process number-2 (HARQ process ID-2) related field (corresponding to the fourth HARQ-related field) .

[0301] If the joint coding is enabled, the HARQ process ID-1 related field may be used for the URLLC data (one TB) . It should be noted that the terminal device assumes joint coding of the TB with HARQ process ID-1 and the TB with HARQ process ID-2. The HARQ process with HARQ process ID-1 is for the URLLC TB. The TB in this HARQ process is self-decodable, and if failed, can be jointly decoded with the TB with HARQ process ID-2. The HARQ process ID-1 related field may also include redundancy version information (RV-1) , modulation code scheme information (MCS-1) and a new data indicator (NDI-1) for the TB with HARQ process ID-1.

[0302] The HARQ process ID-2 related field may be used for the eMBB data (one TB) . The HARQ process with HARQ process ID-2 is for the eMBB TB. The HARQ process ID-2 related field may include redundancy version information (RV-2) , modulation code scheme information (MCS-2) and a new data indicator (NDI-2) for the TB with HARQ process ID-2.

[0303] It can be seen that compared to Example 1 of Case 1-1, RV-3 and NDI-3 may be omitted in the first DCI in Example 2 since up to two TBs could be scheduled by the first DCI, that is, the first DCI in Example 2 does not include RV-3 and NDI-3.

[0304] In a second implementation, the URLLC data and the eMBB data may share a HARQ process. In this implementation, the HARQ process can support one TB for the URLLC data and another TB for the eMBB data. There may be one HARQ buffer for the eMBB data, and another HARQ buffer for the URLLC data. The terminal device or the network device may flush the two HARQ buffers when both the URLLC data and the eMBB data are  successfully decoded. In an example, the scheduling information of the first data is indicative of a third HARQ process ID (i.e., a shared HARQ process ID) for the URLLC data and the eMBB data, first decoding information for the URLLC data and second decoding information for the eMBB data.

[0305] In a specific implementation, the first DCI may include a third HARQ process field, a fifth HARQ-related field and a sixth HARQ-related field. The third HARQ process ID may be carried in the third HARQ process field. The first decoding information for the URLLC data may be carried in the fifth HARQ-related field and the second decoding information for the eMBB data may be carried in the sixth HARQ-related field.

[0306] For this specific implementation, Example 3 will be briefly described here.

[0307] In Example 3, the first DCI may include a joint coding indication field (or called joint coding indicator) for indicating whether joint coding is enabled for the data scheduled by the first DCI. For example, the joint coding indication field may have 1 bit, whose value being ‘1’ may indicate that the joint coding is enabled, meaning that at least one TB scheduled by the first DCI is jointly coded, and whose value being ‘0’ may indicate that the joint coding is disabled, meaning that none of the TBs scheduled by the first DCI is jointly coded.

[0308] In this example, the first DCI may also include a HARQ process ID field (corresponding to the third HARQ process field) and two HARQ process ID related fields (corresponding to the fifth HARQ-related field and the sixth HARQ-related field) . The shared HARQ process ID for the URLLC data and the eMBB data may be carried in the HARQ process ID field.

[0309] If the joint coding is enabled, the fifth HARQ-related field may be used (or predefined) for the URLLC data (one TB) . That is, the fifth HARQ-related field may carry scheduling information of the URLLC TB. The URLLC TB in this HARQ process is self-decodable, and if failed, can be jointly decoded with another TB in the same HARQ process. Specifically, the fifth HARQ-related field may include redundancy version information (RV-1) , modulation code scheme information (MCS-1) and a new data indicator (NDI-1) for the URLLC TB.

[0310] The sixth HARQ-related field may be used (or predefined) for the eMBB data (one TB) . That is, the sixth HARQ-related field may carry scheduling information of the eMBB TB. Specifically, the sixth HARQ-related field may include redundancy version information (RV-2) , modulation code scheme information (MCS-2) and a new data indicator (NDI-2) for the eMBB TB.

[0311] Now, more details and examples for the DCI fields in the second implementation will be given for different scenarios.

[0312] In an example for Scenario 1 (joint coding for URLLC (initial transmission) and eMBB (initial  transmission) ) , both information bits of the URLLC data and information bits of the eMBB data are transmitted. In the first DCI, the joint coding indicator (i.e., the joint coding indication field) indicates that the joint coding is enabled. And both NDI-1 and NDI-2 are toggled, so the terminal device knows that the URLLC data and the eMBB data are jointly coded, and both of them are initial transmissions.

[0313] FIG. 14 shows an example for Scenario 2 (joint coding for URLLC (reTx) and eMBB (initial transmission) ) . As shown in FIG. 14, in a first transmission (1st Tx) , only one TB for the URLLC data is transmitted, and the first DCI indicates a HARQ process ID=M. The NDI for the URLLC data is toggled, indicating an initial transmission of the URLLC data. The joint coding is disabled in the first transmission. In a second transmission (2nd Tx) , the first DCI indicates the same HARQ process ID (i.e., ID=M) , and the NDI for the URLLC data is not toggled, indicating a retransmission of the URLLC data. Also, the first DCI indicates that the joint coding is enabled, and indicates an initial transmission of the eMBB data (e.g., by the NDI for the eMBB data) . Thus, the terminal device knows that the retransmitted URLLC data is jointly coded with the initial transmitted eMBB data. For HARQ buffer management, in the first transmission, the terminal device buffers the URLLC TB, and in the second transmission, the terminal device buffers the joint codeword of the URLLC data and the eMBB data. Then the terminal device performs HARQ combining of the URLLC TB from the first transmission and the URLLC TB from the second transmission. It could be understood that the URLLC TB from the second transmission may include a self-decoded result and a jointly-decoded result for the URLLC data.

[0314] In Scenario 3 (joint coding for URLLC (reTx) and eMBB (reTx) ) , it is assumed that the URLLC data and the eMBB data are jointly encoded in an initial transmission. Scenario 3 may include a case where one of the URLLC data and the eMBB data is successfully decoded and another is failed in the initial transmission. FIG. 15 shows an example for Scenario 3. As shown in FIG. 15, in a first transmission (1st Tx) , the URLLC data and the eMBB data are jointly encoded and transmitted, and the first DCI indicates that the joint coding is enabled and also indicates a HARQ process ID=M (i.e., a shared HARQ process ID) . Both NDIs for the URLLC data and the eMBB data are toggled, indicating an initial transmission of the URLLC data and an initial transmission of the eMBB data. The URLLC data is successfully decoded but the eMBB data is failed in the first transmission. In a second transmission (2nd Tx) , the first DCI indicates that the joint coding is enabled and also indicates the same HARQ process ID (i.e., ID=M) . The NDI for the eMBB data is not toggled, indicating a retransmission of the eMBB data. In the second transmission, the URLLC data which is self-decodable (as shown in the shaded area of FIG. 15) is not transmitted since the URLLC data is successfully decoded. For example, there may be no URLLC transmission  indication. It could be understood that although the URLLC data which is self-decodable (as shown in the shaded area of FIG. 15) is not transmitted in the second transmission, the retransmitted data (as shown in the spotted area of FIG. 15) includes not only the eMBB data but also some or all bits of the URLLC data embedded due to the joint coding, and the joint coding is indicated as being enabled in the second transmission.

[0315] FIG. 16 shows another example for Scenario 3. As shown in FIG. 16, in a first transmission (1st Tx) , the URLLC data and the eMBB data are jointly encoded and transmitted, and the first DCI indicates that the joint coding is enabled and also indicates a HARQ process ID=M (i.e., a shared HARQ process ID) . Both NDIs for the URLLC data and the eMBB data are toggled, indicating an initial transmission of the URLLC data and an initial transmission of the eMBB data. The URLLC data is successfully decoded but the eMBB data is failed in the first transmission. In a second transmission (2nd Tx) , the first DCI indicates that the joint coding is enabled and also indicates the same HARQ process ID (i.e., ID=M) . The NDI for the eMBB data is not toggled, indicating a retransmission of the eMBB data. And the NDI for the URLLC data is toggled, indicating a new transmission of the URLLC data. Since the eMBB data is jointly coded with the previous URLLC TB in the first transmission, the terminal device knows that the eMBB data is not jointly coded with the new URLLC TB, and the new URLLC TB is independently coded, i.e., without joint coding. It could be understood that since the retransmitted eMBB data is jointly coded with the previous URLLC TB in the first transmission, the joint coding is also indicated as being enabled in the second transmission.

[0316] In a third implementation, the information bits of the URLLC data and the information bits of the eMBB data may be multiplexed in a MAC layer and then encoded. That is, one joint TB (i.e., the first data) for joint eMBB and URLLC information is formed. In this way, the joint coding for the URLLC data and the eMBB data could be enabled. In this implementation, the network device may indicate which part of the TB is for the URLLC data (e.g. the location of bits for the URLLC data) and / or indicate which part of the TB is for the eMBB data (e.g. the location of bits for the URLLC data) . The first DCI may indicate whether the TB is a jointly-coded TB (or a mixed traffic TB) . If it is indicated that the TB is a jointly-coded TB, the joint coding is enabled in this transmission. In this implementation, one HARQ process is used for the eMBB data and the URLLC data. The scheduling information of the first data may be indicative of a joint HARQ process ID (corresponding to the one HARQ process) and joint decoding information for the first data. In a specific implementation, the first DCI may include a joint HARQ-related field, and the joint HARQ process ID and the joint decoding information for the first data may be carried in the joint HARQ-related field.

[0317] In a case that the joint coding is not enabled for the first data, the first DCI is indicative of the joint coding  being not enabled for the first data. In this case, the first data may include one or multiple data portions. The one or multiple data portions in the first data may be from the same service and may all be for the terminal device. For example, the one or multiple data portions may be URLLC data or eMBB data. The one or multiple data portions may be separately coded by the network device. In this case, the first DCI may be indicative of resource information, decoding information (e.g., MCS, DMRS, etc. ) , HARQ-related information (HARQ process ID, NDI, RV, feedback resource information, feedback timing information, etc. ) and other information for the one or multiple data portions.

[0318] Returning to the above first implementation, in a specific implementation, the first DCI may include the first HARQ-related field and the second HARQ-related field. A HARQ process ID and decoding information of the one or multiple data portions may be carried in the first HARQ-related field and / or the second HARQ-related field based on a predefined rule or an RRC configuration.

[0319] Example 1 of Case 1-1 will be further described here. In Example 1, additionally, if the joint coding is disabled, the HARQ process ID-1 related field may be disabled, i.e., bits of the HARQ process ID-1 and corresponding RV-1, MCS-1 and NDI-1 are reserved. The HARQ process ID-2 related field can be used to schedule the one or multiple data portions, i.e., the URLLC data or the eMBB data. At this time, up to two TBs could be scheduled by the first DCI. Alternatively, the HARQ process ID-2 related field may be disabled, i.e., bits of the HARQ process ID-2 and corresponding RV-2, MCS-2, NDI-2, RV-3, MCS-3 and NDI-3 are reserved. The HARQ process ID-1 related field can be used to schedule the URLLC data or the eMBB data. At this time, up to one TB could be scheduled by the first DCI.

[0320] In another specific implementation, the first DCI may include the third HARQ-related field and the fourth HARQ-related field. A HARQ process ID and decoding information of the one or multiple data portions may be carried in the third HARQ-related field and / or the fourth HARQ-related field based on a predefined rule and a spatial multiplexing situation of the first data or based on an RRC configuration and a spatial multiplexing situation of the first data.

[0321] Example 2 of Case 1-2 will be further described here. In Example 2, additionally, if the joint coding is disabled, a spatial multiplexing situation of the first data will be considered. If spatial multiplexing is not enabled (e.g., by an RRC configuration) , up to one TB could be scheduled. At this time, the HARQ process ID-1 related field (or the HARQ process ID-2 related field) may be disabled, i.e., bits of the HARQ process ID-1 (or the HARQ process ID-2) and corresponding RV-1, MCS-1 and NDI-1 (or corresponding RV-2, MCS-2 and NDI-2) are reserved. If spatial multiplexing is enabled (e.g., by the RRC configuration) , up to two TBs could be scheduled. Whether two  TBs are enabled in this transmission may depend on the indicated number of layers, e.g., indicated by DCI. At this time, the HARQ process ID-1, RV-1, MCS-1 and NDI-1 are used for one of the two TBs, and the HARQ process ID-2, RV-2, MCS-2 and NDI-2 are used for another TB.

[0322] In an implementation, the one or multiple data portions may include a third data portion (e.g., TB1) and a fourth data portion (e.g., TB2) . In an example, two separate HARQ processes may be used for the third data portion and the fourth data portion, respectively. The scheduling information of the first data may be indicative of the first HARQ process ID and third decoding information for the third data portion (TB1) , and the second HARQ process ID and fourth decoding information for the fourth data portion (TB2) . Alternatively, the third data portion (TB1) may use the third HARQ process ID, and the scheduling information of the first data may be indicative of the third HARQ process ID for the third data portion (TB1) . At this time, a fourth HARQ process ID for the fourth data portion (TB2) may be determined based on the third HARQ process ID. In another example, the third data portion and the fourth data portion may share a HARQ process. For example, both of the third data portion (TB1) and the fourth data portion (TB2) use the third HARQ process ID. The scheduling information of the first data may be indicative of the third HARQ process ID for the third data portion (TB1) and the fourth data portion (TB2) , the third decoding information for the third data portion (TB1) and the fourth decoding information for the fourth data portion (TB2) .

[0323] More details will be given in combination with the above second implementation. In a specific implementation, the first DCI may include the third HARQ process field, the fifth HARQ-related field and the sixth HARQ-related field. Additionally, decoding information of the one or multiple data portions may be carried in the fifth HARQ-related field and / or the sixth HARQ-related field based on a predefined rule or an RRC configuration.

[0324] Example 3 will be further described here. In Example 3, additionally, if the joint coding is disabled, MCS-1, NDI-1 and RV-1 in the first DCI may be used as scheduling information for TB1, and MCS-2, NDI-2 and RV-2 in the first DCI may be used as scheduling information for TB2. The third HARQ process ID carried in the third HARQ process filed of the first DCI may be used for both TB1 and TB2. Alternatively, TB1 may use the third HARQ process ID, and the fourth HARQ process ID for TB2 may be determined based on the third HARQ process ID.

[0325] In the above examples, indication of whether the joint coding is enabled for the first data may be included in the first DCI explicitly, e.g., in the joint coding indication field. In an implementation, the indication of whether the joint coding is enabled for the first data may also be implemented implicitly. For example, some fields (used for  other functions, e.g., HARQ-related fields) in the first DCI may be set as predefined values (e.g., invalid values) to indicate whether the joint coding is enabled or disabled. It can be understood that the predefined values may be configured according to actual needs.

[0326] As an example, in the above Case 1-1, if the joint coding is not enabled, the HARQ process ID-1 related field may be disabled, i.e., bits of the HARQ process ID-1 and corresponding RV-1, MCS-1 and NDI-1 are reserved. The predefined values may be all ‘0’s in the HARQ process ID-1 field, all ‘0’s in RV-1, all ‘0’s in MCS-1, and all ‘1’s in NDI-1. If the values in the HARQ process ID-1 related field are the same as the above predefined value, the terminal device knows that the joint coding is not disabled in this transmission.

[0327] As another example, also in the above Case 1-1, if the joint coding is not enabled, the HARQ process ID-2 related field may be disabled, i.e., bits of the HARQ process ID-2 and corresponding RV-2, MCS-2, NDI-2, RV-3, MCS-3 and NDI-3 are reserved. The HARQ process ID-1 related field can be used to schedule the URLLC data or the eMBB data. At this time, up to one TB could be scheduled by the first DCI. The predefined values may be all ‘0’s in the HARQ process ID-2 field, all ‘0’s in RV-2, all ‘0’s in MCS-21, and all ‘1’s in NDI-2. If the values in the HARQ process ID-2 related field are the same as the above predefined value, the terminal device knows that the joint coding is not disabled in this transmission.

[0328] S1103, the network device sends the first data to the terminal device.

[0329] S1104, the terminal device receives the first data from the network device, and performs decoding on the received first data according to the first DCI.

[0330] The terminal device receives the first data from the network device according to the first DCI. Specifically, the terminal device may receive the first data on a physical downlink shared channel (PDSCH) scheduled by the first DCI.

[0331] After receiving the first data, the terminal device may perform decoding on the received first data according to the first DCI. Specifically, in a case that the joint coding is enabled for the first data, the first data portion (e.g., the URLLC data) may be self-decodable by the terminal device according to the first DCI, and the first data may be jointly-decodable by the terminal device according to a self-decoding result of the URLLC data and the first DCI.

[0332] In an implementation, the terminal device may make multiple decoding attempts before requesting retransmission. In a first decoding attempt, the terminal device performs self-decoding on the URLLC data according to the first DCI. Specifically, the self-decoding on the URLLC data may be performed after receiving a corresponding  minimum of required code bits of the URLLC data. If a self-decoding result of the URLLC data is that the self-decoding of the URLLC data is successful, then the correctly decoded bits can be used to enhance decoding performance for the second data portion (e.g., the eMBB data) , after a corresponding minimum of required code bits of the eMBB data are received. A second decoding attempt will be made if the self-decoding result of the URLLC data is that the self-decoding of the URLLC data fails. Instead of immediately requesting a retransmission, the terminal device may instead proceed to attempt to jointly decode the URLLC data with the eMBB data (larger code) . After the joint decoding, regardless of whether the eMBB data is decoded successfully or not, the joint decoding can increase a probability that the URLLC data will be successfully decoded. In this example, if the decoding of the URLLC data still fails after the second (joint) decoding attempt, then the terminal device may request a retransmission from the network device. With a retransmission, the terminal device can make at least a third decoding attempt. It should be noted that with the retransmitted data, multiple decoding attempts may further be made, for example, to perform self-decoding from the retransmitted data, perform joint decoding from parts of the retransmitted data, and / or perform joint decoding using both the previously received first data and the retransmitted data.

[0333] In a case that a data portion (e.g., the URLLC data or the eMBB data) obtained by the decoding is not for the terminal device, the terminal device may discard the data portion which is not for the terminal device.

[0334] By enabling the joint coding for the URLLC data and the eMBB data and scheduling the jointly-coded data by the first DCI, a success rate of decoding of the URLLC data and reliability thereof can be improved and a code rate can be reduced, resulting in an improved performance.

[0335] The present disclosure further provides solutions of HARQ ACK / NACK (Acknowledgement / Negative Acknowledgement) feedback for joint coding. In an implementation, the scheduling information of the first data in the first DCI may be further indicative of a feedback manner for the first data.

[0336] In a specific implementation, the scheduling information of the first data may be indicative of skipping feedback of the first data portion and performing feedback on the second data portion by the terminal device. That is, no ACK / NACK is fed back for the URLLC data, and only ACK / NACK is fed back for the eMBB data. In this implementation, the network device may assume that the URLLC data is successfully decoded by self-decoding and joint decoding in the joint codeword.

[0337] In another specific implementation, the scheduling information of the first data may be indicative of performing feedback on both of the first data portion and the second data portion by the terminal device. That is,  ACK / NACK feedback is needed for both the URLLC data and the eMBB data. In this implementation, the scheduling information of the first data may be indicative of respective feedback resource information and respective feedback timing information for the first data portion and the second data portion, or indicative of joint feedback resource information and joint feedback timing information for the first data portion and the second data portion.

[0338] FIG. 17 shows a schematic diagram of an example of HARQ ACK / NACK feedback for joint coding. As shown in FIG. 17, in this example, the URLLC CB and the CB0 of the eMBB data (1TB, e.g., corresponding to CB0-CBN) are jointly encoded, so the URLLC can be decoded faster than the eMBB data. In this example, separate ACK / NACK is fed back for the URLLC data and the eMBB data. The first DCI may indicate two HARQ feedback resources and two HARQ timings, where one HARQ timing and one feedback resource for the URLLC data, another HARQ timing and another feedback resource for the eMBB data. In this way, faster ACK / NACK feedback can be realized for the URLLC data.

[0339] Alternatively, in another example, a joint ACK / NACK feedback may be carried in a HARQ codebook. The first DCI may indicate one feedback resource and one HARQ timing for the joint ACK / NACK feedback.

[0340] FIG. 18 is a schematic flowchart of yet another wireless communication method according to one or more embodiments of the present disclosure, where ACK / NACK feedback is needed for both the first data portion and the second data portion. Based on the embodiments of FIG. 11, the method may further include the following steps.

[0341] S1105, the terminal device sends a first physical uplink control channel (PUCCH) carrying a result of PDSCH processing for the first data portion.

[0342] S1106, the terminal device sends a second PUCCH carrying a result of PDSCH processing for the second data portion.

[0343] The first PUCCH may carry HARQ ACK / NACK information for the first data portion (e.g., the URLLC data) , and the second PUCCH may carry HARQ ACK / NACK information for the second data portion (e.g., the eMBB data) . The first PUCCH and the second PUCCH may be different PUCCHs. It could be understood that the first PUCCH and the second PUCCH may be the same PUCCH, e.g., in the case of the joint ACK / NACK feedback.

[0344] In the present disclosure, PDSCH processing delay is further considered for the joint coding. In the related art, if a first uplink symbol of the PUCCH which carries the HARQ-ACK information, as defined by the assigned HARQ-ACK timing K1 and Koffset, if configured, and the PUCCH resource to be used and including the effect of the timing advance, starts no earlier than at symbol L1, where L1 is defined as the next uplink symbol with  its CP starting after Tproc, 1= (N1+d1, 1+d2) (2048+144) ·κ2-μ·TC+Text after the end of the last symbol of the PDSCH carrying the TB being acknowledged, then the terminal device shall provide a valid HARQ ACK / NACK message. The reference time for the start of PDSCH processing is: the end of the last symbol of the PDSCH carrying the TB being acknowledged. (Reference can be made to 3GPP NR specification TS 38.214 V17.2.0 for definitions of related parameters. )

[0345] For the joint coding, the reference time for the start of PDSCH processing of the first data portion (e.g., the URLLC data) and the second data portion (e.g., the eMBB data) may be different, since the first data portion may be jointly encoded with part of the second data portion (e.g., one CB of the second data portion) into the joint codeword.

[0346] In an implementation, the second data portion of the first data may include an initial part and a remaining part, and the joint coding is enabled for the first data portion and the initial part of the second data portion. For example, the initial part may be CB0 of the eMBB data, and the remaining part may be CB1-CBN of the eMBB data. In an implementation, the sending of the first PUCCH may start not earlier than first processing time (corresponding to Tproc for URLLC) after an end of a time unit of the initial part. The end of the time unit of the initial part may be called reference time for start of PDSCH processing for URLLC. The time unit may be a symbol, for example. Then, the sending of the first PUCCH starts not earlier than at symbol L1 (as in TS 38.214 V17.2.0 except that joint coding is considered) . Since the first data portion is jointly coded with only the initial part of the second data portion, after the end of the time unit of the initial part, self-decoding for the first data portion and joint decoding could be performed. The first processing time may correspond to a first processing capability of the terminal device for processing the first data portion, such as, conducting two decoding attempts for the first data portion as described above. The first processing time (or the first processing capability) may be reported by the terminal device to the network device or may be predefined. Since the time for the two decoding attempts for the first data portion are considered, the terminal can provide valid HARQ ACK / NACK information in the first PUCCH.

[0347] In an implementation, the sending of the second PUCCH may start not earlier than second processing time after an end of a time unit of the remaining part, or, not earlier than third processing time after the end of the time unit of the remaining part. The third processing time may equal to the second processing time plus a time offset, where the time offset may be predefined or configured through an RRC signaling. That is, the second processing time may correspond to Tproc for eMBB. Further, in an example, the end of the time unit of the remaining part may correspond to reference time for start of PDSCH processing for eMBB. In another example, the end of the time unit  of the remaining part plus the time offset may correspond to reference time for start of PDSCH processing for eMBB, so that the sending of the second PUCCH starts not earlier than the third processing time after the end of the time unit of the remaining part. The time unit may also be a symbol, for example. Then, the sending of the second PUCCH starts not earlier than at symbol L1 (as in TS 38.214 V17.2.0 except that joint coding is considered) . After the end of the time unit of the remaining part, decoding for the second data portion could be performed. The second processing time may correspond to a second processing capability of the terminal device for processing the second data portion. The second processing time (or the second processing capability) may be reported by the terminal device to the network device or may be predefined. Since the time for processing the second data portion is considered, the terminal can provide valid HARQ ACK / NACK information in the second PUCCH.

[0348] FIG. 19 shows a schematic diagram of an example of PDSCH processing for joint coding. In this example, the URLLC CB is jointly encoded with part of CBs (as shown FIG. 19, jointly encoded with one CB, namely CB0) into the joint codeword.

[0349] For URLLC PDSCH processing, the reference time for the start of PDSCH processing is the end of the symbol of the CB (i.e., CB0 in this example) which includes URLLC coding information. If the first uplink symbol of the first PUCCH which carries the HARQ-ACK information, and the PUCCH resource to be used and including the effect of the timing advance, starts no earlier than at symbol L1, where L1 is defined as the next uplink symbol with its CP starting after Tproc (i.e., the first processing time) after the reference time, then the terminal device shall provide a valid HARQ ACK / NACK message. Tproc (i.e., the first processing time) is PDSCH processing time, e.g., considering two decoding attempts for the URLLC data.

[0350] For eMBB PDSCH processing, the reference time for the start of PDSCH processing may be the end of the symbol of the PDSCH carrying the TB being acknowledged, e.g., the TB for the eMBB data, or may be the end of the symbol of the PDSCH carrying the TB being acknowledged + an offset (i.e., the above time offset) as shown in FIG. 19, where the offset is predefined or configured by the network device. If the first uplink symbol of the PUCCH which carries the HARQ-ACK information, and the PUCCH resource to be used and including the effect of the timing advance, starts no earlier than at symbol L1, where L1 is defined as the next uplink symbol with its CP starting after Tproc (i.e., the second processing time) after the reference time, then the terminal device shall provide a valid HARQ ACK / NACK message. Tproc is PDSCH processing time.

[0351] By taking joint decoding complexity into account to define the reference time for PDSCH processing for the URLLC data and the eMBB data, accuracy and reliability of the HARQ ACK / NACK feedback can be ensured.

[0352] According to one or more embodiments of the present disclosure, the joint coding may not only be enabled for the first data on the PDSCH, but also be enabled for data to be transmitted on a physical uplink shared channel (PUSCH) .

[0353] FIG. 20 is a schematic flowchart of a wireless communication method for PUSCH transmission according to one or more embodiments of the present disclosure. The method may include the following steps.

[0354] S2001, a terminal device reports a processing capability of joint coding for data to be transmitted on a PUSCH to a network device.

[0355] S2002, the network device determines time for scheduling the PUSCH according to the reported processing capability.

[0356] S2003, the network device sends second DCI to the terminal device, where the second DCI is used for scheduling the PUSCH.

[0357] S2004, the terminal device receives the second DCI from the network device.

[0358] S2005, the terminal device sends the PUSCH to the network device according to the processing capability and the second DCI, where the PUSCH carries the data subject to the joint coding.

[0359] For the technical principle and technical effects of joint coding for the data to be transmitted on the PUSCH, reference may be made to those of joint coding for the first data in the above embodiments, which will not be repeated here. It could be understood that whether joint coding is enabled for the data to be transmitted on the PUSCH may be indicated by the second DCI for scheduling the data or by another DCI, or may be configured through an RRC signaling. In the following, PUSCH processing delay will be discussed and considered for the joint coding for the data to be transmitted on the PUSCH.

[0360] In the related art, as shown in FIG. 21, if a first uplink symbol in PUSCH allocation for a TB, including a DMRS (demodulation reference signal) , as defined by the slot offset K2 and Koffset, if configured, and the start S and length L of the PUSCH allocation indicated by 'Time domain resource assignment' of scheduling DCI and including the effect of the timing advance, is no earlier than at symbol L2, where L2 is defined as the next uplink symbol with its CP starting Tproc, 2=max ( (N2+d2, 1+d2) (2048+144) ·κ2-μ·TC+Text+Tswitch, d2, 2) after the end of the reception of the last symbol of a PDCCH carrying the DCI scheduling the PUSCH, then the terminal device shall transmit the TB. The reference time for the start of PUSCH processing is: the end of the reception of the last symbol of the PDCCH carrying the DCI scheduling the PUSCH. (Reference can be made to 3GPP NR specification TS 38.214 V17.2.0 for definitions of related parameters. )

[0361] As compared to a regular channel coding scheme with no joint coding, the joint coding scheme may be more complex, and processing time of the two may be different.

[0362] In an implementation, the processing capability may include first preparing time (e.g., Tproc-1) for joint coding and second preparing time (e.g., Tproc-0) for non-joint coding. In a case that the joint coding is enabled for the data to be transmitted on the PUSCH, the sending of the PUSCH may start not earlier than the first preparing time after an end of a time unit of the second DCI. The time unit may be a symbol, for example. That is, the sending of the PUSCH starts not earlier than at symbol L2 (as in TS 38.214 V17.2.0 except that joint coding is considered) . The first preparing time may be time for preparing the PUSCH carrying the data which is to be transmitted and is subject to joint coding. In a case that the joint coding is not enabled for the data to be transmitted on the PUSCH, the sending of the PUSCH may start not earlier than the second preparing time after the end of the time unit of the second DCI. The second preparing time may be time for preparing the PUSCH carrying the data which is to be transmitted and is not subject to joint coding. Thus, different preparing time (i.e., different processing time) for PUSCH is considered according to different cases.

[0363] In another implementation, the processing capability may include a first time offset for joint coding and a second time offset for non-joint coding. In a case that the joint coding is enabled for the data to be transmitted on the PUSCH, the sending of the PUSCH may start not earlier than first preparing time after an end of a time unit of the second DCI. The time unit may be a symbol, for example. That is, the sending of the PUSCH starts not earlier than at symbol L2 (as in TS 38.214 V17.2.0 except that joint coding is considered) . The first preparing time may equal to a predefined preparing time (e.g., Tproc) plus the first time offset, so as to provide time for preparing the PUSCH carrying the data which is to be transmitted and is subject to joint coding. In a case that the joint coding is not enabled for the data to be transmitted on the PUSCH, the sending of the PUSCH may start not earlier than second preparing time after the end of the time unit of the second DCI. The second preparing time may equal to the predefined preparing time (e.g., Tproc) plus the second time offset, so as to provide time for preparing the PUSCH carrying the data which is to be transmitted and is not subject to joint coding. In this way, different preparing time (i.e., different processing time) for PUSCH is also considered according to different cases.

[0364] More examples of PUSCH preparation time will be given in the following.

[0365] In an example, the terminal device reports a processing capability for joint coding and non-joint coding. The processing capability may correspond to processing time (Tproc) . Thus, there may be two types of PUSCH processing time, one is Tproc-0 (i.e., the second preparing time) for non-joint coding, and another is Tproc-1 (i.e.,  the first preparing time) for joint coding. Same reference time for the start of PUSCH processing may be predefined or configured for the joint coding and non-joint coding. In a case that the joint coding is enabled, e.g., by the second DCI, if a first uplink symbol in PUSCH allocation for a TB, including a DMRS, and including the effect of the timing advance, is no earlier than at symbol L2, where L2 is defined as the next uplink symbol with its CP starting Tproc-1 after the end of the reception of a last symbol of a PDCCH carrying the second DCI scheduling the PUSCH, then the terminal device shall transmit the TB. In a case that the joint coding is not enabled, e.g., by the second DCI, if the first uplink symbol in the PUSCH allocation for the TB, including the DMRS, and including the effect of the timing advance, is no earlier than at symbol L2, where L2 is defined as the next uplink symbol with its CP starting Tproc-0 after the end of the reception of the last symbol of the PDCCH carrying the second DCI scheduling the PUSCH, then the terminal device shall transmit the TB.

[0366] In another example, one processing capability may be reported or predefined (i.e., the predefined preparing time) , but different PUSCH preparation additional time offsets are considered. In this example, Tproc =Tproc_reference + offset, where Tproc_reference is processing delay for non-joint coding (corresponding to the predefined preparing time) , and offset is separately defined or configured for joint coding and non-joint coding. That is, for non-joint coding, offset = 0. For joint coding, offset = v, where v is configured or predefined or determined according to a capability of the terminal device. If a first uplink symbol in PUSCH allocation for a TB, including a DMRS, and including the effect of the timing advance, is no earlier than at symbol L2, where L2 is defined as the next uplink symbol with its CP starting Tproc_reference + offset after the end of the reception of a last symbol of a PDCCH carrying the second DCI scheduling the PUSCH, then the terminal device shall transmit the TB.

[0367] By taking joint coding complexity into account to define the processing delay for PUSCH processing, accuracy and reliability of the PUSCH transmission can be ensured.

[0368] It should be noted that the above embodiments are described by taking joint coding for two data portions (two kinds of traffic data) as examples, which may also be called mixed traffic coding. However, the above embodiments may also be applied to joint coding for different control information, or joint coding for control information and traffic data.

[0369] With the wireless communication methods provided by the present disclosure, the joint coding can be enabled for the first data on the PDSCH or the data to be transmitted on the PUSCH and the jointly-coded data can be scheduled by the first DCI or the second DCI, a success rate of decoding of the data and reliability thereof can be improved and a code rate can be reduced, resulting in an improved performance. In addition, the HARQ procedure  and related scheduling are provided for scenarios involving the joint coding, accuracy and reliability of the HARQ ACK / NACK feedback can be ensured. Further, by providing solutions for the processing delay for PUSCH processing, accuracy and reliability of the PUSCH transmission can be ensured.

[0370] Next, embodiments of products related to the wireless communication methods will be described.

[0371] FIG. 22 shows a schematic structural diagram of a wireless communication apparatus according to one or more embodiments of the present disclosure. As shown in FIG. 22, the wireless communication apparatus 2200 may include:

[0372] a receiving module 2202, configured to: receive first DCI from a network device, where the first DCI is indicative of whether joint coding is enabled for first data and is indicative of scheduling information of the first data; receive the first data from the network device according to the first DCI;

[0373] a processing module 2204, configured to perform decoding on the received first data according to the first DCI.

[0374] In a possible implementation, in a case that the first DCI is indicative of the joint coding being enabled for the first data, the first data includes a first data portion and a second data portion, and the joint coding is enabled for the first data portion and at least part of the second data portion;

[0375] in a case that the first DCI is indicative of the joint coding being not enabled for the first data, the first data includes one or multiple data portions which are separately coded by the network device.

[0376] In a possible implementation, the scheduling information is indicative of a first HARQ process identity (ID) and first decoding information for the first data portion, and a second HARQ process ID and second decoding information for the second data portion.

[0377] In a possible implementation, the first DCI includes a first HARQ-related field and a second HARQ-related field, and the second HARQ-related field includes M HARQ-related subfields, where a value of M is configured by the network device or is predefined;

[0378] the first HARQ process ID and the first decoding information for the first data portion are carried in the first HARQ-related field;

[0379] in a case that spatial multiplexing is enabled for the second data portion, the second HARQ process ID and decoding information of the second data portion are carried in the M HARQ-related subfields;

[0380] in a case that spatial multiplexing is not enabled for the second data portion, the second HARQ process ID and decoding information of the second data portion are carried in a predefined HARQ-related subfield among  the M HARQ-related subfields.

[0381] In a possible implementation, a HARQ process ID and decoding information of the one or multiple data portions are carried in the first HARQ-related field and / or the second HARQ-related field based on a predefined rule or a radio resource control (RRC) configuration.

[0382] In a possible implementation, the first DCI includes a third HARQ-related field and a fourth HARQ-related field;

[0383] the first HARQ process ID and the first decoding information for the first data portion are carried in the third HARQ-related field;

[0384] the second HARQ process ID and the second decoding information for the second data portion are carried in the fourth HARQ-related field.

[0385] In a possible implementation, a HARQ process ID and decoding information of the one or multiple data portions are carried in the third HARQ-related field and / or the fourth HARQ-related field based on a predefined rule and a spatial multiplexing situation of the first data or based on an RRC configuration and a spatial multiplexing situation of the first data.

[0386] In a possible implementation, the first DCI further includes a joint coding indication field for indicating whether the joint coding is enabled for the first data.

[0387] In a possible implementation, the scheduling information is indicative of a third HARQ process ID for the first data portion and the second data portion, first decoding information for the first data portion and second decoding information for the second data portion.

[0388] In a possible implementation, the first DCI includes a third HARQ process field, a fifth HARQ-related field and a sixth HARQ-related field;

[0389] the third HARQ process ID is carried in the third HARQ process field;

[0390] first decoding information for the first data portion is carried in the fifth HARQ-related field and second decoding information for the second data portion is carried in the sixth HARQ-related field.

[0391] In a possible implementation, decoding information of the one or multiple data portions are carried in the fifth HARQ-related field and / or the sixth HARQ-related field based on a predefined rule or an RRC configuration.

[0392] In a possible implementation, the one or multiple data portions include a third data portion and a fourth data portion;

[0393] both of the third data portion and the fourth data portion use the third HARQ process ID; or,

[0394] the third data portion uses the third HARQ process ID, and the fourth portion uses a fourth HARQ process ID determined based on the third HARQ process ID.

[0395] In a possible implementation, the first DCI further includes a joint coding indication field for indicating whether the joint coding is enabled for the first data.

[0396] In a possible implementation, the joint coding is enabled for the first data portion and the second data portion; the scheduling information of the first data is indicative of a joint HARQ process ID and joint decoding information for the first data.

[0397] In a possible implementation, the first DCI includes a joint HARQ-related field, and the joint HARQ process ID and the joint decoding information for the first data are carried in the joint HARQ-related field.

[0398] In a possible implementation, the scheduling information of the first data is indicative of skipping feedback of the first data portion of the first data and performing feedback on the second data portion of the first data.

[0399] In a possible implementation, the scheduling information of the first data is indicative of performing feedback on both of the first data portion of the first data and the second data portion of the first data.

[0400] In a possible implementation, the scheduling information of the first data is indicative of respective feedback resource information and respective feedback timing information for the first data portion of the first data and the second data portion of the first data; or,

[0401] the scheduling information of the first data is indicative of joint feedback resource information and joint feedback timing information for the first data portion of the first data and the second data portion of the first data.

[0402] In a possible implementation, the processing module 2204 is specifically configured to:

[0403] perform self-decoding on the first data portion according to the first DCI;

[0404] performing joint decoding on the first data according to a self-decoding result of the first data portion and the first DCI.

[0405] In a possible implementation, the receiving module 2202 is specifically configured to receive the first data on a physical downlink shared channel (PDSCH) scheduled by the first DCI;

[0406] the apparatus 2200 further includes a sending module (not shown) , configured to: send a first physical uplink control channel (PUCCH) carrying a result of PDSCH processing for the first data portion; send a second PUCCH carrying a result of PDSCH processing for the second data portion;

[0407] In a possible implementation, the second data portion of the first data includes an initial part and a  remaining part, and the joint coding is enabled for the first data portion and the initial part of the second data portion; where the sending of the first PUCCH starts not earlier than first processing time after an end of a time unit of the initial part, and the sending of the second PUCCH starts not earlier than second processing time after an end of a time unit of the remaining part, or, not earlier than third processing time after the end of the time unit of the remaining part, where the third processing time equals to the second processing time plus a time offset; where the first processing time and / or the second processing time is reported to the network device or is predefined.

[0408] In a possible implementation, the first data portion has a smaller payload size than the second data portion.

[0409] In a possible implementation, the receiving module 2202 is further configured to receive second DCI from the network device, where the second DCI is used for scheduling a physical uplink shared channel (PUSCH) ;

[0410] the sending module is further configured to send the PUSCH to the network device according to a processing capability of joint coding for data to be transmitted on the PUSCH and the second DCI.

[0411] In a possible implementation, before the receiving module 2202 receives the second DCI from the network device, the sending module is further configured to:

[0412] report the processing capability to the network device, to enable the network device to determine time for scheduling the PUSCH.

[0413] In a possible implementation, the processing capability includes first preparing time for joint coding and second preparing time for non-joint coding;

[0414] in a case that the joint coding is enabled for the data to be transmitted on the PUSCH, the sending of the PUSCH starts not earlier than the first preparing time after an end of a time unit of the second DCI;

[0415] in a case that the joint coding is not enabled for the data to be transmitted on the PUSCH, the sending of the PUSCH starts not earlier than the second preparing time after the end of the time unit of the second DCI.

[0416] In a possible implementation, the processing capability includes a first time offset for joint coding and a second time offset for non-joint coding;

[0417] in a case that the joint coding is enabled for the data to be transmitted on the PUSCH, the sending of the PUSCH starts not earlier than first preparing time after an end of a time unit of the second DCI, where the first preparing time equals to a predefined preparing time plus the first time offset;

[0418] in a case that the joint coding is not enabled for the data to be transmitted on the PUSCH, the sending of the PUSCH starts not earlier than second preparing time after the end of the time unit of the second DCI, where the second preparing time equals to the predefined preparing time plus the second time offset.

[0419] The wireless communication apparatus may be applied to the terminal device as described in the above method embodiments or may be the terminal device as described in the above method embodiments. It should be understood by a person skilled in the art that, the relevant description of the above modules in the embodiments of the present disclosure may be understood with reference to the relevant description of the wireless communication method in the embodiments of the present disclosure.

[0420] FIG. 23 shows a schematic structural diagram of another wireless communication apparatus according to one or more embodiments of the present disclosure. As shown in FIG. 23, the wireless communication apparatus 2300 may include:

[0421] a sending module 2302, configured to: send first DCI to a terminal device, where the first DCI is indicative of whether joint coding is enabled for first data and is indicative of scheduling information of the first data; send the first data to the terminal device, to enable the terminal device to perform decoding on the first data according to the first DCI.

[0422] In a possible implementation, the apparatus 2300 further includes a processing module (not shown) , configured to:

[0423] perform joint coding on a first data portion and at least part of a second data portion to generate the first data including the first data portion and the second data portion, where the first DCI is indicative of the joint coding being enabled for the first data; or

[0424] perform coding on one or multiple data portions separately to generate the first data including the one or multiple data portions, where the first DCI is indicative of the joint coding being not enabled for the first data.

[0425] In a possible implementation, the scheduling information is indicative of a first HARQ process identity (ID) and first decoding information for the first data portion, and a second HARQ process ID and second decoding information for the second data portion, where the first HARQ process ID and the second HARQ process ID are different.

[0426] In a possible implementation, the first DCI includes a first HARQ-related field and a second HARQ-related field, and the second HARQ-related field includes M HARQ-related subfields, where a value of M is configured by a network device or is predefined;

[0427] the first HARQ process ID and the first decoding information for the first data portion are carried in the first HARQ-related field;

[0428] in a case that spatial multiplexing is enabled for the second data portion, the second HARQ process ID  and decoding information of the second data portion are carried in the M HARQ-related subfields;

[0429] in a case that spatial multiplexing is not enabled for the second data portion, the second HARQ process ID and decoding information of the second data portion are carried in a predefined HARQ-related subfield among the M HARQ-related subfields.

[0430] In a possible implementation, a HARQ process ID and decoding information of the one or multiple data portions are carried in the first HARQ-related field and / or the second HARQ-related field based on a predefined rule or a radio resource control (RRC) configuration.

[0431] In a possible implementation, the first DCI includes a third HARQ-related field and a fourth HARQ-related field;

[0432] the first HARQ process ID and the first decoding information for the first data portion are carried in the third HARQ-related field;

[0433] the second HARQ process ID and the second decoding information for the second data portion are carried in the fourth HARQ-related field.

[0434] In a possible implementation, a HARQ process ID and decoding information of the one or multiple data portions are carried in the third HARQ-related field and / or the fourth HARQ-related field based on a predefined rule and a spatial multiplexing situation of the first data or based on an RRC configuration and a spatial multiplexing situation of the first data.

[0435] In a possible implementation, the first DCI further includes a joint coding indication field for indicating whether the joint coding is enabled for the first data.

[0436] In a possible implementation, the scheduling information is indicative of a third HARQ process ID for the first data portion and the second data portion, first decoding information for the first data portion and second decoding information for the second data portion.

[0437] In a possible implementation, the first DCI includes a third HARQ process field, a fifth HARQ-related field and a sixth HARQ-related field;

[0438] the third HARQ process ID is carried in the third HARQ process field;

[0439] first decoding information for the first data portion is carried in the fifth HARQ-related field and second decoding information for the second data portion is carried in the sixth HARQ-related field.

[0440] In a possible implementation, decoding information of the one or multiple data portions are carried in the fifth HARQ-related field and / or the sixth HARQ-related field based on a predefined rule or an RRC configuration.

[0441] In a possible implementation, the one or multiple data portions include a third data portion and a fourth data portion;

[0442] the third HARQ process ID is scheduled for both of the third data portion and the fourth data portion; or,

[0443] the third HARQ process ID is scheduled for the third data portion, and a fourth HARQ process ID for the fourth portion is determined based on the third HARQ process ID.

[0444] In a possible implementation, the first DCI further includes a joint coding indication field for indicating whether the joint coding is enabled for the first data.

[0445] In a possible implementation, the processing module is specifically configured to perform joint coding on the first data portion and the second data portion; where the scheduling information of the first data is indicative of a joint HARQ process ID and joint decoding information for the first data.

[0446] In a possible implementation, the first DCI includes a joint HARQ-related field, and the joint HARQ process ID and the joint decoding information for the first data are carried in the joint HARQ-related field.

[0447] In a possible implementation, the scheduling information of the first data is indicative of skipping feedback of the first data portion of the first data and performing feedback on the second data portion of the first data by the terminal device.

[0448] In a possible implementation, the scheduling information of the first data is indicative of performing feedback on both of the first data portion of the first data and the second data portion of the first data by the terminal device.

[0449] In a possible implementation, the scheduling information of the first data is indicative of respective feedback resource information and respective feedback timing information for the first data portion of the first data and the second data portion of the first data; or,

[0450] the scheduling information of the first data is indicative of joint feedback resource information and joint feedback timing information for the first data portion of the first data and the second data portion of the first data.

[0451] In a possible implementation, the first data portion is self-decodable by the terminal device according to the first DCI, and the first data is jointly-decodable by the terminal device according to a self-decoding result of the first data portion and the first DCI.

[0452] In a possible implementation, the second data portion of the first data includes an initial part and a remaining part;

[0453] the processing module is specifically configured to perform joint coding on the first data portion and the  initial part of the second data portion;

[0454] the sending module 2302 is specifically configured to send the first data to the terminal device on a physical downlink shared channel (PDSCH) scheduled by the first DCI.

[0455] In a possible implementation, the apparatus 2300 further includes a receiving module (not shown) , configured to: receive a first physical uplink control channel (PUCCH) which carries a result of PDSCH processing for the first data portion and is sent by the terminal device; receive a second PUCCH which carries a result of PDSCH processing for the second data portion and is sent by the terminal device;

[0456] where sending of the first PUCCH by the terminal device starts not earlier than first processing time after an end of a time unit of the initial part, and sending of the second PUCCH by the terminal device starts not earlier than second processing time after an end of a time unit of the remaining part, or, not earlier than third processing time after the end of the time unit of the remaining part, where the third processing time equals to the second processing time plus a time offset; where the first processing time and / or the second processing time is reported by the terminal device or is predefined.

[0457] In a possible implementation, the first data portion has a smaller payload size than the second data portion.

[0458] In a possible implementation, the sending module 2302 is further configured to send second DCI to the terminal device, where the second DCI is used for scheduling a physical uplink shared channel (PUSCH) ;

[0459] the apparatus 2300 further includes a receiving module (not shown) , configured to receive the PUSCH sent by the terminal device according to a processing capability of joint coding for data to be transmitted on the PUSCH and the second DCI.

[0460] In a possible implementation, before the sending module 2302 sends the second DCI to the terminal device, the receiving module is further configured to receive the processing capability reported by the terminal device; the processing module is further configured to determine time for scheduling the PUSCH according to the reported processing capability.

[0461] In a possible implementation, the processing capability includes first preparing time for joint coding and second preparing time for non-joint coding;

[0462] in a case that the joint coding is enabled for the data to be transmitted on the PUSCH, the sending of the PUSCH by the terminal device starts not earlier than the first preparing time after an end of a time unit of the second DCI;

[0463] in a case that the joint coding is not enabled for the data to be transmitted on the PUSCH, the sending of  the PUSCH by the terminal device starts not earlier than the second preparing time after the end of the time unit of the second DCI.

[0464] In a possible implementation, the processing capability includes a first time offset for joint coding and a second time offset for non-joint coding;

[0465] in a case that the joint coding is enabled for the data to be transmitted on the PUSCH, the sending of the PUSCH by the terminal device starts not earlier than first preparing time after an end of a time unit of the second DCI, where the first preparing time equals to a predefined preparing time plus the first time offset;

[0466] in a case that the joint coding is not enabled for the data to be transmitted on the PUSCH, the sending of the PUSCH by the terminal device starts not earlier than second preparing time after the end of the time unit of the second DCI, where the second preparing time equals to the predefined preparing time plus the second time offset.

[0467] The wireless communication apparatus may be applied to the network device as described in the above method embodiments or may be the network device as described in the above method embodiments. It should be understood by a person skilled in the art that, the relevant description of the above modules in the embodiments of the present disclosure may be understood with reference to the relevant description of the wireless communication method in the embodiments of the present disclosure.

[0468] An embodiment of the present disclosure provides a terminal device including processing circuitry for executing any of the above wireless communication methods. It should be understood that the terminal device can execute the steps performed by the terminal device in the above method embodiments, which will not be repeated here.

[0469] An embodiment of the present disclosure provides a network device including processing circuitry for executing any of the above wireless communication methods. It should be understood that the network device can execute the steps performed by the network device in the above method embodiments, which will not be repeated here.

[0470] An embodiment of the present disclosure provides a wireless communication apparatus which includes a processor and a memory. The memory is storing instructions that cause the processor to perform any of the above wireless communication methods.

[0471] An embodiment of the present disclosure provides a wireless communication system, including a network device and a terminal device. The terminal device is configured to execute the steps executed by the terminal device in any of the above wireless communication methods, and the network device is configured to execute the  steps executed by the network device in any of the above wireless communication methods.

[0472] An embodiment of the present disclosure provides a computer-readable medium storing computer execution instructions which, when executed by a processor, causes the processor to execute any of the above wireless communication methods.

[0473] An embodiment of the present disclosure provides a computer program product including computer execution instructions which, when executed by a processor, causes the processor to execute any of the above wireless communication methods.

[0474] Although the present disclosure describes methods and processes with steps in a certain order, one or more steps of the methods and processes may be omitted or altered as appropriate. One or more steps may take place in an order other than that in which they are described, as appropriate.

[0475] Note that the expression “at least one of A or B” , as used herein, is interchangeable with the expression “A and / or B” . It refers to a list in which you may select A or B or both A and B. Similarly, “at least one of A, B, or C”, as used herein, is interchangeable with “A and / or B and / or C” or “A, B, and / or C” . It refers to a list in which you may select: A or B or C, or both A and B, or both A and C, or both B and C, or all of A, B and C. The same principle applies for longer lists having a same format.

[0476] Although the present disclosure is described, at least in part, in terms of methods, a person of ordinary skill in the art will understand that the present disclosure is also directed to the various components for performing at least some of the aspects and features of the described methods, be it by way of hardware components, software or any combination of the two. Accordingly, the technical solution of the present disclosure may be embodied in the form of a software product. A suitable software product may be stored in a pre-recorded storage device or other similar non-volatile or non-transitory computer readable medium, including DVDs, CD-ROMs, USB flash disk, a removable hard disk, or other storage media, for example. The software product includes instructions tangibly stored thereon that enable a processing device (e.g., a personal computer, a server, or a network device) to execute examples of the methods disclosed herein. The machine-executable instructions may be in the form of code sequences, configuration information, or other data, which, when executed, cause a machine (e.g., a processor or other processing device) to perform steps in a method according to examples of the present disclosure.

[0477] The present disclosure may be embodied in other specific forms without departing from the subject matter of the claims. The described example embodiments are to be considered in all respects as being only illustrative and not restrictive. Selected features from one or more of the above-described embodiments may be  combined to create alternative embodiments not explicitly described, features suitable for such combinations being understood within the scope of this disclosure.

[0478] All values and sub-ranges within disclosed ranges are also disclosed. Also, although the systems, devices and processes disclosed and shown herein may include a specific number of elements / components, the systems, devices and assemblies could be modified to include additional or fewer of such elements / components. For example, although any of the elements / components disclosed may be referenced as being singular, the embodiments disclosed herein could be modified to include a plurality of such elements / components. The subject matter described herein intends to cover and embrace all suitable changes in technology.

[0479] Although embodiments have been described above with reference to the accompanying drawings, those of skill in the art will appreciate that variations and modifications may be made without departing from the scope thereof as defined by the appended claims.

Claims

1.A wireless communication method, comprising:receiving, by a terminal device, first downlink control information (DCI) from a network device, wherein the first DCI is indicative of whether joint coding is enabled for first data and is indicative of scheduling information of the first data;receiving, by the terminal device, the first data from the network device according to the first DCI;performing, by the terminal device, decoding on the received first data according to the first DCI.2.The method according to claim 1, wherein:in a case that the first DCI is indicative of the joint coding being enabled for the first data, the first data comprises a first data portion and a second data portion, and the joint coding is enabled for the first data portion and at least part of the second data portion;in a case that the first DCI is indicative of the joint coding being not enabled for the first data, the first data comprises one or multiple data portions which are separately coded by the network device.3.The method according to claim 2, wherein the scheduling information is indicative of a first HARQ process identity (ID) and first decoding information for the first data portion, and a second HARQ process ID and second decoding information for the second data portion.4.The method according to claim 3, wherein the first DCI comprises a first HARQ-related field and a second HARQ-related field, and the second HARQ-related field comprises M HARQ-related subfields, wherein a value of M is configured by the network device or is predefined;the first HARQ process ID and the first decoding information for the first data portion are carried in the first HARQ-related field;in a case that spatial multiplexing is enabled for the second data portion, the second HARQ process ID and decoding information of the second data portion are carried in the M HARQ-related subfields;in a case that spatial multiplexing is not enabled for the second data portion, the second HARQ process ID and decoding information of the second data portion are carried in a predefined HARQ-related subfield among the M HARQ-related subfields.5.The method according to claim 4, wherein a HARQ process ID and decoding information of the one or multiple data portions are carried in the first HARQ-related field and / or the second HARQ-related field based on a  predefined rule or a radio resource control (RRC) configuration.6.The method according to claim 3, wherein the first DCI comprises a third HARQ-related field and a fourth HARQ-related field;the first HARQ process ID and the first decoding information for the first data portion are carried in the third HARQ-related field;the second HARQ process ID and the second decoding information for the second data portion are carried in the fourth HARQ-related field.7.The method according to claim 6, wherein a HARQ process ID and decoding information of the one or multiple data portions are carried in the third HARQ-related field and / or the fourth HARQ-related field based on a predefined rule and a spatial multiplexing situation of the first data or based on an RRC configuration and a spatial multiplexing situation of the first data.8.The method according to any one of claims 4 to 7, wherein the first DCI further comprises a joint coding indication field for indicating whether the joint coding is enabled for the first data.9.The method according to claim 2, wherein the scheduling information is indicative of a third HARQ process ID for the first data portion and the second data portion, first decoding information for the first data portion and second decoding information for the second data portion.10.The method according to claim 9, wherein the first DCI comprises a third HARQ process field, a fifth HARQ-related field and a sixth HARQ-related field;the third HARQ process ID is carried in the third HARQ process field;first decoding information for the first data portion is carried in the fifth HARQ-related field and second decoding information for the second data portion is carried in the sixth HARQ-related field.11.The method according to claim 10, wherein decoding information of the one or multiple data portions are carried in the fifth HARQ-related field and / or the sixth HARQ-related field based on a predefined rule or an RRC configuration.12.The method according to claim 11, wherein the one or multiple data portions comprise a third data portion and a fourth data portion;both of the third data portion and the fourth data portion use the third HARQ process ID; or,the third data portion uses the third HARQ process ID, and the fourth portion uses a fourth HARQ process ID determined based on the third HARQ process ID.13.The method according to any one of claims 10 to 12, wherein the first DCI further comprises a joint coding indication field for indicating whether the joint coding is enabled for the first data.14.The method according to claim 2, wherein the joint coding is enabled for the first data portion and the second data portion;the scheduling information of the first data is indicative of a joint HARQ process ID and joint decoding information for the first data.15.The method according to claim 14, wherein the first DCI comprises a joint HARQ-related field, and the joint HARQ process ID and the joint decoding information for the first data are carried in the joint HARQ-related field.16.The method according to any one of claims 2 to 15, wherein the scheduling information of the first data is indicative of skipping feedback of the first data portion of the first data and performing feedback on the second data portion of the first data by the terminal device.17.The method according to any one of claims 2 to 15, wherein the scheduling information of the first data is indicative of performing feedback on both of the first data portion of the first data and the second data portion of the first data by the terminal device.18.The method according to claim 17, wherein the scheduling information of the first data is indicative of respective feedback resource information and respective feedback timing information for the first data portion of the first data and the second data portion of the first data; or,the scheduling information of the first data is indicative of joint feedback resource information and joint feedback timing information for the first data portion of the first data and the second data portion of the first data.19.The method according to any one of claims 2 to 18, wherein the performing, by the terminal device, decoding on the received first data according to the first DCI comprises:performing, by the terminal device, self-decoding on the first data portion according to the first DCI;performing, by the terminal device, joint decoding on the first data according to a self-decoding result of the first data portion and the first DCI.20.The method according to any one of claims 2 to 19, wherein the receiving, by the terminal device, the first data from the network device according to the first DCI comprises:receiving, by the terminal device, the first data on a physical downlink shared channel (PDSCH) scheduled by the first DCI;wherein the method further comprises:sending, by the terminal device, a first physical uplink control channel (PUCCH) carrying a result of PDSCH processing for the first data portion;sending, by the terminal device, a second PUCCH carrying a result of PDSCH processing for the second data portion.21.The method according to claim 20, wherein the second data portion of the first data comprises an initial part and a remaining part, and the joint coding is enabled for the first data portion and the initial part of the second data portion;wherein the sending of the first PUCCH starts not earlier than first processing time after an end of a time unit of the initial part, and the sending of the second PUCCH starts not earlier than second processing time after an end of a time unit of the remaining part, or, not earlier than third processing time after the end of the time unit of the remaining part, wherein the third processing time equals to the second processing time plus a time offset; wherein the first processing time and / or the second processing time is reported by the terminal device to the network device or is predefined.22.The method according to any one of claims 2 to 21, wherein the first data portion has a smaller payload size than the second data portion.23.The method according to any one of claims 1 to 22, further comprising:receiving, by the terminal device, second DCI from the network device, wherein the second DCI is used for scheduling a physical uplink shared channel (PUSCH) ;sending, by the terminal device, the PUSCH to the network device according to a processing capability of joint coding for data to be transmitted on the PUSCH and the second DCI.24.The method according to claim 23, before receiving, by the terminal device, the second DCI from the network device, further comprising:reporting, by the terminal device, the processing capability to the network device, to enable the network device to determine time for scheduling the PUSCH.25.The method according to claim 24, wherein the processing capability comprises first preparing time for joint coding and second preparing time for non-joint coding;in a case that the joint coding is enabled for the data to be transmitted on the PUSCH, the sending of the PUSCH starts not earlier than the first preparing time after an end of a time unit of the second DCI;in a case that the joint coding is not enabled for the data to be transmitted on the PUSCH, the sending of the PUSCH starts not earlier than the second preparing time after the end of the time unit of the second DCI.26.The method according to claim 24, wherein the processing capability comprises a first time offset for joint coding and a second time offset for non-joint coding;in a case that the joint coding is enabled for the data to be transmitted on the PUSCH, the sending of the PUSCH starts not earlier than first preparing time after an end of a time unit of the second DCI, wherein the first preparing time equals to a predefined preparing time plus the first time offset;in a case that the joint coding is not enabled for the data to be transmitted on the PUSCH, the sending of the PUSCH starts not earlier than second preparing time after the end of the time unit of the second DCI, wherein the second preparing time equals to the predefined preparing time plus the second time offset.27.A wireless communication method, comprising:sending, by a network device, first downlink control information (DCI) to a terminal device, wherein the first DCI is indicative of whether joint coding is enabled for first data and is indicative of scheduling information of the first data;sending, by the network device, the first data to the terminal device, to enable the terminal device to perform decoding on the first data according to the first DCI.28.The method according to claim 27, further comprising:performing, by the network device, joint coding on a first data portion and at least part of a second data portion to generate the first data comprising the first data portion and the second data portion, wherein the first DCI is indicative of the joint coding being enabled for the first data; orperforming, by the network device, coding on one or multiple data portions separately to generate the first data comprising the one or multiple data portions, wherein the first DCI is indicative of the joint coding being not enabled for the first data.29.The method according to claim 28, wherein the scheduling information is indicative of a first HARQ process identity (ID) and first decoding information for the first data portion, and a second HARQ process ID and second decoding information for the second data portion.30.The method according to claim 29, wherein the first DCI comprises a first HARQ-related field and a second HARQ-related field, and the second HARQ-related field comprises M HARQ-related subfields, wherein a value of M is configured by the network device or is predefined;the first HARQ process ID and the first decoding information for the first data portion are carried in the first HARQ-related field;in a case that spatial multiplexing is enabled for the second data portion, the second HARQ process ID and decoding information of the second data portion are carried in the M HARQ-related subfields;in a case that spatial multiplexing is not enabled for the second data portion, the second HARQ process ID and decoding information of the second data portion are carried in a predefined HARQ-related subfield among the M HARQ-related subfields.31.The method according to claim 30, wherein a HARQ process ID and decoding information of the one or multiple data portions are carried in the first HARQ-related field and / or the second HARQ-related field based on a predefined rule or a radio resource control (RRC) configuration.32.The method according to claim 29, wherein the first DCI comprises a third HARQ-related field and a fourth HARQ-related field;the first HARQ process ID and the first decoding information for the first data portion are carried in the third HARQ-related field;the second HARQ process ID and the second decoding information for the second data portion are carried in the fourth HARQ-related field.33.The method according to claim 32, wherein a HARQ process ID and decoding information of the one or multiple data portions are carried in the third HARQ-related field and / or the fourth HARQ-related field based on a predefined rule and a spatial multiplexing situation of the first data or based on an RRC configuration and a spatial multiplexing situation of the first data.34.The method according to any one of claims 30 to 33, wherein the first DCI further comprises a joint coding indication field for indicating whether the joint coding is enabled for the first data.35.The method according to claim 28, wherein the scheduling information is indicative of a third HARQ process ID for the first data portion and the second data portion, first decoding information for the first data portion and second decoding information for the second data portion.36.The method according to claim 35, wherein the first DCI comprises a third HARQ process field, a fifth HARQ-related field and a sixth HARQ-related field;the third HARQ process ID is carried in the third HARQ process field;first decoding information for the first data portion is carried in the fifth HARQ-related field and second decoding information for the second data portion is carried in the sixth HARQ-related field.37.The method according to claim 36, wherein decoding information of the one or multiple data portions are carried in the fifth HARQ-related field and / or the sixth HARQ-related field based on a predefined rule or an RRC configuration.38.The method according to claim 37, wherein the one or multiple data portions comprise a third data portion and a fourth data portion;the third HARQ process ID is scheduled by the network device for both of the third data portion and the fourth data portion; or,the third HARQ process ID is scheduled by the network device for the third data portion, and a fourth HARQ process ID for the fourth portion is determined based on the third HARQ process ID.39.The method according to any one of claims 36 to 38, wherein the first DCI further comprises a joint coding indication field for indicating whether the joint coding is enabled for the first data.40.The method according to claim 28, wherein the performing, by the network device, joint coding on the first data portion and at least part of the second data portion comprises:performing, by the network device, joint coding on the first data portion and the second data portion;wherein the scheduling information of the first data is indicative of a joint HARQ process ID and joint decoding information for the first data.41.The method according to claim 40, wherein the first DCI comprises a joint HARQ-related field, and the joint HARQ process ID and the joint decoding information for the first data are carried in the joint HARQ-related field.42.The method according to any one of claims 28 to 41, wherein the scheduling information of the first data is indicative of skipping feedback of the first data portion of the first data and performing feedback on the second data portion of the first data by the terminal device.43.The method according to any one of claims 28 to 41, wherein the scheduling information of the first data is indicative of performing feedback on both of the first data portion of the first data and the second data portion of the first data by the terminal device.44.The method according to claim 43, wherein the scheduling information of the first data is indicative of respective feedback resource information and respective feedback timing information for the first data portion of the first data and the second data portion of the first data; or,the scheduling information of the first data is indicative of joint feedback resource information and joint feedback timing information for the first data portion of the first data and the second data portion of the first data.45.The method according to any one of claims 28 to 44, wherein the first data portion is self-decodable by the terminal device according to the first DCI, and the first data is jointly-decodable by the terminal device according to a self-decoding result of the first data portion and the first DCI.46.The method according to any one of claims 28 to 45, wherein the second data portion of the first data comprises an initial part and a remaining part;the performing, by the network device, joint coding on the first data portion and at least part of the second data portion comprises: performing, by the network device, joint coding on the first data portion and the initial part of the second data portion;the sending, by the network device, the first data to the terminal device comprises: sending, by the network device, the first data to the terminal device on a physical downlink shared channel (PDSCH) scheduled by the first DCI.47.The method according to claim 46, further comprising:receiving, by the network device, a first physical uplink control channel (PUCCH) which carries a result of PDSCH processing for the first data portion and is sent by the terminal device;receiving, by the network device, a second PUCCH which carries a result of PDSCH processing for the second data portion and is sent by the terminal device;wherein sending of the first PUCCH by the terminal device starts not earlier than first processing time after an end of a time unit of the initial part, and sending of the second PUCCH by the terminal device starts not earlier than second processing time after an end of a time unit of the remaining part, or, not earlier than third processing time after the end of the time unit of the remaining part, wherein the third processing time equals to the second processing time plus a time offset; wherein the first processing time and / or the second processing time is reported by the terminal device to the network device or is predefined.48.The method according to any one of claims 28 to 47, wherein the first data portion has a smaller payload size than the second data portion.49.The method according to any one of claims 27 to 48, further comprising:sending, by the network device, second DCI to the terminal device, wherein the second DCI is used for scheduling a physical uplink shared channel (PUSCH) ;receiving, by the network device, the PUSCH sent by the terminal device according to a processing capability of joint coding for data to be transmitted on the PUSCH and the second DCI.50.The method according to claim 49, before sending, by the network device, the second DCI to the terminal device, further comprising:receiving, by the network device, the processing capability reported by the terminal device;determining, by the network device, time for scheduling the PUSCH according to the reported processing capability.51.The method according to claim 50, wherein the processing capability comprises first preparing time for joint coding and second preparing time for non-joint coding;in a case that the joint coding is enabled for the data to be transmitted on the PUSCH, the sending of the PUSCH by the terminal device starts not earlier than the first preparing time after an end of a time unit of the second DCI;in a case that the joint coding is not enabled for the data to be transmitted on the PUSCH, the sending of the PUSCH by the terminal device starts not earlier than the second preparing time after the end of the time unit of the second DCI.52.The method according to claim 50, wherein the processing capability comprises a first time offset for joint coding and a second time offset for non-joint coding;in a case that the joint coding is enabled for the data to be transmitted on the PUSCH, the sending of the PUSCH by the terminal device starts not earlier than first preparing time after an end of a time unit of the second DCI, wherein the first preparing time equals to a predefined preparing time plus the first time offset;in a case that the joint coding is not enabled for the data to be transmitted on the PUSCH, the sending of the PUSCH by the terminal device starts not earlier than second preparing time after the end of the time unit of the second DCI, wherein the second preparing time equals to the predefined preparing time plus the second time offset.53.A wireless communication apparatus, comprising:a receiving module, configured to: receive first downlink control information (DCI) from a network device, wherein the first DCI is indicative of whether joint coding is enabled for first data and is indicative of scheduling information of the first data; receive the first data from the network device according to the first DCI;a processing module, configured to perform decoding on the received first data according to the first DCI.54.The apparatus according to claim 53, wherein:in a case that the first DCI is indicative of the joint coding being enabled for the first data, the first data comprises a first data portion and a second data portion, and the joint coding is enabled for the first data portion and at least part of the second data portion;in a case that the first DCI is indicative of the joint coding being not enabled for the first data, the first data comprises one or multiple data portions which are separately coded by the network device.55.The apparatus according to claim 54, wherein the scheduling information is indicative of a first HARQ process identity (ID) and first decoding information for the first data portion, and a second HARQ process ID and second decoding information for the second data portion.56.The apparatus according to claim 55, wherein the first DCI comprises a first HARQ-related field and a second HARQ-related field, and the second HARQ-related field comprises M HARQ-related subfields, wherein a value of M is configured by the network device or is predefined;the first HARQ process ID and the first decoding information for the first data portion are carried in the first HARQ-related field;in a case that spatial multiplexing is enabled for the second data portion, the second HARQ process ID and decoding information of the second data portion are carried in the M HARQ-related subfields;in a case that spatial multiplexing is not enabled for the second data portion, the second HARQ process ID and decoding information of the second data portion are carried in a predefined HARQ-related subfield among the M HARQ-related subfields.57.The apparatus according to claim 56, wherein a HARQ process ID and decoding information of the one or multiple data portions are carried in the first HARQ-related field and / or the second HARQ-related field based on a predefined rule or a radio resource control (RRC) configuration.58.The apparatus according to claim 55, wherein the first DCI comprises a third HARQ-related field and a fourth HARQ-related field;the first HARQ process ID and the first decoding information for the first data portion are carried in the third HARQ-related field;the second HARQ process ID and the second decoding information for the second data portion are carried in the fourth HARQ-related field.59.The apparatus according to claim 58, wherein a HARQ process ID and decoding information of the one or multiple data portions are carried in the third HARQ-related field and / or the fourth HARQ-related field based on a predefined rule and a spatial multiplexing situation of the first data or based on an RRC configuration and a spatial  multiplexing situation of the first data.60.The apparatus according to any one of claims 56 to 59, wherein the first DCI further comprises a joint coding indication field for indicating whether the joint coding is enabled for the first data.61.The apparatus according to claim 54, wherein the scheduling information is indicative of a third HARQ process ID for the first data portion and the second data portion, first decoding information for the first data portion and second decoding information for the second data portion.62.The apparatus according to claim 61, wherein the first DCI comprises a third HARQ process field, a fifth HARQ-related field and a sixth HARQ-related field;the third HARQ process ID is carried in the third HARQ process field;first decoding information for the first data portion is carried in the fifth HARQ-related field and second decoding information for the second data portion is carried in the sixth HARQ-related field.63.The apparatus according to claim 62, wherein decoding information of the one or multiple data portions are carried in the fifth HARQ-related field and / or the sixth HARQ-related field based on a predefined rule or an RRC configuration.64.The apparatus according to claim 63, wherein the one or multiple data portions comprise a third data portion and a fourth data portion;both of the third data portion and the fourth data portion use the third HARQ process ID; or,the third data portion uses the third HARQ process ID, and the fourth portion uses a fourth HARQ process ID determined based on the third HARQ process ID.65.The apparatus according to any one of claims 62 to 64, wherein the first DCI further comprises a joint coding indication field for indicating whether the joint coding is enabled for the first data.66.The apparatus according to claim 54, wherein the joint coding is enabled for the first data portion and the second data portion;the scheduling information of the first data is indicative of a joint HARQ process ID and joint decoding information for the first data.67.The apparatus according to claim 66, wherein the first DCI comprises a joint HARQ-related field, and the joint HARQ process ID and the joint decoding information for the first data are carried in the joint HARQ-related field.68.The apparatus according to any one of claims 54 to 67, wherein the scheduling information of the first data  is indicative of skipping feedback of the first data portion of the first data and performing feedback on the second data portion of the first data.69.The apparatus according to any one of claims 54 to 67, wherein the scheduling information of the first data is indicative of performing feedback on both of the first data portion of the first data and the second data portion of the first data.70.The apparatus according to claim 69, wherein the scheduling information of the first data is indicative of respective feedback resource information and respective feedback timing information for the first data portion of the first data and the second data portion of the first data; or,the scheduling information of the first data is indicative of joint feedback resource information and joint feedback timing information for the first data portion of the first data and the second data portion of the first data.71.The apparatus according to any one of claims 54 to 70, wherein the processing module is specifically configured to:perform self-decoding on the first data portion according to the first DCI;performing joint decoding on the first data according to a self-decoding result of the first data portion and the first DCI.72.The apparatus according to any one of claims 54 to 71, wherein the receiving module is specifically configured to:receive the first data on a physical downlink shared channel (PDSCH) scheduled by the first DCI;wherein the apparatus further comprises:a sending module, configured to: send a first physical uplink control channel (PUCCH) carrying a result of PDSCH processing for the first data portion; send a second PUCCH carrying a result of PDSCH processing for the second data portion.73.The apparatus according to claim 72, wherein the second data portion of the first data comprises an initial part and a remaining part, and the joint coding is enabled for the first data portion and the initial part of the second data portion;wherein the sending of the first PUCCH starts not earlier than first processing time after an end of a time unit of the initial part, and the sending of the second PUCCH starts not earlier than second processing time after an end of a time unit of the remaining part, or, not earlier than third processing time after the end of the time unit of the remaining part, wherein the third processing time equals to the second processing time plus a time offset; wherein the first processing time and / or the second processing time is reported to the network device or is predefined.74.The apparatus according to any one of claims 54 to 73, wherein the first data portion has a smaller payload size than the second data portion.75.The apparatus according to any one of claims 53 to 74, wherein the receiving module is further configured to receive second DCI from the network device, wherein the second DCI is used for scheduling a physical uplink shared channel (PUSCH) ;the sending module is further configured to send the PUSCH to the network device according to a processing capability of joint coding for data to be transmitted on the PUSCH and the second DCI.76.The apparatus according to claim 75, wherein before the receiving module receives the second DCI from the network device, the sending module is further configured to:report the processing capability to the network device, to enable the network device to determine time for scheduling the PUSCH.77.The apparatus according to claim 76, wherein the processing capability comprises first preparing time for joint coding and second preparing time for non-joint coding;in a case that the joint coding is enabled for the data to be transmitted on the PUSCH, the sending of the PUSCH starts not earlier than the first preparing time after an end of a time unit of the second DCI;in a case that the joint coding is not enabled for the data to be transmitted on the PUSCH, the sending of the PUSCH starts not earlier than the second preparing time after the end of the time unit of the second DCI.78.The apparatus according to claim 76, wherein the processing capability comprises a first time offset for joint coding and a second time offset for non-joint coding;in a case that the joint coding is enabled for the data to be transmitted on the PUSCH, the sending of the PUSCH starts not earlier than first preparing time after an end of a time unit of the second DCI, wherein the first preparing time equals to a predefined preparing time plus the first time offset;in a case that the joint coding is not enabled for the data to be transmitted on the PUSCH, the sending of the PUSCH starts not earlier than second preparing time after the end of the time unit of the second DCI, wherein the second preparing time equals to the predefined preparing time plus the second time offset.79.A wireless communication apparatus, comprising:a sending module, configured to: send first downlink control information (DCI) to a terminal device, wherein the first DCI is indicative of whether joint coding is enabled for first data and is indicative of scheduling information of the first data; send the first data to the terminal device, to enable the terminal device to perform decoding on the first data according to the first DCI.80.The apparatus according to claim 79, further comprising a processing module, configured to:perform joint coding on a first data portion and at least part of a second data portion to generate the first data comprising the first data portion and the second data portion, wherein the first DCI is indicative of the joint coding being enabled for the first data; orperform coding on one or multiple data portions separately to generate the first data comprising the one or multiple data portions, wherein the first DCI is indicative of the joint coding being not enabled for the first data.81.The apparatus according to claim 80, wherein the scheduling information is indicative of a first HARQ process identity (ID) and first decoding information for the first data portion, and a second HARQ process ID and second decoding information for the second data portion.82.The apparatus according to claim 81, wherein the first DCI comprises a first HARQ-related field and a second HARQ-related field, and the second HARQ-related field comprises M HARQ-related subfields, wherein a value of M is configured by a network device or is predefined;the first HARQ process ID and the first decoding information for the first data portion are carried in the first HARQ-related field;in a case that spatial multiplexing is enabled for the second data portion, the second HARQ process ID and decoding information of the second data portion are carried in the M HARQ-related subfields;in a case that spatial multiplexing is not enabled for the second data portion, the second HARQ process ID and decoding information of the second data portion are carried in a predefined HARQ-related subfield among the M HARQ-related subfields.83.The apparatus according to claim 82, wherein a HARQ process ID and decoding information of the one or multiple data portions are carried in the first HARQ-related field and / or the second HARQ-related field based on a predefined rule or a radio resource control (RRC) configuration.84.The apparatus according to claim 81, wherein the first DCI comprises a third HARQ-related field and a fourth HARQ-related field;the first HARQ process ID and the first decoding information for the first data portion are carried in the third HARQ-related field;the second HARQ process ID and the second decoding information for the second data portion are carried in the fourth HARQ-related field.85.The apparatus according to claim 84, wherein a HARQ process ID and decoding information of the one or multiple data portions are carried in the third HARQ-related field and / or the fourth HARQ-related field based on a predefined rule and a spatial multiplexing situation of the first data or based on an RRC configuration and a spatial multiplexing situation of the first data.86.The apparatus according to any one of claims 82 to 85, wherein the first DCI further comprises a joint coding indication field for indicating whether the joint coding is enabled for the first data.87.The apparatus according to claim 80, wherein the scheduling information is indicative of a third HARQ process ID for the first data portion and the second data portion, first decoding information for the first data portion and second decoding information for the second data portion.88.The apparatus according to claim 87, wherein the first DCI comprises a third HARQ process field, a fifth HARQ-related field and a sixth HARQ-related field;the third HARQ process ID is carried in the third HARQ process field;first decoding information for the first data portion is carried in the fifth HARQ-related field and second decoding information for the second data portion is carried in the sixth HARQ-related field.89.The apparatus according to claim 88, wherein decoding information of the one or multiple data portions are carried in the fifth HARQ-related field and / or the sixth HARQ-related field based on a predefined rule or an RRC configuration.90.The apparatus according to claim 89, wherein the one or multiple data portions comprise a third data portion and a fourth data portion;the third HARQ process ID is scheduled for both of the third data portion and the fourth data portion; or,the third HARQ process ID is scheduled for the third data portion, and a fourth HARQ process ID for the fourth portion is determined based on the third HARQ process ID.91.The apparatus according to any one of claims 88 to 90, wherein the first DCI further comprises a joint coding indication field for indicating whether the joint coding is enabled for the first data.92.The apparatus according to claim 80, wherein the processing module is specifically configured to:perform joint coding on the first data portion and the second data portion;wherein the scheduling information of the first data is indicative of a joint HARQ process ID and joint decoding information for the first data.93.The apparatus according to claim 92, wherein the first DCI comprises a joint HARQ-related field, and the joint HARQ process ID and the joint decoding information for the first data are carried in the joint HARQ-related field.94.The apparatus according to any one of claims 80 to 93, wherein the scheduling information of the first data is indicative of skipping feedback of the first data portion of the first data and performing feedback on the second data portion of the first data by the terminal device.95.The apparatus according to any one of claims 80 to 93, wherein the scheduling information of the first data is indicative of performing feedback on both of the first data portion of the first data and the second data portion of the first data by the terminal device.96.The apparatus according to claim 95, wherein the scheduling information of the first data is indicative of respective feedback resource information and respective feedback timing information for the first data portion of the first data and the second data portion of the first data; or,the scheduling information of the first data is indicative of joint feedback resource information and joint feedback timing information for the first data portion of the first data and the second data portion of the first data.97.The apparatus according to any one of claims 80 to 96, wherein the first data portion is self-decodable by the terminal device according to the first DCI, and the first data is jointly-decodable by the terminal device according to a self-decoding result of the first data portion and the first DCI.98.The apparatus according to any one of claims 80 to 97, wherein the second data portion of the first data comprises an initial part and a remaining part;the processing module is specifically configured to perform joint coding on the first data portion and the initial part of the second data portion;the sending module is specifically configured to send the first data to the terminal device on a physical downlink shared channel (PDSCH) scheduled by the first DCI.99.The apparatus according to claim 98, further comprising a receiving module, configured to:receive a first physical uplink control channel (PUCCH) which carries a result of PDSCH processing for the first data portion and is sent by the terminal device;receive a second PUCCH which carries a result of PDSCH processing for the second data portion and is sent by the terminal device;wherein sending of the first PUCCH by the terminal device starts not earlier than first processing time after an end of a time unit of the initial part, and sending of the second PUCCH by the terminal device starts not earlier than second processing time after an end of a time unit of the remaining part, or, not earlier than third processing time after the end of the time unit of the remaining part, wherein the third processing time equals to the second processing time plus a time offset; wherein the first processing time and / or the second processing time is reported by the terminal device or is predefined.100.The apparatus according to any one of claims 80 to 99, wherein the first data portion has a smaller payload size than the second data portion.101.The apparatus according to any one of claims 79 to 100, wherein the sending module is further configured to send second DCI to the terminal device, wherein the second DCI is used for scheduling a physical uplink shared channel (PUSCH) ;the apparatus further comprises a receiving module, configured to receive the PUSCH sent by the terminal device according to a processing capability of joint coding for data to be transmitted on the PUSCH and the second DCI.102.The apparatus according to claim 101, wherein before the sending module sends the second DCI to the terminal device:the receiving module is further configured to receive the processing capability reported by the terminal device;the processing module is further configured to determine time for scheduling the PUSCH according to the reported processing capability.103.The apparatus according to claim 102, wherein the processing capability comprises first preparing time for joint coding and second preparing time for non-joint coding;in a case that the joint coding is enabled for the data to be transmitted on the PUSCH, the sending of the PUSCH by the terminal device starts not earlier than the first preparing time after an end of a time unit of the second DCI;in a case that the joint coding is not enabled for the data to be transmitted on the PUSCH, the sending of the PUSCH by the terminal device starts not earlier than the second preparing time after the end of the time unit of the second DCI.104.The apparatus according to claim 102, wherein the processing capability comprises a first time offset for joint coding and a second time offset for non-joint coding;in a case that the joint coding is enabled for the data to be transmitted on the PUSCH, the sending of the PUSCH by the terminal device starts not earlier than first preparing time after an end of a time unit of the second DCI, wherein the first preparing time equals to a predefined preparing time plus the first time offset;in a case that the joint coding is not enabled for the data to be transmitted on the PUSCH, the sending of the PUSCH by the terminal device starts not earlier than second preparing time after the end of the time unit of the second DCI, wherein the second preparing time equals to the predefined preparing time plus the second time offset.105.A terminal device, comprising processing circuitry for executing the method according to any one of claims 1 to 26.106.A network device, comprising processing circuitry for executing the method according to any one of claims 27 to 52.107.A wireless communication system, comprising the terminal device according to claim 105 and the network device according to claim 106.108.A computer-readable medium storing computer execution instructions which, when executed by a processor, causes the processor to execute the method according to any one according to claims 1 to 26 or the method according to any one according to claims 27 to 52.109.A computer program product comprising computer execution instructions which, when executed by a processor, causes the processor to execute the method according to any one according to claims 1 to 26 or the method according to any one according to claims 27 to 52.

Images