Wireless communication methods and related products

Abstract

A wireless communication method and related products are provided. The method includes the step of a first terminal device receiving a first instruction from a network device, wherein the first instruction indicates joint coding on a first resource. In the wireless communication method and related products of this disclosure, joint coding is enabled on the first resource, so that the reliability of data transmitted on the first resource can be improved.

Description

Technical Field

[0001] Cross - reference to related applications This application claims the priority of U.S. Provisional Patent Application No. 63 / 505,551, titled "INTER - UE MIXED TRAFFIC COOPERATION", filed on June 01, 2023, the entire content of which is incorporated herein by reference.

[0002] Technical Field This disclosure generally relates to the field of communication technologies, and more particularly, to wireless communication methods and related products.

Background Art

[0003] Resilience is a fundamental feature that needs to be addressed in 6th generation (6G) mobile communication technology. Two trends are observed towards 6G. From a technical perspective, millimeter waves and massive multiple - input multiple - output (MIMO) will be more prevalent as they can significantly expand the current bandwidth resources. From a service perspective, a single device will need to support multiple services with different latency and reliability requirements.

[0004] As multiple services converge on one physical wireless link, potential scenarios emerge. The goal is to provide multiple quality - of - service (QoS) for multiple services within one wireless link. Given high carrier frequencies and large - scale antennas, beamforming can be performed more aggressively, enabling the convergence of multiple services in one wireless link. On the other hand, these services may have very diverse key performance indicators (KPIs). This is difficult because different KPIs have to be supported under the same wireless channel.

[0005] This background information is provided to clarify information that the applicant considers potentially relevant to this disclosure. It is not necessarily intended, nor should it be interpreted, that any of the aforementioned pieces of information constitutes prior art to this disclosure. [Overview of the Initiative] [Means for solving the problem]

[0006] In the first aspect, certain embodiments of the present disclosure provide a wireless communication method, the method: The first step of a first terminal device receiving a first instruction from a network device, the first instruction indicating joint coding on a first resource.

[0007] Since joint coding is enabled on the first resource, the reliability of data transmitted on the first resource may be improved.

[0008] In a possible implementation of the first aspect, the joint coding on the first resource is joint coding for the first data for the first terminal device and for the second data for the second terminal device.

[0009] By enabling joint coding between different terminal devices, not only can the latency and reliability requirements for the second data for the second terminal device be improved, but the performance of the first terminal device can also be guaranteed.

[0010] In a possible implementation of the first aspect, first data from a first terminal device and second data from a second terminal device are congruently coded into a first codeword, the first codeword comprising a plurality of encoded blocks generated by encoding the first data and the second data with error-correcting codes, the plurality of encoded blocks comprising a self-decodeable encoded block corresponding to the second data, the self-decodeable encoded block being decodeable independently of the other encoded blocks of the plurality of encoded blocks of the first codeword, and the self-decodeable encoded block being further decodeable congruently with one or more of the other encoded blocks of the plurality of encoded blocks of the first codeword.

[0011] Multiple decoding attempts are allowed, thus improving the success rate and reliability of decoding the first and second data, reducing the code rate, and resulting in improved performance.

[0012] In a possible implementation of the first aspect, the first instruction is carried in first downlink control information (DCI), the first DCI indicating at least one of the coding rate of the first data, the coding rate of the second data, resource information of the second data, and the code block index of the first data.

[0013] In a possible implementation of the first aspect, the first DCI identifies the first resource in a reference resource area by at least one of the following: an M × N time-frequency bitmap corresponding to the reference resource area (where M and N are integers greater than 0), an index in a resource allocation table corresponding to the reference resource area, or the resource location of the first resource in the reference resource area, the reference resource area being configured or predefined through radio resource control (RRC) signaling.

[0014] The instructions for the first resource used for collaborative coding can be flexible.

[0015] In one possible implementation of the first aspect, a first Radio Network Temporary Identifier (RNTI) is used to scramble the Physical Downlink Shared Channel (PDSCH) for the first and second data.

[0016] In a possible implementation of the first aspect, the first RNTI is different from the Cell Radio Network Temporary Identifier (C-RNTI) of the first terminal device, and the first RNTI is different from the C-RNTI of the second terminal device.

[0017] The first RNTI (i.e., mixed RNTI) is proposed to support joint coding between different terminal devices in order to distinguish it from other types of joint coding and to have better compatibility with other types of joint coding.

[0018] In one possible implementation of the first aspect, the method further includes the step of receiving a second DCI from a network device by a first terminal device, the second DCI being used to schedule third data, the third data including the first data.

[0019] In a possible implementation of the first aspect, after the first terminal device receives the first instruction from the network device, the method further includes: determining by the first terminal device that a second resource scheduled by the second DCI for the third data overlaps with at least a portion of the first resource; and determining by the first terminal device that data scheduled by the second DCI on the second resource is not transmitted by the network device.

[0020] By enabling joint coding between different terminal devices and providing a special DCI (i.e., the first DCI that carries the first instruction) in the preemption solution, not only can the latency and reliability requirements of the second data for the second terminal device be improved, but also the performance of the first terminal device can be guaranteed.

[0021] In a possible implementation of the first aspect, the method further includes a step of the first terminal device transmitting a first physical uplink control channel (PUCCH) that carries the result of PDSCH processing for the third data to the network device.

[0022] In a possible implementation of the first aspect, the transmission of the first PUCCH does not start earlier than the first processing time after the end of the time unit of the physical downlink control channel (PDCCH) that carries the first DCI, or does not start earlier than the second processing time after the end of the time unit of the PDCCH that carries the first DCI, and the second processing time is equal to the first processing time plus a time offset.

[0023] In a possible implementation of the first aspect, the transmission of the first PUCCH does not start earlier than the third processing time after the end of the time unit of the PDSCH scheduled by the second DCI.

[0024] The PDSCH processing delay is considered for joint coding between different terminal devices, thus the accuracy and reliability of HARQ ACK / NACK feedback can be guaranteed.

[0025] In the second aspect, an embodiment of the present disclosure provides a wireless communication method, and the method includes: A step of the network device transmitting a first instruction to the first terminal device, where the first instruction indicates joint coding on the first resource.

[0026] Since the joint coding is enabled on the first resource, the reliability of the data transmitted on the first resource can be improved.

[0027] In a possible implementation of the second aspect, the joint coding on the first resource is joint coding for the first data for the first terminal device and the second data for the second terminal device.

[0028] By enabling joint coding between different terminal devices, not only can the latency and reliability requirements of the second data for the second terminal device be improved, but the performance of the first terminal device can also be guaranteed.

[0029] In a possible implementation of the second aspect, the first data of the first terminal device and the second data of the second terminal device are jointly coded into a first coded word, and the first coded word includes a plurality of encoded blocks generated by encoding the first data and the second data with error-correcting codes. The plurality of encoded blocks include self-decodable encoded blocks corresponding to the second data. The self-decodable encoded blocks are decodable independently of other encoded blocks among the plurality of encoded blocks of the first coded word, and the self-decodable encoded blocks are further decodable in agreement with one or more of the other encoded blocks among the plurality of encoded blocks of the first coded word.

[0030] Multiple decoding attempts are allowed, thus the success rate and reliability of decoding the first data and the second data can be improved, the coding rate can be reduced, resulting in improved performance.

[0031] In a possible implementation of the second aspect, the first instruction is carried in first downlink control information (DCI), the first DCI indicating at least one of the coding rate of the first data, the coding rate of the second data, resource information of the second data, and the code block index of the first data.

[0032] In a possible implementation of the second aspect, the first DCI identifies the first resource in a reference resource area by at least one of the following: an M × N time-frequency bitmap corresponding to the reference resource area (where M and N are integers greater than 0), an index in a resource allocation table corresponding to the reference resource area, or a resource location of the first resource in the reference resource area, the reference resource area being configured or predefined through radio resource control (RRC) signaling.

[0033] The instructions for the first resource used for collaborative coding can be flexible.

[0034] In a possible implementation of the second aspect, the first Radio Network Temporary Identifier (RNTI) is used to scramble the Physical Downlink Shared Channel (PDSCH) for the first and second data.

[0035] In a possible implementation of the second aspect, the first RNTI is different from the Cell Radio Network Temporary Identifier (C-RNTI) of the first terminal device, and the first RNTI is different from the C-RNTI of the second terminal device.

[0036] The first RNTI (i.e., mixed RNTI) is proposed to support joint coding between different terminal devices in order to distinguish it from other types of joint coding and to have better compatibility with other types of joint coding.

[0037] In a possible implementation of the second aspect, the method further includes the step of having a first terminal device transmit a first physical uplink control channel (PUCCH) to a network device that carries the results of PDSCH processing for third data.

[0038] In a possible implementation of the second aspect, the transmission of the first PUCCH does not begin earlier than the first processing time after the end of the time unit of the physical downlink control channel (PDCCH) carrying the first DCI, or earlier than the second processing time after the end of the time unit of the PDCCH carrying the first DCI, where the second processing time is equal to the first processing time plus a time offset.

[0039] In a possible implementation of the second aspect, the transmission of the first PUCCH does not begin before the third processing time, after the end of the time unit of the PDSCH scheduled by the second DCI.

[0040] PDSCH processing delays are taken into account for joint coding between different terminal devices, thus ensuring the accuracy and reliability of HARQ ACK / NACK feedback.

[0041] In a third aspect, one embodiment of the present invention provides a wireless communication method, the method being: The steps include: a second terminal device receiving a third DCI from a network device, wherein the third DCI represents a joint coding on a first resource.

[0042] Since joint coding is enabled on the first resource, the reliability of data transmitted on the first resource may be improved.

[0043] In a possible implementation of the third aspect, the joint coding on the first resource is the joint coding for the first data for the first terminal device and the second data for the second terminal device.

[0044] By enabling joint coding between different terminal devices, not only can the latency and reliability requirements for the second data for the second terminal device be improved, but the performance of the first terminal device can also be guaranteed.

[0045] In a possible implementation of the third aspect, first data from a first terminal device and second data from a second terminal device are congruently coded into a first codeword, the first codeword comprising a plurality of encoded blocks generated by encoding the first data and the second data with error-correcting codes, the plurality of encoded blocks comprising a self-decodeable encoded block corresponding to the second data, the self-decodeable encoded block being decodeable independently of the other encoded blocks of the plurality of encoded blocks of the first codeword, and the self-decodeable encoded block being further decodeable congruently with one or more of the other encoded blocks of the plurality of encoded blocks of the first codeword.

[0046] Multiple decoding attempts are allowed, thus improving the success rate and reliability of decoding the first and second data, reducing the code rate, and resulting in improved performance.

[0047] In a possible implementation of the third aspect, the third DCI represents at least one of the following: the coding rate of the first data, the coding rate of the second data, resource information of the second data, and the code block index of the first data.

[0048] In a possible implementation of the third aspect, feedback to the second data is performed by the second terminal device based on HARQ-related information contained in the third DCI, the HARQ-related information including feedback resource information and feedback timing information for the second data.

[0049] In a possible implementation of the third aspect, the first Radio Network Temporary Identifier (RNTI) is used to scramble the Physical Downlink Shared Channel (PDSCH) for the first and second data.

[0050] In a possible implementation of the third aspect, the first RNTI is different from the Cell Radio Network Temporary Identifier (C-RNTI) of the first terminal device, and the first RNTI is different from the C-RNTI of the second terminal device.

[0051] In a possible implementation of the third aspect, the first RNTI is represented by the third DCI or constituted through RRC signaling.

[0052] The first RNTI (i.e., mixed RNTI) is proposed to support joint coding between different terminal devices in order to distinguish it from other types of joint coding and to have better compatibility with other types of joint coding.

[0053] In a possible implementation of the third aspect, the third DCI indicates whether joint coding is enabled for the second data.

[0054] In a possible implementation of the third aspect, the third DCI further indicates whether the first data is for a first terminal device; or whether the first data is for a first terminal device is determined through RRC signaling.

[0055] In a possible implementation of the third aspect, the method further includes the step of discarding the first data for the first terminal device by the second terminal device.

[0056] In a fourth aspect, certain embodiments of the present disclosure provide a wireless communication device, the device comprising various modules configured to perform a wireless communication method by a possible implementation of either the first aspect or one of the first aspects.

[0057] In a fifth aspect, certain embodiments of the present disclosure provide a wireless communication device, which includes various modules configured to perform a wireless communication method by a possible implementation of either the second aspect or one of the second aspects.

[0058] In a sixth aspect, certain embodiments of the present disclosure provide a wireless communication device, which includes various modules configured to perform a wireless communication method by a possible implementation of either a third aspect or one of the third aspects.

[0059] In a seventh aspect, one embodiment of the present disclosure provides a first terminal device including processing circuitry for performing a wireless communication method by a possible implementation of either the first aspect or one of the first aspects.

[0060] In the eighth aspect, one embodiment of the present disclosure provides a network device including processing circuitry for performing a wireless communication method by a possible implementation of the second aspect or either one of the second aspects.

[0061] In a ninth aspect, one embodiment of the present disclosure provides a second terminal device including processing circuitry for performing a wireless communication method by a possible implementation of either a third aspect or one of the third aspects.

[0062] In a tenth aspect, one embodiment of the present disclosure provides a wireless communication system including a first terminal device according to a seventh aspect, a second terminal device according to a ninth aspect, and a network device according to an eighth aspect.

[0063] In the eleventh aspect, embodiments of the present disclosure provide a computer-readable medium storing computer execution instructions, which, when executed by a processor, cause the processor to execute a wireless communication method described in the first aspect or a possible implementation of either the first aspect, or the second aspect or a possible implementation of either the second aspect, or the third aspect or a possible implementation of either the third aspect.

[0064] In the twelfth aspect, one embodiment of the present disclosure provides a computer program product including a computer execution instruction, which, when executed by a processor, causes the processor to execute a wireless communication method described in the first aspect or a possible implementation of either the first aspect, or the second aspect or a possible implementation of either the second aspect, or the third aspect or a possible implementation of either the third aspect.

[0065] This disclosure provides a wireless communication method and related products. A first terminal device receives a first instruction from a network device, the first instruction indicating joint coding on a first resource. Since joint coding is enabled on the first resource, the reliability of data transmitted on the first resource can be improved. Furthermore, first data for the first terminal device and second data for the second terminal device can be jointly coded on the first resource. After receiving the first instruction, the first terminal device can determine that the resource initially scheduled for the first terminal device is to be used for joint coding of the first data for the first terminal device and the second data for the second terminal device. In this way, not only can the latency and reliability requirements of the second data for the second terminal device be improved, but the performance of the first terminal device can also be guaranteed. [Brief explanation of the drawing]

[0066] Herein, the accompanying drawings illustrating exemplary embodiments of the present disclosure are referenced as an example.

[0067] [Figure 1] This is a simplified schematic diagram of a communication system according to one or more embodiments of the present disclosure.

[0068] [Figure 2] This is a schematic diagram illustrating an exemplary communication system according to one or more embodiments of the present disclosure.

[0069] [Figure 3] This is a schematic diagram of the basic component structure of a communication system according to one or more embodiments of the present disclosure.

[0070] [Figure 4] This document shows a block diagram of a device in a communication system according to one or more embodiments of this disclosure.

[0071] [Figure 5] This is a schematic diagram of a 6G multi-service scenario according to one or more embodiments of the present disclosure.

[0072] [Figure 6] 6a and 6b are schematic diagrams of self-decoding and joint decoding according to one or more embodiments of the present disclosure.

[0073] [Figure 7] This is a schematic diagram of joint coding according to one or more embodiments of the present disclosure.

[0074] [Figure 8] This is another schematic diagram of joint coding according to one or more embodiments of the present disclosure.

[0075] [Figure 9] Figures 9a and 9b are schematic diagrams of an example of a preemption solution.

[0076] [Figure 10]This is a schematic flowchart of a wireless communication method according to one or more embodiments of the present disclosure.

[0077] [Figure 11] This is a schematic flowchart of another wireless communication method according to one or more embodiments of the present disclosure.

[0078] [Figure 12] This is a schematic flowchart of yet another wireless communication method according to one or more embodiments of the present disclosure.

[0079] [Figure 13] This is a schematic diagram of an example of joint coding between different terminal devices according to one or more embodiments of the present disclosure.

[0080] [Figure 14] This is a schematic diagram of another example of joint coding between different terminal devices according to one or more embodiments of the present disclosure.

[0081] [Figure 15] This is a schematic diagram of an example of a reference resource area according to one or more embodiments of the present disclosure.

[0082] [Figure 16] This is a schematic diagram of an example of buffer management according to one or more embodiments of the present disclosure.

[0083] [Figure 17] This is a schematic flowchart of yet another wireless communication method according to one or more embodiments of the present disclosure.

[0084] [Figure 18] Figures 18a and 18b are schematic diagrams of examples of PDSCH processing for joint coding according to one or more embodiments of the present disclosure.

[0085] [Figure 19]This is a schematic flowchart of yet another wireless communication method according to one or more embodiments of the present disclosure.

[0086] [Figure 20] This is a schematic diagram of a wireless communication device according to one or more embodiments of the present disclosure.

[0087] [Figure 21] This is a schematic diagram of another wireless communication device according to one or more embodiments of the present disclosure. [Modes for carrying out the invention]

[0088] The following description refers to the accompanying drawings, which form part of the disclosure and, as an example, illustrate specific aspects of embodiments of the disclosure or specific aspects in which embodiments of the disclosure may be used. It is understood that embodiments of the disclosure may be used in other aspects and may include structural or logical modifications not shown in the drawings. Accordingly, the following detailed description should not be constrained, and the scope of the disclosure is defined by the accompanying claims.

[0089] To aid in understanding this disclosure, examples of wireless communication systems and devices are described below.

[0090] Exemplary communication systems and devices

[0091] Referring to Figure 1, a simplified schematic diagram of a communication system is provided as an illustrative, not limiting, example. The communication system 100 includes a radio access network 120. The radio access network 120 may be a next-generation (e.g., 6G or later) radio access network or a legacy (e.g., 5G, 4G, 3G, or 2G) radio access network. One or more communication electrical devices (EDs) 110a-120j (collectively referred to as 110) may be interconnected with each other in the radio access network 120, or connected to one or more network nodes (170a, 170b, collectively referred to as 170). The core network 130 may be part of the communication system, may depend on the radio access technology used in the communication system 100, or may be independent. The communication system 100 also includes a public switched telephone network (PSTN) 140, the Internet 150, and other networks 160.

[0092] Figure 2 shows an exemplary communication system 100. Generally, 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 operates by sharing resources, such as carrier spectral bandwidth, among its components. The communication system 100 may include a terrestrial communication system and / or a non-terrestrial communication system. The communication system 100 can provide a wide range of communication services and applications, such as earth surveillance, remote sensing, passive sensing and positioning, navigation and tracking, autonomous delivery and mobility, etc. The communication system 100 can provide high availability and robustness through the joint operation of the terrestrial and non-terrestrial communication systems. For example, integrating a non-terrestrial communication system (or its components) into a terrestrial communication system can result in what can be considered a heterogeneous network involving multiple layers. Compared to conventional communication networks, heterogeneous networks can achieve better overall performance through efficient multilink joint operation, more flexible function sharing, and faster physical layer link switching between terrestrial and non-terrestrial networks.

[0093] Terrestrial and non-terrestrial communication systems can be considered subsystems of a communication system. In the illustrated example, communication system 100 includes electronic devices (EDs) 110a-110d (collectively referred to as ED 110), radio access networks (RANs) 120a-120b, non-terrestrial communication networks 120c, core network 130, public switched telephone network (PSTN) 140, the internet 150, and other networks 160. RANs 120a-120b include their respective base stations (BSs) 170a-170b, which may be collectively referred to as terrestrial transceiver points (T-TRPs) 170a-170b. Non-terrestrial communication networks 120c include access nodes 120c, which may be collectively referred to as non-terrestrial transceiver points (NT-TRPs) 120.

[0094] Any ED 110 may be 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, other networks 160, or any combination thereof. In some examples, an ED 110a may communicate uplink and / or downlink transmissions through interface 190a with T-TRP 170a. In some examples, EDs 110a, 110b, and 110d may also communicate directly with each other through one or more sidelink air interfaces 190b. In some examples, an ED 110d may communicate uplink and / or downlink transmissions through interface 190c with NT-TRP 172.

[0095] Air interfaces 190a and 190b may use any suitable radio access technology or similar communication technology. For example, communication system 100 may implement one or more channel access methods in air interfaces 190a and 190b, 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). Air interfaces 190a and 190b may also utilize other, higher-dimensional signal spaces, which may involve combinations of orthogonal and / or non-orthogonal dimensions.

[0096] The air interface 190c can enable communication between the ED 110d and one or more NT-TRP 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 more NT-TRPs for multicast transmission.

[0097] RANs 120a and 120b communicate with the core network 130 to provide EDs 110a, 110b, and 110c with a variety of services, including voice, data, and other services. RANs 120a and 120b and / or the core network 130 may communicate directly or indirectly with one or more other RANs (not shown) that may or may not be directly serviced by the core network 130, and may or may not employ the same radio access technology as RANs 120a, RAN 120b, or both. The core network 130 may also function as a gateway access between (i) 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 other networks 160). In addition, some or all of the ED 110a, 110b, and 110c may include the capability to communicate with different wireless networks through different wireless links using different wireless technologies and / or protocols. Instead of (or in addition to) wireless communication, the ED 110a, 110b, and 110c may communicate with service providers or switches (not shown) and the Internet 150 via wired communication channels. The PSTN 140 may include a circuit-switched telephone network for providing legacy telephone services (POTS). The Internet 150 may include a network of computers and / or subnets (intranets) and may incorporate protocols such as Internet Protocol (IP), Transmission Control Protocol (TCP), and User Datagram Protocol (UDP). The ED 110a, 110b, and 110c are multimode devices capable of operating according to multiple wireless access technologies and may incorporate multiple transceivers necessary to support such technologies.

[0098] Basic Component Structure

[0099] Figure 3 shows another example of ED 110 and base stations 170a, 170b, and / or 170c. The ED 110 is used to connect people, things, machines, etc. The ED 110 can be widely used in a variety of scenarios such as cellular communication, D2D (device-to-device), V2X (vehicle-to-everything), P2P (peer-to-peer), M2M (machine-to-machine), MTC (machine-type communications), IOT (Internet of Things), VR (virtual reality), AR (augmented reality), industrial control, autonomous driving, telemedicine, smart grids, smart furniture, smart offices, smart wearables, smart transportation, smart cities, drones, robots, remote sensing, passive sensing, positioning, navigation and tracking, autonomous delivery and mobility.

[0100] Each ED 110 represents any suitable end-user device for wireless operation, and among other possibilities, may include (or may be referred to as) devices such as user equipment / devices (UE), wireless transmit / receive units (WTRU), mobile stations, fixed or mobile subscriber units, cellular telephones, stations (STA), machine-type communications (MTC) devices, personal digital assistants (PDAs), smartphones, laptops, computers, tablets, wireless sensors, consumer electronic devices, smartbooks, vehicles, cars, trucks, buses, trains, or IoT devices, industrial devices, or equipment (e.g., communication modules, modems, or chips) in the aforementioned devices. Future generations of ED 110 may also be referred to using other terms. Base stations 170a and 170b are T-TRPs and will be referred to as T-TRP 170 below. Also, as shown in Figure 3, the NT-TRP will be referred to as NT-TRP 172 below. Each ED 110 connected to T-TRP 170 and / or NT-TRP 172 may be turned on (i.e., established, activated, or enabled), turned off (i.e., released, deactivated, or disabled), and / or configured dynamically or semi-statically in response to one or more of the connection availability and connection needs.

[0101] ED 110 includes a transmitter 201 and a receiver 203 coupled to one or more antennas 204. Only one antenna 204 is shown. One, some, or all of the antennas may alternatively be panels. The transmitter 201 and receiver 203 may be integrated as, for example, a transceiver. The transceiver is configured to modulate data or other content for transmission by at least one antenna 204 or a 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 wired. Each antenna 204 includes any suitable structure for transmitting and / or receiving wireless or wired signals.

[0102] 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 can be configured to implement some or all of the functions and / or embodiments described herein and can store software instructions or modules executed by the processing unit 210. Each memory 208 includes any suitable volatile and / or non-volatile storage and retrieval device. Any suitable type of memory may be used, such as random access memory (RAM), read-only memory (ROM), hard disk, optical disk, subscriber identification module (SIM) card, memory stick, secure digital (SD) memory card, or on-processor cache.

[0103] 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 Figure 1). The input / output devices enable interaction with users or other devices within the network. Each input / output device includes any suitable structure for providing or receiving information from a user, including network interface communications, such as a speaker, microphone, keypad, keyboard, display, or touchscreen.

[0104] ED 110 further includes a processor 210 for performing operations related to preparing transmissions for uplink transmissions to NT-TRP 172 and / or T-TRP 170, operations related to processing downlink transmissions received from NT-TRP 172 and / or T-TRP 170, and operations related to processing sidelink transmissions to and from another ED 110. Processing operations related to preparing transmissions for uplink transmissions may include operations such as encoding, modulation, transmit beamforming, and generating symbols for transmission. Processing operations related to processing downlink transmissions may include operations such as receive beamforming, demodulation, and decoding of received symbols. Depending on the embodiment, the downlink transmission may also be received by a receiver 203, possibly using receive beamforming, and the processor 210 may extract signaling from the downlink transmission (for example, 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, processor 276 implements transmit beamforming and / or receive beamforming based on beam direction indications, such as beam angle information (BAI), received from T-TRP 170. In some embodiments, processor 210 may perform operations related to network access (e.g., initial access) and / or downlink synchronization, such as operations related to detecting synchronization sequences and decoding and obtaining system information. In some embodiments, processor 210 may perform channel estimation using, for example, reference signals received from NT-TRP 172 and / or T-TRP 170.

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

[0106] The processor 210, and the processing components of the transmitter 201 and receiver 203, may each be implemented by one or more identical or different processors configured to execute instructions stored in memory (e.g., 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).

[0107] In some implementations, T-TRP 170 may be known by other names, among other possibilities, such as base station, base transceiver station (BTS), radio base station, network node, network device, network-side device, transmit / receive node, node B, evolved node B (enode B or eNB), home enode B, next-generation node B (gNB), transmit point (TP), site controller, access point (AP), or wireless router, relay station, remote radio head, ground node, ground network device, or ground base station, baseband unit (BBU), remote radio unit (RRU), active antenna unit (AAU), remote radio head (RRH), central unit (CU), distributed unit (DU), positioning node, etc. T-TRP 170 may be macro BS, pico BS, relay node, donor node, etc., or a combination thereof. T-TRP 170 may refer to a forging device or apparatus (e.g., communication module, modem, or chip) within the aforementioned devices.

[0108] In some embodiments, portions of the T-TRP 170 may be distributed. For example, some of the modules of the T-TRP 170 may be located remotely from the equipment housing the antennas of the T-TRP 170 and may be coupled to the equipment housing the antennas via a communication link (not shown) sometimes known as a fronthaul, such as a Common Public Radio Interface (CPRI). Thus, in some embodiments, the term T-TRP 170 may also refer to network-side modules that perform processing operations such as determining the location of the ED 110, resource allocation (scheduling), message generation, and encoding / decoding, and are not necessarily part of the equipment housing the antennas of the T-TRP 170. These modules may be coupled to other T-TRPs. In some embodiments, the T-TRP 170 may actually be multiple T-TRPs working together to service the ED 110, for example, through coordinated multipoint transmission.

[0109] The T-TRP 170 includes at least one transmitter 252 coupled to one or more antennas 256 and at least one receiver 254. Only one antenna 256 is shown. One, some, or all of the antennas may alternatively be a panel. The transmitter 252 and receiver 254 may be integrated as a transceiver. The T-TRP 170 further includes a processor 260 for performing operations including operations related to preparing a transmission for downlink transmission to ED 110, processing an uplink transmission received from ED 110, preparing a transmission for backhaul transmission to NT-TRP 172, and processing a transmission received from NT-TRP 172 via backhaul. Processing operations related to preparing a transmission for downlink or backhaul transmission may include operations such as encoding, modulation, precoding (e.g., MIMO precoding), transmit beamforming, and generating symbols for transmission. Processing operations related to processing received transmissions on the uplink or through the backhaul may include operations such as receive beamforming, and demodulating and decoding received symbols. The processor 260 may also perform operations related to network access (e.g., initial access) and / or downlink synchronization, such as generating the contents of a synchronous signal block (SSB) and generating system information. In some embodiments, the processor 260 also generates beam direction instructions, e.g., BAI, which can be scheduled for transmission by the scheduler 253. The processor 260 performs other network-side processing operations described herein, such as determining the location of the ED 110 and determining where to deploy the NT-TRP 172. In some embodiments, the processor 260 may generate signaling to constitute, for example, 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 transmitted by the transmitter 252.It should be noted that the term "signaling" as used herein may alternatively be referred to as control signaling. Dynamic signaling may be transmitted in a control channel, for example, a physical downlink control channel (PDCCH), while static or semi-static upper-layer signaling may be included in packets transmitted in a data channel, for example, a physical downlink shared channel (PDSCH).

[0110] The scheduler 253 may be coupled to the processor 260. The scheduler 253 may be contained within the T-TRP 170 or operate independently of the T-TRP 170, which may schedule uplink transmissions, downlink transmissions, and / or backhaul transmissions, including issuing scheduling grants and / or configuring unscheduled ("configured grants") resources. The T-TRP 170 further includes memory 258 for storing information and data. Memory 258 stores instructions and data used, generated, or collected by the T-TRP 170. For example, memory 258 may store software instructions or modules configured to implement some or all of the functions and / or embodiments described herein and performed by the processor 260.

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

[0112] The processing components of processor 260, scheduler 253, and transmitter 252 and receiver 254 may each be implemented by one or more identical or different processors configured to execute instructions stored in memory, for example, memory 258. Alternatively, some or all of the processing components of processor 260, scheduler 253, and transmitter 252 and receiver 254 may be implemented using dedicated circuitry such as FPGAs, GPUs, or ASICs.

[0113] Although the NT-TRP 172 is shown only as a drone as an example, the NT-TRP 172 can be implemented in any suitable non-terrestrial form. The NT-TRP 172 may also 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 shown. One, some, or all of the antennas may alternatively be panels. The transmitter 272 and receiver 274 may be integrated as a transceiver. The NT-TRP 172 further includes a processor 276 for performing operations including preparing transmissions for downlink transmissions to ED 110, processing uplink transmissions received from ED 110, preparing transmissions for backhaul transmissions to T-TRP 170, and processing transmissions received from T-TRP 170 via backhaul. Processing operations related to preparing transmissions for downlink or backhaul transmissions may include operations such as encoding, modulation, pre-coding (e.g., MIMO pre-coding), transmit beamforming, and generating symbols for transmission. Processing operations related to processing received transmissions on the uplink or through backhaul may include operations such as receive beamforming, and demodulating and decoding received symbols. In some embodiments, the processor 276 implements transmit beamforming and / or receive beamforming based on beam direction information (e.g., BAI) received from the T-TRP 170. In some embodiments, the processor 276 may generate signaling to configure one or more parameters of, for example, the ED 110. In some embodiments, the NT-TRP 172 implements physical layer processing but does not implement higher layer functions such as functions in the medium access control (MAC) or radio link control (RLC) layer. This is just an example; more generally, the NT-TRP 172 can implement higher-layer functions in addition to physical layer processing.

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

[0115] The processor 276, and the processing components of the transmitter 272 and receiver 274, may each be implemented by one or more identical or different processors configured to execute instructions stored in memory, for example, memory 278. Alternatively, some or all of the processing components 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, GPU, or ASIC. In some embodiments, the NT-TRP 172 may actually be multiple NT-TRPs working together to service the ED 110, for example, through coordinated multipoint transmission.

[0116] T-TRP 170, NT-TRP 172, and / or ED 110 may include other components, but these are omitted for clarity.

[0117] Basic module structure

[0118] One or more steps of the methods of the embodiments provided herein may be performed by the corresponding units or modules shown in Figure 4. Figure 4 shows units or modules in a device such as ED 110, T-TRP 170, or NT-TRP 172. For example, a signal may be transmitted by a transmission unit or transmit module. For example, a signal may be transmitted by a transmission unit or transmit module. A signal may be received by a receiving unit or receive module. A signal may be processed by a processing unit or processing module. Other steps may be performed by an artificial intelligence (AI) or machine learning (ML) module. Each unit or module may be implemented using hardware, one or more components or devices running software, or a combination thereof. For example, one or more of the units or modules may be integrated circuits such as programmed FPGAs, GPUs, or ASICs. If modules are implemented using software for execution by a processor, for example, it should be understood that those modules may be acquired by the processor for processing, individually or together, as needed, in whole or in part, in one or more instances, and that those modules themselves may contain instructions for further deployment and instantiation.

[0119] Further details regarding ED 110, T-TRP 170, and NT-TRP 172 are known to those skilled in the art; therefore, these details are omitted here.

[0120] 6G Intelligent Air Interface

[0121] An air interface generally includes several components and associated parameters that collectively specify how transmissions are sent and / or received over a wireless communication link between two or more communication devices. For example, an air interface may include one or more components that define waveforms, frame structures, multiple access schemes, protocols, coding schemes, and / or modulation schemes for carrying information (e.g., data) over a wireless communication link. The wireless communication link may support a link between a radio access network and user equipment (e.g., a "Uu" link), and / or a link between devices (e.g., a "sidelink"), such as between two user devices, and / or a link between a non-terrestrial (NT) communication network and user equipment (UE). The following are some examples of the components described above. Waveform components can specify the shape and form of the transmitted signal. Waveform options may include orthogonal multiple access waveforms and non-orthogonal multiple access waveforms. Non-exclusive examples of such waveform options include orthogonal frequency division multiplexing (OFDM), filtered OFDM (f-OFDM), time-windowed OFDM, filtered bank multicarrier (FBMC), universally filtered multicarrier (UFMC), generalized frequency division multiplexing (GFDM), wavelet packet modulation (WPM), faster than Nyquist (FTN) waveforms, and low peak-to-average power ratio (low PAPR WF) waveforms. Frame structure components can specify the configuration of a frame or group of frames. Frame structure components can represent one or more of the following parameters of a frame or group of frames: time, frequency, pilot signature, code, or other parameters of the frame or group of frames. Further details of frame structure are described below. Multiple access scheme components may specify multiple access technique options, including techniques that define how communication devices share a common physical channel. These techniques include 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 multi-carrier code-division multiple access (LDS-MC-CDMA), non-orthogonal multiple access (NOMA), pattern-division multiple access (PDMA), grid-division multiple access (LPMA), resource-spread multiple access (RSMA), and sparse code multiple access (SCMA). Furthermore, multiple access technique options may include scheduled access versus unscheduled access (also known as grant-free access); non-orthogonal multiple access versus orthogonal multiple access via dedicated channel resources (e.g., without sharing among multiple communication devices); competition-based shared channel resources versus non-competition-based shared channel resources; and cognitive radio-based access. Hybrid Automatic Retransmission Request (HARQ) protocol components can specify how transmission and / or retransmission should occur. Non-exclusive examples of transmission and / or retransmission mechanism options include specifying the scheduled data pipe size, the signaling mechanism for transmission and / or retransmission, and the retransmission mechanism. Coding and modulation components can specify how transmitted information can be encoded / decoded and modulated / demodulated for transmission / reception purposes. Coding can refer to methods of error detection and forward error correction. Non-exclusive examples of coding options include turbo trellis codes, turbo product codes, fountain codes, low-density parity check codes, and polar codes. Modulation can simply refer to a constellation (including, for example, modulation technique and order), or more specifically, to various types of advanced modulation methods such as hierarchical modulation and low PAPR modulation.

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

[0123] Frame structure

[0124] A frame structure is a feature of the wireless communication physical layer that defines the time-domain signal transmission structure, for example, to allow for timing references and timing alignment of basic time-domain transmission units. Wireless communication between communication devices can take place over time-frequency resources governed by the frame structure. The frame structure is sometimes referred to as the wireless frame structure instead.

[0125] Depending on the frame structure and / or the configuration of frames within the frame structure, frequency division duplex (FDD), / or time division duplex (TDD), and / or full-duplex (FD) communication may be possible. FDD communication occurs when transmission in different directions (e.g., uplink versus downlink) takes place in different frequency bands. TDD communication occurs when transmission in different directions (e.g., uplink versus downlink) takes place over different durations. FD communication occurs when transmission and reception take place on the same time-frequency resource, meaning that devices can both transmit and receive simultaneously in time on the same frequency resource.

[0126] An example of a frame structure is a Long-Term Evolution (LTE) frame structure with the following specifications: Each frame has a duration of 10 ms, each frame has 10 subframes, each with a duration of 1 ms, each subframe contains 2 slots, each with a duration of 0.5 ms, each slot is for the transmission of 7 OFDM symbols (assuming a normal CP), each OFDM symbol has a certain symbol duration and a specific bandwidth (or partial bandwidth or bandwidth segment) related to the number of subcarriers and subcarrier spacing, and the frame structure is based on OFDM waveform parameters such as subcarrier spacing and CP length (CP has fixed length or limited length options), and the switching gap between the uplink and downlink in TDD must be an integer multiple of the OFDM symbol duration.

[0127] Another example of a frame structure is the frame structure in New Radio (NR) with the following specifications: Multiple subcarrier intervals are supported, each corresponding to a numerology, and the frame structure is numerology-dependent, but in all cases the frame length is set to 10ms and consists of 10 subframes, each 1ms long; slots are defined as 14 OFDM symbols, and slot lengths are numerology-dependent. For example, the NR frame structure for a normal CP 15kHz subcarrier interval ("Numerology 1") is different from the NR frame structure for a normal CP 30kHz subcarrier interval ("Numerology 2"). For the 15kHz subcarrier interval, the slot length is 1ms, and for the 30kHz subcarrier interval, the slot length is 0.5ms. The NR frame structure can have greater flexibility than the LTE frame structure.

[0128] Another example of a frame structure is a representative flexible frame structure for use in, for example, 6G networks or later. In a flexible frame structure, a symbol block may be defined as the minimum duration that can be scheduled in the flexible frame structure. A symbol block can be a unit of transmission having an optional redundancy portion (e.g., a CP portion) and an informational portion (e.g., a data portion). OFDM symbols are an example of a symbol block. Symbol blocks are sometimes referred to alternatively as symbols. Embodiments of a flexible frame structure include various parameters that can be configured, such as frame length, subframe length, and symbol block length. A non-exclusive list of possible configuration parameters in some embodiments of a flexible frame structure includes the following: (1) Frame: The frame length is not limited to 10ms, and the frame length is configurable and may change over time. In some embodiments, each frame includes one or more downlink synchronous channels and / or one or more downlink broadcast channels, each synchronous channel and / or broadcast channel may be transmitted in different directions by different beamforming. The frame length may be more than one possible value and may be configured based on the application scenario. For example, an autonomous vehicle may require relatively fast initial access, in which case the frame length may be set to 5ms for the autonomous vehicle application. As another example, a smart meter in a home may not require fast initial access, in which case the frame length may be set to 20ms for the smart meter application. (2) Subframe duration: Subframes may or may not be defined in the flexible frame structure, depending on the implementation. For example, a frame may be defined to include slots but not subframes. For example, in a frame where subframes are defined for time-domain alignment, the duration of the subframes may be configurable. For example, subframes may be configured to have lengths such as 0.1ms, 0.2ms, 0.5ms, 1ms, 2ms, 5ms, etc. In some embodiments, if subframes are not required in a particular scenario, the subframe length may be defined to be the same as the frame length, or it may not be defined at all. (3) Slot Configuration: Slots may or may not be defined in the flexible frame structure, depending on the implementation. In a frame in which a slot is defined, the slot definition (for example, by duration and / or number of symbol blocks) may be configurable. In one embodiment, the slot configuration is common to all UEs or groups of UEs. In this case, the slot configuration information may be transmitted to the UEs on a broadcast channel or a common control channel. In other embodiments, the slot configuration may be UE-specific, in which case the slot configuration information may be transmitted on a UE-specific control channel. In some embodiments, the slot configuration signaling may be transmitted together with the frame configuration signaling and / or the subframe configuration signaling. In other embodiments, the slot configuration may be transmitted independently of the frame configuration signaling and / or the subframe configuration signaling. Generally, the slot configuration may be system-common, base station-common, UE group-common, or UE-specific. (4) Subcarrier spacing (SCS): SCS is a parameter of scalable numerology that can possibly range from 15 kHz to 480 kHz. SCS may vary with the spectral frequency and / or maximum UE velocity to minimize the effects of Doppler shift and phase noise. In some examples, there may be separate transmit and receive frames, and the SCS of symbols in the receive frame structure may be configured independently of the SCS of symbols in the transmit frame structure. The SCS in the receive frame may be different from the SCS in the transmit frame. In some examples, the SCS of each transmit frame may be half the SCS of each receive frame. If the SCS between the receive and transmit frames is different, for example, if a more flexible symbol duration is implemented using the inverse discrete Fourier transform (IDFT) instead of the fast fourier transform (FFT), the difference does not necessarily need to be scaled by a factor of two. Additional examples of frame structures may be used with different SCSs. (5) Flexible transmission duration of the basic transmission unit: The basic transmission unit may be a symbol block (alternatively called a symbol), which generally includes a redundancy portion (called a 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 change dynamically, possibly per frame, or per group of frames, or per subframe, or per slot, or per scheduling. The information (e.g., data) portion may be flexible and configurable. Another possible parameter for a symbol block that may be defined is the ratio of the CP duration to the information (e.g., data) duration. In some embodiments the symbol block length may be adjusted according to channel conditions (e.g., multipath delay, Doppler), and / or latency requirements, and / or available duration. As another example, the symbol block length may be adjusted to fit the available duration in a frame. (6) Flexible switching gap: A frame may contain both a downlink portion for downlink transmission from the base station and an uplink portion for uplink transmission from the UE. A gap may exist between each uplink portion and downlink portion, which is called a switching gap. The switching gap length (duration) may be configurable. The switching gap duration may be fixed within a frame or flexible within a frame, and the switching gap duration may change dynamically, possibly per frame, per group of frames, per subframe, per slot, or per scheduling.

[0129] Cell, carrier, bandwidth portion (BWP), and occupied bandwidth

[0130] Devices such as base stations can provide coverage across a cell. Wireless communication with a device can occur through one or more carrier frequencies. A carrier frequency is called a carrier. A carrier is sometimes alternatively called a component carrier (CC). A carrier can be characterized by its bandwidth and reference frequency, such as the carrier's center or lowest or highest frequency. A carrier can be on a licensed or unlicensed spectrum. Wireless communication with a device can also occur through one or more BWPs, either additionally or alternatively. For example, a carrier may have one or more BWPs. More generally, wireless communication with a device may occur through the wireless spectrum. The spectrum may contain one or more carriers and / or one or more BWPs.

[0131] A cell may include one or more downlink resources and optionally one or more uplink resources, or a cell may include one or more uplink resources and optionally one or more downlink resources, or a cell may include both one or more downlink resources and one or more uplink resources. For example, a cell may include only one downlink carrier / BWP, or only one uplink carrier / BWP, or multiple downlink carriers / BWPs, or multiple uplink carriers / BWPs, or one downlink carrier / BWP and one uplink carrier / BWP, or one downlink carrier / BWP and multiple uplink carriers / BWPs, or multiple downlink carriers / BWPs and one uplink carrier / BWP, or multiple downlink carriers / BWPs and multiple uplink carriers / BWPs. In some embodiments, the cell may include, instead of or in addition, one or more sidelink resources, such as sidelink transmit and receive resources.

[0132] A BWP can be broadly defined as a set of consecutive or discontinuous frequency subcarriers on a carrier, or a set of consecutive or discontinuous frequency subcarriers on multiple carriers, or a set of discontinuous or consecutive frequency subcarriers that may have one or more carriers.

[0133] In some embodiments, a carrier may have one or more BWPs, for example, a carrier with a bandwidth of 20 MHz and consisting of one BWP, or a carrier with a bandwidth of 80 MHz and consisting of two adjacent consecutive BWPs. In other embodiments, a BWP may have one or more carriers, for example, a BWP may have a bandwidth of 40 MHz and consist of two adjacent consecutive carriers, each having a bandwidth of 20 MHz. In some embodiments, a BWP may include a plurality of non-contiguous spectral resources, where the first of the non-contiguous carriers may be in the mmW band, the second in the low band (such as the 2 GHz band), the third in the THz band (if present), and the fourth in the visible light band (if present). Resources within a single carrier belonging to a BWP may be consecutive or non-contiguous. In some embodiments, a BWP has non-contiguous spectral resources on a single carrier.

[0134] Wireless communication may be conducted through an occupied bandwidth. The occupied bandwidth may be defined as the width of the frequency band, where below the lower limit and above the upper limit of the frequency, the average power emitted is equal to a specified percentage β / 2 of the total average transmitted power, for example, the value of β / 2 is 0.5%.

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

[0136] Terminal type

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

[0138] In this embodiment of the disclosure, the Internet of Things (IoT) may include one or more of the following: NB-IoT, MTC, mMTC, etc., but is not limited to this.

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

[0140] URLLC can refer to a service that offers high reliability, low latency, and extremely high availability. Specifically, URLLC may include the following communication scenarios and applications: industrial applications and control, traffic safety and control, remote manufacturing, remote training, remote surgery, unmanned operation, industrial automation, security industry, etc.

[0141] MTC can refer to low-cost, high-coverage services. It is sometimes called M2M. mMTC refers to large-scale IoT services.

[0142] NB-IoT can be a service characterized by broad coverage, numerous connections, low rates, low costs, low power consumption, and a superior architecture. Specifically, NB-IoT may include smart water meters, smart parking, intelligent pet tracking, smart bicycles, intelligent smoke detectors, intelligent toilets, and intelligent vending machines.

[0143] CPE may refer to a mobile signal access device that receives mobile signals and transmits those mobile signals using wireless fidelity (WiFi) signals, or a device that converts high-speed 4G or 5G signals to WiFi signals and may simultaneously support a relatively large number of mobile devices accessing 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.

[0144] V2X enables communication between vehicles, between vehicles and network devices, and between network devices, allowing for the acquisition of a range of traffic information such as real-time road conditions, road information, and pedestrian information. This information can then be used to provide in-vehicle entertainment, improving driving safety, reducing congestion, and improving traffic efficiency.

[0145] For example, terminal types include eMBB devices, URLLC devices, NB-IoT devices, and CPE devices. eMBB devices are primarily configured to transmit large packets of data, or may be configured to transmit small packets of data, and are generally mobile. Requirements for transmission delay and reliability are common, and both uplink and downlink communications exist. The channel environment is relatively complex and changeable, and indoor or outdoor communications may be used. For example, an eMBB device may be a mobile phone. URLLC devices are primarily configured to transmit small packets of data, or may transmit intermediate packets of data. Generally, URLLC devices belong to a non-mobile state or may travel along a fixed route. URLLC devices have relatively high requirements for transmission delay and reliability, i.e., low transmission delay and high reliability are required, and both uplink and downlink communications exist. The channel environment is stable. For example, a URLLC device may be a factory device. NB-IoT devices are primarily used to transmit small amounts of data. NB-IoT devices are generally stationary, have a known location, have moderate transmission delay and reliability requirements, have a relatively large amount of uplink communication, and have a relatively stable channel environment. For example, an NB-IoT device may be a smart water meter or sensor. CPE devices are primarily used to transmit large packets of data, are generally stationary or can travel over very short distances, have moderate requirements for transmission delay and reliability, have both uplink and downlink communication, and have a relatively stable channel environment. For example, a CPE device may be a terminal device in a smart home, AR, VR, etc. When determining the terminal type of a terminal device, the terminal type may be determined based on the terminal device's service type, mobility, transmission delay requirements, reliability requirements, channel environment, and communication scenario. The terminal type corresponding to a terminal device is determined to be an eMBB device, URLLC device, NB-IoT device, or CPE device.

[0146] Note that eMBB devices may be described as eMBB alternatively, URLLC devices as URLLC alternatively, NB-IoT devices as NB-IoT alternatively, and CPE devices as CPE alternatively. V2X devices may also be described as V2X devices, but are not limited to this.

[0147] Physical Uplink Control Channel (PUCCH) and Physical Transmit Link Control Channel (PTxCCH)

[0148] The physical uplink control channel (PUCCH) is primarily used to carry uplink control information (UCI). Specifically, this information may include information regarding a terminal device requesting uplink resource configuration from a network device, information regarding whether downlink service data has been successfully received by the terminal device, and channel state information (CSI) of the downlink channel reported by the terminal device.

[0149] In some possible implementations, a physical layer control channel, i.e., a physical transmission link control channel (PTxCCH), may be introduced. The function of the PTxCCH is similar to that of the PUCCH in LTE and 5G. Specifically, this channel is used by terminal devices to transmit control information and / or by network devices to receive control information. The control information may include at least one of the following: ACK / NACK information, channel status information, scheduling requests, etc. It should be understood that, in general, standard protocols are written from the perspective of terminal devices. Therefore, the physical layer uplink control channel may be described as the physical layer transmit link control channel.

[0150] Downlink Control Information (DCI)

[0151] Downlink control information (DCI) is control information related to PDSCH and PUSCH that is transmitted over the PDCCH. Terminal devices can only correctly process PDSCH data or PUSCH data when the DCI information is correctly decoded.

[0152] Different DCI uses can vary. For example, there are DCIs used for uplink / downlink transmission resource allocation, DCIs used for uplink power control adjustment, and DCIs used for downlink dual-stream spatial multiplexing. Different DCI formats may be used to distinguish DCIs for different purposes.

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

[0154] To reduce the number of blind detections performed by terminal devices, it is proposed that the information contained in the DCI be transmitted in parts. For example, the first type information is used as the first DCI for transmission, the second type information as the second DCI for transmission, and the third type information as the third DCI for transmission. Alternatively, in another example, the first and second type information are used as the first DCI for transmission, and the third type information is used as the second DCI for transmission. Alternatively, in another example, the first type information is used as the first DCI for transmission, and the second and third type information are used as the second DCI for transmission. The information contained in the DCI is transmitted in parts, thereby allowing terminal devices to process different types of information in parallel, thereby reducing communication delay.

[0155] Blind detection of terminal devices

[0156] Since the terminal device does not know in advance which format of DCI will be carried on the PDCCH to be received, nor which candidate PDCCH will be used to transmit the DCI, the terminal device must perform a blind detection of the PDCCH to receive the corresponding DCI. Before the terminal device successfully decodes the PDCCH, it may attempt to decode each possible candidate PDCCH. This continues until the terminal device successfully detects the PDCCH, or until it reaches the amount of DCI expected to be received by the terminal device or the terminal device's limit on the number of blind detections.

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

[0158] It should be understood that cyclic redundancy check (CRC) bits are typically added to the DCI information bits to implement error detection capabilities for terminal devices, and that different types of radio network temporary identifiers (RNTIs) are used for scrambling in the CRC bits. Therefore, RNTIs are implicitly encoded in the CRC bits. It should be further understood that different RNTIs may be used both to identify terminal devices and to distinguish between DCI purposes.

[0159] In addition, for the terminal device's blind detection process, since the PDCCH contains multiple CCEs or the DCI is carried over multiple CCEs, the terminal device needs to perform blind detection on these multiple CCEs. However, if the terminal device performs blind detection on each CCE individually, the efficiency is relatively low. Therefore, a search space is specified in the protocol. The search space can simply be understood as the granularity at which, when the terminal device performs PDCCH blind detection, the blind detection is performed using several CCEs. For example, if the value of the aggregation level AL of CCEs defined in the search space is 4 or 8, then when the terminal device performs blind detection, the blind detection is performed at the granularity of 4 CCEs, and then at the granularity of 8 CCEs.

[0160] Specifically, when a network device identifies a PDCCH, if the aggregation level AL value of a CCE defined in the search space is 4 or 8, in addition to using the aggregation level parameter (a value of 4 or 8 is selected), the CCE location index parameter is also used, where the CCE location index is obtained through calculation based on the PDCCH's time-frequency domain information, aggregation level, etc. Since a terminal device cannot know the exact aggregation level and starting location index of the CCE occupied by the PDCCH, the terminal device receives upper-layer signaling before receiving the PDCCH, which indicates the PDCCH's time-frequency domain information, etc. In addition, the terminal device determines, based on the protocol, instructions from the network device, etc., that the aggregation level of the PDCCH may be 4 or 8. Therefore, during blind detection, the terminal device can first use aggregation level 4 to calculate the position index of the CCE within the PDCCH (including the starting position index of the CCE) based on the time-frequency domain information of the PDCCH, and then perform blind detection for the corresponding CCE. Subsequently, when the expected DCI is not detected or reaches an amount of DCI that is not expected to be detected, the terminal device can further use aggregation level 8 to calculate the starting position index of the CCE within the PDCCH (the position index of the CCE) based on the time-frequency domain information of the PDCCH, and then perform blind detection for the corresponding CCE.

[0161] Downlink (DL) HARQ and Uplink (UL) HARQ

[0162] For DL ​​HARQ, the MAC (Media Access Control) entity includes a HARQ entity for each serving cell, which maintains several 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 the DL-SCH (DL Shared Channel) to the corresponding HARQ process. A HARQ process supports one TB when the physical layer is not configured for downlink space multiplexing, and supports one or two TBs when the physical layer is configured for downlink space multiplexing. When a transmission is made for a HARQ process, one or two TBs (in the case of downlink space multiplexing) and associated HARQ information are received from the HARQ entity.

[0163] For UL HARQ, the MAC entity contains a HARQ entity for each serving cell with configured uplinks, which maintains several 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.

[0164] The above are possible scenarios or generalized descriptions of embodiments of the present disclosure, and the motivations and technical concepts of the present disclosure are illustrated below.

[0165] Resilience is a fundamental characteristic that needs to be addressed in 6G. With the development of Industry 4.0 and many other technological visions, ultra-high reliability and low latency wireless communication are crucial enablers for large-scale automated manufacturing.

[0166] Two trends are observed towards 6G. From a technical standpoint, mmWave and large-scale MIMO (Multiple-Input Multiple-Output) will become more widespread as they can significantly expand current bandwidth resources. From a service standpoint, a single device will need to support multiple services with different latency and reliability requirements. These two trends, along with more stringent resilience requirements, offer an opportunity to redesign the physical layer.

[0167] As multiple services converge onto a single physical wireless link, potential scenarios emerge. The goal is to provide multiple QoS (Quality of Service) levels for multiple services within a single wireless link. Given high carrier frequencies and large antennas, beamforming can be performed more aggressively, enabling the convergence of multiple services on a single wireless link. However, these services may have a wide variety of KPIs (Key Performance Indicators). As shown in Figure 5, URLLC (Ultra-Reliable Low-Latency Communications), mMTC (massive Machine Type Communication), eMBB (enhanced Mobile Broadband), and Tbps communication may all be integrated into a single beam. This is challenging because different KPIs must be supported under the same wireless channel, SNR (Signal-to-Noise Ratio), fading, etc.

[0168] For two packets with different payload sizes and / or reliability / latency requirements, for example, one eMBB packet with a large payload size and another URLLC packet with a smaller payload size and / or higher reliability requirements, joint coding (or mixed traffic coding) may be used for these two packets.

[0169] Joint coding (also called mixed traffic coding)

[0170] Joint coding refers to the congruent encoding of multiple packets (two or more) into a single codeword, for example, congruently encoding a small packet (e.g., a URLLC packet) and a large packet (e.g., an eMBB packet) into a single codeword. That is, the joint codeword contains multiple payloads. There are two possible solutions for joint coding. Solution 1: Encode multiple payloads into a single codeword. Here, at least one payload is self-decodeable (decodeable locally) and globally decodeable. Solution 2: Encode multiple payloads into a single codeword using unequal error protection.

[0171] Solution 1 provides a self-decodeable congruent coding design such that each individual payload (e.g., corresponding to a certain service) can be self-decoded, and at the same time, congruent decoding is supported to further improve performance. Small messages (e.g., URLLC bits) can be decoded both locally and globally, and larger code blocks (e.g., including eMBB bits) can be decoded globally. Specifically, local decoding is used as the first attempt (lower confidence). If local decoding is successful, the correctly received small code can be used to improve the larger code, as it provides prior information for decoding the larger code. If local decoding fails, global decoding with the larger code is used as the second attempt (higher confidence), i.e., in the second attempt, the small code can be decoded globally (congruently decoded) using the larger code.

[0172] Figures 6a and 6b illustrate self-decoding and (in case of self-decoding failure) congruent decoding. As an example, several smaller or shorter messages may be embedded in or otherwise combined with a longer code block or payload, also referred to herein as a composite payload. These smaller messages are self-decodeable, meaning they can be decoded after collecting only the code bits, or symbols, or subsets of LLRs associated with the longer codeword, rather than the entire longer codeword. A subset of code bits is also a standalone short code or codeword that is decodeable on its own.

[0173] Two or more of these smaller messages are also congruently decodeable. A subset of the code bits corresponding to the congruently decodeable smaller messages is combined with the longer code. This can be achieved through what is referred to herein as "coupling" of bits from multiple messages. For example, some or all of the bits from the first message (smaller code) may be copied and combined with the bits from the second message (larger code). In this example, the bits from the first message may be directly copied and appended to the bits of the second message, or otherwise combined. Another possible option is to first transform the bits from the first message, for example by multiplying by a binary matrix, and then either append the transformed bits to the bits of the second message, or otherwise combine the transformed bits with the bits of the second message.

[0174] While this example refers to information bit (message) coupling, it is also possible to use coded bits for coupling, either additionally or alternatively. For example, in the case of a systematic code, the message bits are also part of the code bits, and thus the two alternatives of information bit coupling or code bit coupling are essentially the same.

[0175] Some embodiments support multiple decoding attempts before requesting a retransmission. For example, joint decoding may actually be inserted or attempted between a decoding failure and a retransmission request. As an example, consider an embodiment that includes a transmission method of three decoding attempts. Referring to Figures 6a and 6b, in the first decoding attempt, the receiver receives a codeword and, after receiving the corresponding minimum required code bits, decodes the first self-decodeable payload of that codeword. If the decoding of the first payload is successful (Figure 6a), after receiving the corresponding minimum required code bits for decoding the second payload, the correctly decoded bits can be used to improve the decoding performance of the codeword for the second payload. If the decoding of the first payload fails (Figure 6b), a second decoding attempt is made. Instead of immediately requesting a retransmission, the receiver proceeds to attempt joint decoding of the first payload with the second payload. After decoding of the second payload, regardless of the success or failure of the second payload decoding, joint decoding can increase the 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, the receiver requests a retransmission (not shown) from the transmitter. This will result in some delay, but the retransmission allows the receiver to perform at least a third decoding attempt. Multiple further decoding attempts may be made using the retransmitted codeword to self-decode from the retransmitted codeword, to jointly decode from parts of the retransmitted codeword, and / or to jointly decode using both the previously received codeword and the retransmitted codeword.

[0176] By adopting the above solution, some or all of the bits of the smaller code are copied for joint coding and combined with the bits of the larger code. On the one hand, after successful decoding of a self-decodeable code, the code rate of at least another code (e.g., eMBB bits) can be reduced, resulting in improved performance. That is, enhanced eMBB is achieved. On the other hand, if a self-decodeable code (e.g., URLLC) fails to decode, instead of requesting a retransmission, the receiver proceeds to jointly decode the self-decodeable code with the larger code. If joint decoding is successful, the code rate of the former can be reduced, resulting in improved performance. That is, URLLC without HARQ is realized.

[0177] Solution 2 involves embedding a small URLLC packet within the eMBB packet. In essence, this concept is a single FEC (Forward Error Correction) for multiple packets. In encoder design, packet priorities are considered, ensuring better protection for packets with higher priority. Priorities can be defined using different metrics, such as reliability priority based on the target BLER (Block Error Ratio), latency priority based on latency requirements, and source priority when packets may originate from different sources in forwarding and multi-hop scenarios.

[0178] This solution could use separate CRCs to allow for individual packet decoding. If a packet fails to decode, the HARQ scheme will request retransmission of the combined codeword.

[0179] Solution 2 can be considered as “priority-based payload mapping”. Figure 7 is a schematic diagram of the joint coding of Solution 2. Specifically, as shown in Figure 7, the payload data (or packets) may be from different applications (or different sources). Firstly, they are grouped according to their QoS requirements and CRC coded separately. Then, a priority-based payload mapping procedure is performed to map each packet to the information bit position of the codeword according to reliability or latency. The reliability or latency of each bit depends on the specific channel coding scheme and decoding algorithm. Figure 7 shows the joint coding of two packets, namely a URLLC payload and an eMBB payload. In practice, more than two packets may be jointly coded.

[0180] One possible improvement to the above solution is to further protect the URLLC payload using an outer code. Figure 8 is a schematic diagram of congruent coding with such a possible improvement. This can achieve additional reliability for the URLLC payload. This is done by inserting another encoding process between CRC coding and priority-based mapping, as shown in Figure 8.

[0181] This disclosure provides details regarding an air interface design for joint coding, and the proposed air interface design for joint coding can be used in both of the above solutions.

[0182] Preemption Solutions

[0183] According to some embodiments of this disclosure, a preemption solution is proposed to enable the latency and reliability requirements of one of two types of service data (e.g., URLLC data) in the multiplexing of two types of service data in NR, for example, URLLC data and eMBB data. In the following description of the preemption solution, URLLC data and eMBB data are taken as examples of two types of service data.

[0184] The preemption solution allows URLLC data for URLLC terminal devices to use resources scheduled for eMBB data for eMBB terminal devices. Figures 9a and 9b show schematic diagrams of an example of a preemption solution. As shown in Figure 9a, initially, resource 901 is scheduled by the network device for eMBB data for the eMBB terminal device. When URLLC data for the URLLC terminal device arrives, to enable latency and reliability requirements for URLLC data, the network device may schedule the URLLC data for the URLLC terminal device to use resource 902 within resource 901 scheduled for eMBB data. The network device can then send instructions to the eMBB terminal device to tell it which portion of resource 901 is to be used by the URLLC terminal device, i.e., which portion of the resources is to be preempted by the URLLC terminal device. Specifically, a preemption indicator (e.g., carried within DCI) may be transmitted in the next slot to indicate which portion of the scheduled resource (i.e., resource 902 in this example) is occupied by the URLLC terminal device. After receiving the preemption indicator, the eMBB terminal device flushes the soft buffer of data on the preempted resource 902, as shown in Figure 9b, and then performs demodulation and decoding.

[0185] In this way, latency and reliability requirements for URLLC data can be guaranteed.

[0186] Furthermore, in the embodiments described above, since some of the eMBB data on the preempted resource 902 is not transmitted, the eMBB terminal device may sometimes fail to correctly decode the entire eMBB data. Therefore, the eMBB data needs to be retransmitted, which may affect eMBB performance.

[0187] This disclosure further provides solutions for improving the performance of the above-described preemption solutions.

[0188] According to the concepts of this disclosure, a first terminal device may receive a first instruction from a network device, the first instruction indicating joint coding on a first resource. Since joint coding is enabled on the first resource, the reliability of data transmitted on the first resource can be improved. Furthermore, first data for the first terminal device and second data for the second terminal device can be jointly coded on the first resource. After receiving the first instruction, the first terminal device can determine that the resource initially scheduled for the first terminal device is to be used for joint coding of the first data for the first terminal device and the second data for the second terminal device. In this way, not only can the latency and reliability requirements of the second data for the second terminal device be improved, but the performance of the first terminal device can also be guaranteed.

[0189] The above briefly describes some of the technical concepts of the present invention. Specific embodiments of the present invention will be described in detail in the following description.

[0190] Figure 10 shows a schematic flowchart of a wireless communication method according to one or more embodiments of the present disclosure. The method may be carried out by a first terminal device. As shown in Figure 10, the method may include the following: S1001 The first terminal device receives a first instruction from a network device. The first instruction indicates a joint coding on the first resource.

[0191] A first terminal device receives a first instruction from a network device, which may indicate joint coding on a first resource. In one implementation, joint coding on the first resource may be enabled for multiple data parts. From the perspective of the sources of the multiple data parts, the multiple data parts receiving joint coding may be from different services; for example, one data part may be URLLC data and another may be eMBB data. The multiple data parts may also be from the same service. From the perspective of the destinations of the multiple data parts, in one implementation, all of the multiple data parts are for the first terminal device. In another implementation, depending on scheduling by the network device, the multiple data parts may be for different terminal devices, and at least one of those data parts is for the first terminal device.

[0192] In some implementations, multiple data portions may include a first data and a second data, and the joint coding on the first resource may be the joint coding of the first data and the second data. In some implementations, for the joint coding here, either solution 1 or solution 2 of the joint coding described above may be applied, the first data may be eMBB data from solution 1 and solution 2, and the second data may be URLLC data from solution 1 and solution 2. In some specific implementations, the information bits of the first data and the information bits of the second data may be multiplexed in the MAC layer and then encoded, which also enables joint coding.

[0193] The solutions of this disclosure can be applied to specific solutions in which the first data (payload) and the second data (payload) are co-coded, and also to specific solutions in which the first MAC PDU (Protocol Data Unit) and the second MAC PDU are co-coded. While implementations for specific solutions in which the first data and the second data are co-coded are described below as examples, it should be noted that these can also be applied to specific solutions in which the first MAC PDU and the second MAC PDU are co-coded.

[0194] In one implementation, the first data may be for a first terminal device, and the second data may be for a second terminal device. That is, this implementation enables joint coding between different terminal devices, which is sometimes called inter-UE joint coding or inter-UE mixed traffic coordination. For example, the first data may be eMBB data, and the second data may be URLLC data.

[0195] In one implementation, first data from a first terminal device and second data from a second terminal device are congruently coded into a first codeword. For example, the second data may be congruently coded with a portion of the first data, or with all of the first data, to form a first codeword containing the first and second data. Which portion of the first data is congruently coded with the second data may be configured (e.g., through RRC signaling), predefined, or indicated by a network device. The first codeword contains a plurality of encoded blocks generated by encoding the first and second data with error-correcting codes, the plurality of encoded blocks containing a self-decodeable encoded block corresponding to the second data. The self-decodeable encoded block is decodeable independently of the other encoded blocks of the plurality of encoded blocks in the first codeword, and the self-decodeable encoded block is further congruently decodeable together with one or more of the other encoded blocks of the plurality of encoded blocks in the first codeword. In other words, the second data may be self-decodeable, and the second data may be congruent decodeable according to the self-decoding result of the second data.

[0196] In one implementation, a first instruction indicating joint coding on a first resource may be carried in a first DCI. The first DCI may indicate resource information (e.g., time / frequency / spatial resources, RE portion, RE location, etc.) and decoding information (e.g., MCS, DMRS, etc.) for the first and second data. For example, the first DCI may indicate at least one of the coding rate of the first data, the coding rate of the second data, resource information for the second data, and the code block index of the first data. Optionally, the first DCI may further indicate HARQ-related information (e.g., HARQ process ID, NDI, RV, feedback resource information, feedback timing information) and other information about the first data.

[0197] In one implementation, a first terminal device receives first and second data on a PDSCH, which have been jointly coded by a network device. A first radio network temporary identifier (RNTI) is used to scramble the PDSCH. In one specific implementation, joint coding is valid for different terminal devices (i.e., the first terminal device and the second terminal device), so the first RNTI (which may be called a joint RNTI or mixed RNTI) may be different from the cell-radio network temporary identifier (C-RNTI) of the first terminal device and different from the C-RNTI of the second terminal device. Optionally, the first RNTI may be represented by a first DCI or may be constructed through RRC signaling.

[0198] The above-described solutions of embodiments of this disclosure may be applied to scenarios having a preemption solution.

[0199] According to preemption solutions in some embodiments, a network device may first schedule resources for a third type of data (e.g., eMBB data) for a first terminal device. When the second type of data (e.g., URLLC data) arrives for a second terminal device, the network device schedules the second type of data for the second terminal device to use a portion of the resources initially scheduled for the third type of data (also called the second resource or preempted resource). That is, a portion of the resources initially scheduled for the third type of data is preempted by the second terminal device to ensure the latency and reliability requirements of the URLLC data. Here, the resources actually occupied by the URLLC data are not limited to being the same size as the second resource. In this case, the data initially scheduled for the first terminal device is not transmitted over the preempted resource, and instead, the second type of data for the second terminal device is transmitted over the preempted resource. Therefore, the first terminal device may not be able to correctly decode the received data, thereby affecting the performance of the first terminal device.

[0200] According to some other embodiments of the present disclosure, when second data (e.g., URLLC data) arrives for a second terminal device, a network device may decide to allow the second resource in the resources initially scheduled for the third data to be “preempted.” Instead of using the preempted second resource to transmit the second data without transmitting the data initially scheduled to be transmitted on the second resource, according to these embodiments of the present disclosure, the network device enables joint coding of the second data for the second terminal device and the first data of the third data for the first terminal device. The network device may schedule a first resource to be used for jointly coded data (i.e., a first codeword) of the second and first data. In some implementations, the first resource includes the second resource; that is, the second resource initially scheduled for the third data is hereby used for the jointly coded data. In other words, the second resource is an overlapping resource between the resource initially scheduled for the third data and the first resource.

[0201] After receiving a first instruction indicating joint coding on the first resource (for example, in the next scheduling period or in the next PDCCH monitoring opportunity, such as in the next slot), the first terminal device can determine that the second resource initially scheduled for the third data overlaps with at least a portion of the first resource. The first terminal device can then determine that the data initially scheduled on the second resource is not transmitted by the network device, and that the jointly coded data, including the first and second data, is transmitted on the first resource, which includes the second resource. At this point, the first terminal device can decode the received data to obtain the third data and the second data. In a particular implementation, the first terminal device may combine the first data from the jointly coded data with the data received on the initially scheduled resource other than the second resource to obtain the combined third data. In this implementation, since the second data is for the second terminal device, the first terminal device can discard the second data.

[0202] The embodiments and examples described herein illustrate the joint coding of two types of traffic data, which may also be called mixed traffic coding. However, the disclosure is not limited thereto, and for example, the solutions of the disclosure may also be applied to the joint coding of more than two types of traffic data, or joint coding for different control information, or joint coding for control information and traffic data.

[0203] In the wireless communication method provided by this disclosure, the first terminal device receives a first instruction from the network device, where the first instruction indicates joint coding on a first resource. Since joint coding is enabled on the first resource, the reliability of the data transmitted on the first resource can be improved. Furthermore, first data for the first terminal device and second data for the second terminal device can be jointly coded on the first resource. After receiving the first instruction, the first terminal device can determine that the resource initially scheduled for the first terminal device is to be used for joint coding of the first data for the first terminal device and the second data for the second terminal device. In this way, not only can the latency and reliability requirements of the second data for the second terminal device be improved, but the performance of the first terminal device can also be guaranteed.

[0204] In the above, the wireless communication method of the present invention was described from the perspective of a first terminal device in combination with Figure 10. Hereafter, the wireless communication method of the present disclosure will be described from the perspective of a network device in combination with Figure 11. Figure 11 shows a schematic flowchart of another wireless communication method according to one or more embodiments of the present disclosure. The method may be carried out by a network device. As shown in Figure 11, the method may include the following: S1101 The network device sends a first instruction to a first terminal device. The first instruction indicates a joint coding on a first resource.

[0205] For S1101, please refer to the explanation for S1001, and it will not be repeated here.

[0206] In the wireless communication method provided by this disclosure, a network device transmits a first instruction to a first terminal device, the first instruction indicating joint coding on a first resource. Since joint coding is enabled on the first resource, the reliability of the data transmitted on the first resource can be improved. Furthermore, first data for the first terminal device and second data for the second terminal device can be jointly coded on the first resource. That is, the resource initially scheduled for the first terminal device is used for joint coding of the first data for the first terminal device and the second data for the second terminal device. In this way, not only can the latency and reliability requirements of the second data for the second terminal device be improved, but the performance of the first terminal device can also be guaranteed.

[0207] To provide a clearer explanation of the wireless communication method of this disclosure, the method will be described in more detail below, using the example that the first and third data are eMBB data and the second data is URLLC data. Details regarding joint coding between different terminal devices (i.e., inter-UE joint coding) are given below for illustrative purposes, and it should be noted that these may also be applicable to other types of joint coding, such as normal joint coding (scheduling jointly coded data only once), intra-UE joint coding (for example, scheduling non-jointly coded data for a terminal device once, and then scheduling jointly coded data for the same terminal device a second time, with these two schedulings having overlapping resources).

[0208] Figure 12 is a schematic flowchart of yet another wireless communication method according to one or more embodiments of the present disclosure. This method includes the following steps:

[0209] S1201 The network device sends a second DCI to the first terminal device to schedule the third data, and begins sending the third data to the first terminal device.

[0210] S1202 The first terminal device receives a second DCI from the network device and receives a first portion of the third data according to the second DCI.

[0211] The network device may transmit a second DCI to the first terminal device. The second DCI is used to schedule the third data. The second DCI may schedule one or more TBs for the third data. Each TB may correspond to one or more CBs (code blocks). The second DCI may also indicate scheduling information for the third data, which may include resource information for the third data (e.g., time / frequency / spatial resources, RE portion, RE position, etc.) and decoding information (e.g., MCS, DMRS, etc.). Optionally, the scheduling information for the third data may also include HARQ-related information (e.g., HARQ process ID, NDI, RV, feedback resource information, feedback timing information, etc.) and other information about the third data (e.g., measurement instructions, power control instructions, etc.). In a particular implementation, the resource information for the third data may include resources scheduled for the third data for the first terminal device, which may be called the resources initially scheduled for the third data.

[0212] A network device begins transmitting third data to a first terminal device, and the first terminal device begins receiving the third data. In this case, a preemption scenario can be considered as an example. For example, the first terminal device receives the first part of the third data, and then the need for preemption arises. For example, one TB is scheduled for the third data, and this one TB may correspond to N+1 CBs, i.e., CB0 to CBN (i.e., the nth CB). The first part of the third data may be CB0 and CB1 of the third data.

[0213] Please note that the execution order of S1201 and S1202 is illustrative and not limited to this disclosure. For example, a network device may send a second DCI to a first terminal device, and the first terminal device may receive the second DCI from the network device. The network device then begins to send a third data to the first terminal device, and the first terminal device begins to receive the third data according to the second DCI.

[0214] S1203 The network device transmits a first codeword to a first terminal device, the first codeword being generated by jointly coding first data for the first terminal device and second data for the second terminal device, and transmitted over the first resource, where the first data is part of third data.

[0215] S1204, the first terminal device receives the first codeword from the network device.

[0216] As an example, continuing the preemption scenario, after the first terminal device has received the first portion of the third data, the second data for the second terminal device may arrive. The network device may decide to allow the second resource in the resources initially scheduled for the third data to be preempted. In one example, the first data may be the data of the third data that should be sent after the first portion of the third data. In one implementation, the first data may include one or more CBs. For example, the second data may be congruently encoded with one or more CBs of the third data (i.e., the first data), which may be configured or predefined. For example, if the first portion of the third data is CB0 and CB1 of the third data, the first data may be CB2 and CB3 of the third data. Instead of using a preempted second resource to send second data without sending the data initially scheduled to be sent on the second resource, one implementation enables the network device to enable joint coding of second data for a second terminal device and first data of a third data set for a first terminal device. The first data is for the first terminal device, and the second data is for the second terminal device, thus enabling joint coding between different terminal devices. In one implementation, the second data (e.g., URLLC data) may have a smaller payload size than the third data (e.g., eMBB data). In one example, the second data may also have higher reliability requirements than the third data. In the following description, eMBB data is used as an example of the first and third data, and URLLC data is used as an example of the second data. The first terminal device may be called an eMBB terminal device, and the second terminal device may be called a URLLC terminal device.

[0217] The first data of a first terminal device and the second data of a second terminal device are congruently coded into a first codeword. The second data may be congruently coded with a portion of the first data, or with all of the first data, to form a first codeword containing the first data and the second data. Which portion of the first data is congruently coded with the second data may be configured (for example, through RRC signaling), predefined, or indicated by a network device. The first codeword may contain a plurality of encoded blocks generated by encoding the first data and the second data with error-correcting codes, the plurality of encoded blocks may contain a self-decodeable encoded block corresponding to the second data. The self-decodeable encoded block may be decodeable independently of the other encoded blocks of the plurality of encoded blocks of the first codeword, and the self-decodeable encoded block may be further decodeable together with one or more of the other encoded blocks of the plurality of encoded blocks of the first codeword. In other words, the second data (for example, URLLC data) may be self-decodeable, and the second data may be congruent decodeable according to the self-decoding result of the second data.

[0218] In some implementations, for the joint coding described herein, either solution 1 or solution 2 of the joint coding method can be applied, where the first data may be eMBB data from solution 1 and solution 2, and the second data may be URLLC data from solution 1 and solution 2. In some specific implementations, the information bits of the first data and the information bits of the second data may be multiplexed and then encoded at the MAC layer, which also enables joint coding. Note that the solutions of this disclosure can be applied to specific solutions in which the first data (payload) and the second data (payload) are jointly coded, and can also be applied to specific solutions in which the first MAC PDU (protocol data unit) and the second MAC PDU are jointly coded. Implementations for specific solutions in which the first data and the second data are jointly coded are described below as examples, and note that they can also be applied to specific solutions in which the first MAC PDU and the second MAC PDU are jointly coded.

[0219] There are two possible approaches to implementing collaborative coding:

[0220] Method 1: The first data and one CB of the second data may be congruently encoded into a first codeword (i.e., a congruent codeword), where the corresponding CB index for the CB of the third data for forming the first codeword may be predefined, indicated (e.g., by DCI), or configured (e.g., through RRC signaling). That is, which parts of the third data are used as the first data for congruent coding, and which parts of the first data are specifically congruently coded together with the second data, may be configured (e.g., through RRC signaling) or predefined.

[0221] For example, one TB may be scheduled for the third data, and this one TB may correspond to N+1 CBs, i.e., CB0 to CBN (i.e., the nth CB). The first part of the third data may be CB0 and CB1 of the third data, and the first data may be CB2 of the third data. The second data is congruently encoded with CB2 of the first data to form the first codeword. In another example, the first data may be CB2 and CB3 of the third data, and the second data is congruently encoded with CB2 of the first data to form the first codeword. In this case, it can be understood that the first codeword also includes information about CB3, which is part of the first data but is not congruently coded with the second data. In yet another example, the first data may be CB2 and CB3 to CBN of the third data, and the second data is congruently encoded with CB2 of the first data to form the first codeword. In this case, it can be understood that the first codeword also includes CB3-CBN information, which is part of the first data but is not co-coded with the second data. For ease of explanation, the first codeword in this case is also referred to in this disclosure as co-coded data or co-coded codeword.

[0222] In a particular implementation of Method 1, a limitation on the maximum encoded information length in channel coding is taken into consideration, for example, assuming that the total number of information bits is Nmax and reaches the maximum encoded information length. When the CBs of the second data and the third data are congruently encoded, the second data may occupy a portion of the information bits, and as a result, the length of codeable information in the CB is less than Nmax. Therefore, in an example of this disclosure, different CBs of the third data may have different payload sizes, for example, the payload size of CB2 may be smaller than the payload sizes of CB3 to CBN, in which case CB2, having the smaller payload size, is congruently coded with the second data.

[0223] Method 2: Two or more CBs of the first data and the second data may be identically encoded into the first codeword, and the number of CBs to be identically coded and the corresponding CB indexes may be predefined or configured (e.g., through RRC signaling). For example, the second data may be identically encoded with two or more CBs of the third data to form the first codeword. Specifically, the second data and M CBs (where 1 < M ≤ N) may be identically encoded into M encoded blocks, and each encoded block includes the second data. As shown in FIG. 13 illustrating an example of identical coding between different terminal devices, the first part of the third data in this example is CB0 and CB1 of the third data, and the first data may be CB2 and CB3 of the third data. The second data is identically encoded with CB2 and CB3 of the third data to form the first codeword. Specifically, the second data and two CBs (e.g., CB2 and CB3) may be identically encoded into two encoded blocks, and each encoded block includes the second data. In other examples, it can be understood that the second data may be identically encoded with the remainder of the third data, e.g., CB2 to CBN of the third data, which will not be elaborated. Specifically, the second data and N - 1 CBs (e.g., CB2 to CBN) may be identically encoded into N - 1 encoded blocks, and each encoded block includes the second data. Method 2 may be beneficial for further improving the reliability of the second data. For example, the second data may be repeated and identically encoded with multiple CBs.

[0224] In one implementation, the second data (URLLC data as shown in the shaded area of ​​Figure 13) in the first codeword (i.e., the congruent codeword) is self-decodeable. In addition, the CB2 and CB3 of the second and third data are congruently encoded into the first codeword, with the second data representing information about the second data and the CB2 and CB3 of the third data representing information about the first data. After congruent coding, the first codeword contains information about both the second and first data. Note that the halftone area in Figure 13 contains not only information about the CB2 and CB3 of the third data (for example, corresponding to the larger codes in Figures 6a and 6b), but also some or all of the information about the bits of the second data embedded by congruent coding. Thus, after successful self-decoding of the second data in the halftone area, the second data can be used to improve the decoding of the CB2 and CB3 of the first data. The correctly decoded second data provides prior information for decoding the portion within the halftone area, including the CB2 and CB3 information of the first data and some or all of the bits of the already correctly decoded second data. In this way, the augmented third data is achieved. However, for the sake of simplicity, the portion within the halftone area will be simply referred to as CB2 and CB3 of the third data in the following explanation, and it should be understood that the portion within the halftone area has some or all of the bits of the second data embedded within it.

[0225] The following explanation will use Method 2 as an example of a joint coding implementation. Please understand that Method 1 can also be applied.

[0226] A network device may schedule a first resource to be used to transmit a first codeword. In one implementation, the first resource includes a second resource; that is, the second resource initially scheduled for a third data is now used for the first codeword. In other words, the second resource is the overlapping resource between the resource initially scheduled for the third data and the first resource.

[0227] A first terminal device may receive a first codeword from a network device. In one implementation, the first terminal device receives the first codeword from the network device on the PDSCH. A first RNTI is used to scramble the PDSCH. In one specific implementation, joint coding is enabled for different terminal devices (i.e., a first terminal device and a second terminal device), so the first RNTI (sometimes called a joint RNTI or mixed RNTI) may be different from the C-RNTI of the first terminal device and different from the C-RNTI of the second terminal device. That is, the first RNTI is used for joint coding between different terminal devices. Optionally, the first RNTI may be shown in a first DCI or may be configured through RRC signaling.

[0228] S1205 The network device transmits a first DCI to a first terminal device, and the first instruction is carried in the first DCI, indicating a joint coding on the first resource.

[0229] S1206 The first terminal device receives the first DCI from the network device.

[0230] The first instruction in the first DCI may indicate joint coding on the first resource. The first DCI may indicate resource information (e.g., time / frequency / spatial resource, RE portion, RE position, etc.) and decoding information (e.g., MCS, DMRS, etc.) of the first codeword containing the first data and the second data. For example, the first DCI may indicate at least one of the coding rate of the first data, the coding rate of the second data, resource information of the second data, and the code block index of the first data. Optionally, the first DCI may further indicate HARQ-related information (e.g., HARQ process ID, NDI, RV, feedback resource information, feedback timing information) and other information about the third data.

[0231] In one implementation, the network device may send a first DCI carrying the first instruction to the first terminal device after sending the first codeword. In a further example, the network device may send a first DCI carrying the first instruction to the first terminal device after sending the first codeword (including the first and second data) and the third data (excluding the data initially scheduled on preempted resources). For example, the first DCI may be sent within the next scheduling period or the next PDCCH monitoring opportunity of the first terminal device, such as within the next slot. Note that the timing of sending the first DCI is not limited to the above, as long as the first terminal device can obtain the above information related to joint coding before decoding the received data.

[0232] In some implementations, for a first terminal device, there may be a reference resource area configured by a network device, either predefined (e.g., agreed upon by both parties according to a protocol) or, for example, through RRC signaling. The first terminal device may buffer data received in the reference resource area. The first resource used for the first codeword and the resource initially scheduled for the third data are included in the reference resource area, so that the first terminal device can not only receive the third data based on the second DCI, but also receive the first codeword on the first resource even if the first DCI for scheduling the first codeword has not been received, for example, in some implementations where the first DCI is received in the next scheduling period or the next PDCCH monitoring opportunity. The reference resource area may be indicated to the first terminal device before the transmission of the second DCI, and it should be noted that the timing of such indication is not limited, as long as the reception of normally scheduled data and possible jointly coded data for the first terminal device can be guaranteed.

[0233] In one implementation, there may be multiple ways in which the first DCI points to the first resource in the reference resource area, for example, including at least one of the following: an M×N time-frequency bitmap corresponding to the reference resource area (where M and N are integers greater than 0), an index in a resource allocation table corresponding to the reference resource area, or the resource location of the first resource in the reference resource area.

[0234] S1207 The first terminal device performs decoding on the received data according to the first DCI and the second DCI.

[0235] After receiving a first instruction indicating joint coding on a first resource (for example, in the next scheduling period or in the next PDCCH monitoring opportunity, for example, within the next slot), the first terminal device can determine that the second resource initially scheduled for the third data (more precisely, for the first data) overlaps with at least a portion of the first resource. The first terminal device can then determine that the data initially scheduled on the second resource is not transmitted by the network device, and that a first codeword containing the first and second data is transmitted on the first resource containing the second resource. At this point, the first terminal device can decode the received data to obtain the third data and the second data.

[0236] For a first codeword containing eMBB data (e.g., CB2 and CB3 corresponding to the larger code in Figures 6a and b) and URLLC data, in one implementation, a first terminal device may perform multiple decoding attempts before requesting retransmission. In the first decoding attempt, the first terminal device performs self-decoding of the URLLC data according to a first DCI. Specifically, self-decoding of the URLLC data may be performed after receiving the corresponding minimum required sign bits of the URLLC data. If self-decoding of the URLLC data is successful, after receiving the corresponding minimum required sign bits of the eMBB data, the correctly decoded bits can be used to improve decoding performance for a second data portion (e.g., eMBB data). In particular, if self-decoding of the URLLC data fails, a second decoding attempt is made. The first terminal device may then proceed to attempt conjugate decoding of the URLLC data with the eMBB data (larger code). After joint decoding, regardless of whether the eMBB data is successfully decoded or not, joint decoding can increase the probability that the URLLC data will be successfully decoded. In this example, if the decoding of the eMBB data fails after a second (joint) decoding attempt, the first terminal device may request retransmission from the network device. Retransmission allows the first terminal device to perform at least a third decoding attempt. Note that multiple further decoding attempts may be made using the retransmitted data, for example, to perform self-decoding from the retransmitted data, to perform joint decoding from parts of the retransmitted data, and / or to perform joint decoding using both the previously received first codeword and the retransmitted data. Note that since only the eMBB data in the first codeword is for the first terminal device, the first terminal device may not perform self-decoding for the URLLC data and may only decode the eMBB data.

[0237] In one implementation, a first terminal device may combine the first data obtained from the first codeword with data received on the first scheduled resource other than the second resource (e.g., CB0, CB1, CB4~CBN) to obtain a combined third data. In this implementation, since the second data is for the second terminal device, the first terminal device can discard the second data.

[0238] After decoding the received data, the first terminal device performs feedback on the third data based on HARQ-related information, which includes feedback resource information and feedback timing information for the third data. In one implementation, the HARQ feedback may be based on HARQ-related information contained in a second DCI. In another implementation, the HARQ feedback may be based on HARQ-related information contained in a first DCI. If both the first and second DCIs contain HARQ-related information, whether to use the HARQ-related information from the first or second DCI may be predefined (for example, the first terminal device may simply ignore the HARQ-related information in the second DCI), or it may be configured, for example, through RRC signaling.

[0239] Since joint coding is enabled on the first resource, the reliability of data transmitted on the first resource may be improved. Furthermore, since the resource initially scheduled for the first terminal device is used for joint coding of the first data for the first terminal device and the second data for the second terminal device, not only may the latency and reliability requirements for the second data for the second terminal device be improved, but the performance of the first terminal device may also be guaranteed.

[0240] Here, we will provide further details and examples regarding joint coding across different terminal devices.

[0241] Figure 13 shows an example of joint coding between different terminal devices according to one or more embodiments of the present disclosure.

[0242] In this example, when an eMBB terminal device (i.e., the first terminal device) is scheduled by the second DCI to transmit DL eMBB data (i.e., third data including one eMBB TB, etc.) on resource 1302, DL URLLC data arrives for the URLLC terminal device (i.e., the second terminal device) during the transmission of the eMBB TB. The eMBB TB corresponds to five CBs, i.e., CB0 to CB5. The network device reallocates the resources scheduled for the eMBB terminal device to the URLLC terminal device. Reallocation means that a portion of the resources that were originally allocated to the eMBB terminal device are now allocated to the URLLC terminal device. In this example, resources initially scheduled by the second DCI for CB2 and CB3 (corresponding to the second resource 1304 in Figure 13) are reallocated, as shown in Figure 14, which shows a schematic diagram of joint coding from the terminal device's perspective. Referring back to Figure 13, the network device jointly encodes the URLLC data together with the partial eMBB data (e.g., CB2 and CB3) of the eMBB terminal device on the second resource 1304 to form a first codeword on the first resource 1306, and transmits a third DCI to the URLLC terminal device to indicate scheduling information to the URLLC terminal device. Which portion of the eMBB data is used for joint coding with the URLLC data may be indicated or configured by the network device or by a predefined rule. The predefined rule may be that the portion of the eMBB data to be jointly coded is a CB scheduled to be transmitted on an overlapping resource between what is indicated by the second DCI for the eMBB terminal device and what is indicated by the third DCI for the URLLC terminal device, i.e., CB2 and CB3 (i.e., the first data as described above).It should be noted that if a portion of CB2 is transmitted before the second data arrives, i.e., if the first terminal device receives only a portion of CB2, the entire CB2 may be used for joint coding. In other words, the first codeword may contain information from the entire CB2.

[0243] For specific implementations of congruent coding, URLLC data can be congruently encoded with one or more CBs of eMBB data, which may be constructed or predefined. In one example, URLLC data is congruently encoded with one CB of eMBB data (i.e., CB2) that has the lowest CB index to be congruently encoded in the congruent codeword. The benefit of this example is that fast URLLC decoding is achieved after receiving the congruent codeword of the URLLC data and the one eMBB CB. In another example, URLLC data is congruently encoded with multiple CBs. For example, URLLC data is congruently encoded with all CBs to be congruently encoded in the congruent codeword (CB2 and CB3 in Figures 13 and 14). In this case, as described above, the portions within the halftone areas in Figures 13 and 14 include not only CB2 and CB3 of the eMBB data (e.g., corresponding to the larger codes in Figures 6a and 6b), but also some or all of the bits of URLLC data embedded by congruent coding. The benefit of this example is that URLLC reliability is further improved.

[0244] URLLC terminal devices decode URLLC data by joint decoding (multiple decoding attempts as described above). For example, a URLLC terminal device self-decodes the URLLC data, and if that fails, jointly decodes the URLLC data and partial eMBB data (CB2 and CB3) within the joint codeword (i.e., the first codeword on the first resource 1306).

[0245] The network device sends a first instruction (i.e., a mixed traffic instruction) to the eMBB terminal device in the first DCI in the next slot, for example, to indicate scheduling information about the jointly coded data (i.e., the first codeword) in the previous slot. In this way, compared to preemption solutions in some embodiments in which the preempted information (CB2 and CB3) is not transmitted, the eMBB terminal device in Figure 13 can obtain its entire coded information (for example, by combining CB2 and CB3 from the first codeword with the initially scheduled CB0, CB1, CB4, and CB5).

[0246] By utilizing the mixed traffic coordination described above, not only is the latency of URLLC terminal devices improved, but the performance of eMBB terminal devices is also guaranteed because all eMBB data is transmitted.

[0247] The following provides further details based on this example.

[0248] If a URLLC terminal device is configured for different types of joint coding, such as inter-UE joint coding and intra-UE joint coding, the third DCI indicates whether joint coding is enabled and whether the joint coding is for inter-UE joint coding or intra-UE joint coding. For example, the third DCI may have an inter-UE mixed traffic indicator. The inter-UE mixed traffic indicator may be carried in a field of the third DCI having 1 bit. A value of "1" in the field may indicate that inter-UE joint coding is enabled, and a value of "0" may indicate that inter-UE joint coding is disabled or that intra-UE joint coding is enabled. If a URLLC terminal device is configured for inter-UE joint coding, the third DCI indicates whether joint coding is enabled.

[0249] When inter-UE joint coding is enabled, the third DCI indicates that URLLC data is jointly encoded with some eMBB data and indicates the time / frequency / spatial resources for joint information. The PDSCH of the joint codeword is scrambled using a sequence, where the scramble sequence generator is initialized with a mixed RNTI other than C-RNTI (corresponding to the first RNTI described above), and the mixed RNTI is configured by the network device for the URLLC terminal device and the eMBB terminal device.

[0250] If inter-UE joint coding is enabled in this transmission, the URLLC terminal device assumes that mixed RNTI will be used for PDSCH scrambling sequence generation; otherwise, if inter-UE joint coding is disabled in this transmission, the URLLC terminal device assumes that C-RNTI will be used for PDSCH scrambling sequence generation.

[0251] The URLLC terminal device decodes the URLLC data through self-decoding and joint decoding with the eMBB data, i.e., through two decoding attempts as described above. The URLLC terminal device discards the received eMBB data.

[0252] The eMBB terminal device is configured by a network device or has a predefined reference DL resource area (corresponding to the reference resource area described above), as shown by the dashed box 1308 in Figure 13. Figure 15 also shows a schematic diagram of an example of a reference resource area for an eMBB terminal device. The eMBB terminal device needs to buffer the received data in the reference DL resource of the reference DL resource area 1502.

[0253] For eMBB terminal devices, slot-based scheduling is generally configured by the network device, and the DCI monitoring cycle is a slot. When the second DCI indicates resources for a DL eMBB TB in the PDSCH, the eMBB terminal device is unaware that some of its scheduled resources will be reallocated to another URLLC terminal device. In the next slot, the first instruction in the first DCI indicates that some of the resources will be reallocated to a URLLC terminal device, and that joint coding will occur in the previous slot.

[0254] Therefore, the first DCI carrying the first instruction is a special DCI (called a mixed traffic instruction DCI) and is an instruction to each eMBB terminal device in the time domain and / or frequency domain of the affected eMBB resources. The “affected” resources mean resources for a jointly coded codeword of partial eMBB data and other URLLC data. The second DCI allows the eMBB terminal device to know which portion of the scheduled resources has been used by another downlink transmission by checking the overlapping region of the “affected” resources(s) and scheduled resources(s).

[0255] For buffer management of the eMBB terminal device, according to the second DCI for eMBB scheduling, the eMBB terminal device places the received data within the scheduled time and frequency resources into a soft buffer. As shown in Figure 16, which provides a schematic diagram of an example of buffer management, the eMBB terminal device places CB0, CB1, CB2', CB3', CB4, and CB5 within the scheduled time and frequency resources into a soft buffer. Here, CB2' and CB3' are actually data on preempted resources, and are no longer CB2 and CB3 as the preempted resources are reallocated for another transmission. After receiving a mixed traffic instruction, the eMBB terminal device knows which portion of the scheduled resources (i.e., the second resource 1304 in Figure 13) has been used by another downlink transmission and knows the first resource (i.e., the first resource 1306 in Figure 13) for the jointly coded codeword (first codeword) of the partial eMBB data and another URLLC data. Therefore, the eMBB terminal device uses the received data in the first resource 1306 (i.e., CB2 and CB3) to replace the received data in the second resource 1304 (i.e., CB2' and CB3') with a soft buffer.

[0256] Several alternatives are provided for how the time domain and / or frequency domain of affected eMBB resources are represented to each eMBB terminal device(s). In the first alternative, an M×N time-frequency bitmap represents the resources in the reference DL resource, where the values ​​of M and / or N are configured or predefined. In the second alternative, an index in a time-frequency allocation table is used, where the time-frequency allocation table is predefined or configured, and the rows in the table represent time and frequency resources. In the third alternative, an index in a time allocation table and RB or RBG in the reference DL resource are used, where the time allocation table is predefined or configured. The rows in the table represent time-domain resources, and the network device also represents the frequency location for the resource, for example, the RB or RBG location.

[0257] The first DCI also indicates scheduling information in the preceding resource for the joint codeword. The scheduling information includes, but is not limited to, at least one of the following: a mixed RNTI value for determining the PDSCH scrambling sequence; the MCS of URLLC and / or eMBB in the jointly coded data; the RE used by URLLC (e.g., the RE portion in the indicated resource); and the eMBB CB index in the jointly decoded data. Alternatively, the eMBB CB index(s) in the jointly coded data may be determined by a predefined rule: CBs that are not transmitted and / or URLLC data that are partially transmitted in non-overlapping resources before arrival are determined to be included in the jointly coded data.

[0258] After receiving scheduling information within a mixed traffic instruction, the eMBB terminal device can decode its portion of the data within the joint codeword in the indicated resource for joint coding (i.e., the first resource). By HARQ combing the two portions of data (one portion scheduled by the second DCI and the other portion jointly encoded with another URLLC data), the eMBB terminal device can decode the data.

[0259] It should be noted that in some embodiments, S1201 and S1202 may not be necessary. For example, for scheduling requirements for both URLLC data for a second terminal device and eMBB data for a first terminal device, the network device may directly schedule the URLLC data and at least a portion of the eMBB data as co-coded data without first scheduling the eMBB data. Of these embodiments, parts that are the same as those in the embodiments described above will not be repeated here.

[0260] In this disclosure, PDSCH processing delays are further considered for joint coding. In related technologies, assigned HARQ-ACK timings K1 and K offset The first uplink symbol of the PUCCH, including the effect of timing advance, carries HARQ-ACK information defined by (if configured) and the PUCCH resources to be used, such that the first uplink symbol of the PUCCH does not start earlier than symbol L1, where L1 is later than the end of the last symbol of the PDSCH carrying the TB whose CP is received and confirmed. proc,1 =(N1+d 1,1 +d2)(2048+144)·κ2 -μ ·T c +T extWhen defined as the next uplink symbol that follows, the terminal device shall provide a valid HARQ ACK / NACK message. The reference time for initiating PDSCH processing is the end of the last symbol of the PDSCH carrying the TB to be acknowledged. (For definitions of the relevant parameters, see Non-Patent Literature 1.) [Non-Patent Document 1] 3GPP NR specification TS38.214 V17.2.0

[0261] Figure 17 is a schematic flowchart of yet another wireless communication method according to one or more embodiments of the present disclosure, where PDSCH processing delay is taken into consideration. Based on the embodiment of Figure 12, the method may further include the following: S1208 The first terminal device transmits a first PUCCH that carries the result of the PDSCH processing on the third data.

[0262] The first PUCCH may carry HARQ ACK / NACK information for the third data (e.g., eMBB data). For joint coding between different terminal devices, the first terminal device (eMBB terminal device) may need to perform two decodes: one to decode partial data in the first transmission (i.e., the initially scheduled transmission) and the other to decode the remaining partial data in the second transmission (i.e., the transmission of the joint codeword for the second data and the first data). In addition, the first terminal device knows, by a first instruction in the first DCI, that there is a second transmission after the PDSCH transmission, for example in the next slot. Thus, the PDSCH processing delay in this case may differ from the normal NR PDSCH processing delay.

[0263] In one implementation, the transmission of the first PUCCH may begin no earlier than a first processing time after the end of the time unit of the PDCCH carrying the first DCI, or no earlier than a second processing time after the end of the time unit of the PDCCH carrying the first DCI. The second processing time may be equal to the first processing time plus a time offset, which may be predefined or configured through RRC signaling. That is, the first processing time may correspond to a Tproc for the eMBB. Furthermore, in one example, the end of the time unit of the PDCCH carrying the first DCI may correspond to a reference time for the start of PDSCH processing for the eMBB. In another example, the end of the time unit of the PDCCH carrying the first DCI plus the time offset may correspond to a reference time for the start of PDSCH processing for the eMBB, and therefore, the transmission of the first PUCCH may not begin no earlier than the second processing time after the end of the time unit of the PDCCH carrying the first DCI. The time unit may be, for example, a symbol. The transmission of the first PUCCH then begins no earlier than in symbol L1 (as in TS 38.214 V17.2.0, except that joint coding is considered). After the completion of the time unit of the PDCCH carrying the first DCI, decoding of the third data can be performed. The first processing time may correspond to the first processing capacity of the first terminal device for processing the third data. The first processing time (or first processing capacity) may be reported to the network device by the first terminal device or may be predefined. Since time for processing the third data is considered, the first terminal device can provide valid HARQ ACK / NACK information in the first PUCCH.

[0264] In another implementation, the transmission of the first PUCCH may begin no earlier than a third processing time after the end of the PDSCH time unit scheduled by the second DCI. In one example of this implementation, the end of the PDSCH time unit scheduled by the second DCI plus a time offset may correspond to the reference time for the start of PDSCH processing for the eMBB. Different time offsets may be provided for different situations. For example, time offset 1 may be used for normal joint coding situations, time offset 2 for intra-UE joint coding situations, and time offset 3 for inter-UE joint coding situations. In inter-UE joint coding situations, the end of the PDSCH time unit scheduled by the second DCI plus time offset 3 may correspond to the reference time for the start of PDSCH processing for the eMBB, and therefore, the transmission of the first PUCCH will not begin no earlier than a third processing time after the end of the PDSCH time unit scheduled by the second DCI. The time unit may be, for example, a symbol. Next, the transmission of the first PUCCH begins no 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 PDSCH scheduled by the second DCI, decoding of the third data may be performed, provided that joint coding between different terminal devices is considered. Here, the third processing time may correspond to the third processing capacity of the first terminal device for processing the third data in the context of joint coding between different terminal devices. The third processing time (or third processing capacity) may be reported to the network device by the first terminal device or may be predefined. Since time for processing the third data is considered, the first terminal device can provide valid HARQ ACK / NACK information in the first PUCCH.

[0265] In a further implementation, depending on the coding scheme, there may be multiple types of processing times, for example, the processing time (Tproc_0) for non-union coding, the processing time (Tproc_1) for union coding in the terminal device, the processing time (Tproc_2) for union coding between different terminal devices, etc.

[0266] Figures 18a and 18b show schematic diagrams of examples of PDSCH processing for the union coding of FIG. 13. In these examples, for the UE-to-UE union coding, the PDSCH processing for the eMBB terminal device is considered.

[0267] In one implementation, as shown in FIG. 18a, the reference time for the start of PDSCH processing is at the end of the mixed traffic indication (the first DCI), or the end of the mixed traffic indication (the first DCI) with an offset added, and the offset is predefined or configured. The first DCI indicates that UE-to-UE union coding occurs in the previous time slot(s). The first uplink symbol of the PUCCH, which carries HARQ-ACK information and the PUCCH resources to be used and includes the effect of timing advance, does not start earlier than symbol L1, where L1 is defined as the next uplink symbol whose CP starts after Tproc (for example, the first processing time) after the reference time. In this case, the UE is assumed to provide a valid HARQ-ACK message. Tproc is the PDSCH processing time.

[0268] In another embodiment, as shown in Figure 18b, the reference time for initiating PDSCH processing is an offset added to the end of the PDSCH symbol carrying the received eMBB TB, where the offset is predefined or configured by the network device. There are multiple offsets for congruent coding. For example, offset 1 (time offset 1 above) is for when the URLLC data and the entire eMBB data are congruently encoded (i.e., normal congruent coding). Offset 2 (time offset 2 above) is for in-UE congruent coding. In some implementations of in-UE congruent coding, partial eMBB data is transmitted, the original eMBB transmission is stopped, and a subsequent congruent codeword of URLLC data and the partial eMBB data (not transmitted in the original transmission) is transmitted, so that the first terminal device must combine the two transmissions to decode the eMBB data. Offset 3 (the above time offset 3) is for inter-UE mixed traffic coordination, and the occurrence of inter-UE joint coding is indicated after the eMBB PDSCH transmission, for example by the first DCI in the next slot. The UE shall provide a valid HARQ-ACK message if the first uplink symbol of the PUCCH, carrying HARQ-ACK information and the PUCCH resources to be used, including the effect of timing advance, does not start earlier than symbol L1, where L1 is defined as the next uplink symbol whose CP starts after a Tproc after a reference time. Tproc is the PDSCH processing time. Optionally, depending on the coding scheme, there are multiple types of processing times. For example, Tproc-0 is for non-joint coding, Tproc-1 is for intra-UE joint coding, and Tproc-2 is for inter-UE joint coding.

[0269] The accuracy and reliability of HARQ ACK / NACK feedback can be guaranteed by taking into account the combined coding type and the combined decoding complexity to define the reference time for PDSCH processing for data.

[0270] In the wireless communication method provided by the present disclosure, first, since the combined coding is enabled in the first resource, the reliability of the data transmitted on the first resource can be improved. Further, the first data for the first terminal device and the second data for the second terminal device can be combined-coded on the first resource. After receiving the first instruction, the first terminal device can determine that the resource first scheduled for the first terminal device is used for the combined coding of the first data for the first terminal device and the second data for the second terminal device. In this way, not only can the latency and reliability requirements of the second data for the second terminal device be improved, but the performance of the first terminal device can also be guaranteed.

[0271] Next, in combination with FIG. 19, the wireless communication method of the present disclosure will be described from the perspective of a second terminal device (for example, a URLLC terminal device). FIG. 19 shows a schematic flowchart of still another wireless communication method according to one or more embodiments of the present disclosure. The method can be implemented by the second terminal device. As shown in FIG. 19, the method can include the following steps.

[0272] S1901 The second terminal device receives a third DCI from the network device, and the third DCI indicates the combined coding on the first resource.

[0273] S1902 The second terminal device receives a first coded word and performs decoding on the received first coded word according to the third DCI, where the first data for the first terminal device and the second data for the second terminal device are combined-coded in the first coded word.

[0274] S1903 The second terminal device discards the first data.

[0275] For S1901 to S1903, refer to the description in the above-described embodiment of the method. The technical principles and technical effects are the same and will not be repeated here. It will be understood that the scheduling scheme of the third DCI for the first codeword may be the same as the scheduling scheme of the first DCI for the first codeword described above, with respect to instructions such as resource information, decode information, feedback scheme, feedback timing information, and resource information.

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

[0277] Figure 20 shows a schematic diagram of the structure of a wireless communication device according to one or more embodiments of the present disclosure. As shown in Figure 20, the wireless communication device 2000 may include the following: A receiving module 2002 is configured to receive a first instruction from a network device. The first instruction indicates a joint coding on a first resource.

[0278] In one possible implementation, the joint coding on the first resource is the joint coding of first data for a first terminal device including the device and second data for a second terminal device.

[0279] In one possible implementation, first data from a first terminal device and second data from a second terminal device are congruently coded into a first codeword, the first codeword comprising a plurality of encoded blocks generated by encoding the first data and the second data with error-correcting codes, the plurality of encoded blocks comprising a self-decodeable encoded block corresponding to the second data, the self-decodeable encoded block being decodeable independently of the other encoded blocks of the plurality of encoded blocks of the first codeword, and the self-decodeable encoded block being further decodeable congruently with one or more of the other encoded blocks of the plurality of encoded blocks of the first codeword.

[0280] In one possible implementation, the first instruction is carried in first Downlink Control Information (DCI), which indicates at least one of the coding rate of the first data, the coding rate of the second data, resource information of the second data, and the code block index of the first data.

[0281] In one possible implementation, the first DCI indicates the first resource in the reference resource area by at least one of the following: an M × N time-frequency bitmap corresponding to the reference resource area (where M and N are integers greater than 0), an index in a resource allocation table corresponding to the reference resource area, or the resource location of the first resource in the reference resource area, the reference resource area is configured or predefined through radio resource control (RRC) signaling.

[0282] In one possible implementation, the device 2000 further includes a processing module configured to buffer data received in the reference resource area.

[0283] In one possible implementation, a first radio network temporary identifier (RNTI) is used to scramble the physical downlink shared channel (PDSCH) for the first and second data.

[0284] In one possible implementation, the first RNTI is different from the cell-radio network temporary identifier (C-RNTI) of the first terminal device, and the first RNTI is different from the C-RNTI of the second terminal device.

[0285] In one possible implementation, the first RNTI is either represented by the first DCI or configured through RRC signaling.

[0286] In one possible implementation, the receiving module 2002 is further configured to receive a second DCI from a network device, the second DCI is used to schedule a third data, the third data containing the first data.

[0287] In one possible implementation, feedback to the third data is performed by the first terminal device based on HARQ-related information contained in the second DCI, and the HARQ-related information includes feedback resource information and feedback timing information for the third data.

[0288] In one possible implementation, the device 2000 further includes a processing module configured to determine that a second resource scheduled by a second DCI for third data overlaps with at least a portion of the first resource; and that data scheduled by a second DCI on the second resource is not transmitted by a network device.

[0289] In one possible implementation, the apparatus 2000 further includes a transmission module configured to transmit a first physical uplink control channel (PUCCH) carrying the result of PDSCH processing for the third data to the network device.

[0290] In one possible implementation, the transmission of the first PUCCH does not start earlier than after a first processing time from the end of the time unit of the physical downlink control channel (PDCCH) carrying the first DCI, or does not start earlier than after a second processing time from the end of the time unit of the PDCCH carrying the first DCI, where the second processing time is equal to the first processing time plus a time offset.

[0291] In one possible implementation, the transmission of the first PUCCH does not start earlier than after a third processing time from the end of the time unit of the PDSCH scheduled by the second DCI.

[0292] In one possible implementation, the first processing time and / or the third processing time are predefined or reported by the first terminal device to the network device.

[0293] In one possible implementation, the second data has a payload size smaller than that of the third data.

[0294] The wireless communication device may be applied to the first terminal device as described in the above method embodiments, or may be the first terminal device as described in the above method embodiments. Those skilled in the art should understand that the related descriptions of the above modules in the embodiments of the present disclosure can be understood by referring to the related descriptions of the wireless communication method in the embodiments of the present disclosure.

[0295] FIG. 21 shows a schematic structural diagram of another wireless communication device according to one or more embodiments of the present disclosure. As shown in FIG. 21, the wireless communication device 2100 may include the following. A transmitting module 2102 is configured to send a first instruction to a first terminal device. The first instruction indicates a joint coding on a first resource.

[0296] In one possible implementation, the congruent coding on the first resource is the congruent coding for the first data for the first terminal device and the second data for the second terminal device.

[0297] In one possible implementation, first data from a first terminal device and second data from a second terminal device are congruently coded into a first codeword, which comprises a plurality of encoded blocks generated by encoding the first data and the second data with error-correcting codes, the plurality of encoded blocks comprising a self-decodeable encoded block corresponding to the second data, the self-decodeable encoded block being decodeable independently of the other encoded blocks of the plurality of encoded blocks of the first codeword, and the self-decodeable encoded block being decodeable congruently with one or more of the other encoded blocks of the plurality of encoded blocks of the first codeword.

[0298] In one possible implementation, the first instruction is carried in first downlink control information (DCI), the first DCI indicating at least one of the coding rate of the first data, the coding rate of the second data, resource information of the second data, and the code block index of the first data.

[0299] In one possible implementation, the first DCI identifies the first resource in the reference resource area by at least one of the following: an M × N time-frequency bitmap corresponding to the reference resource area (where M and N are integers greater than 0), an index in a resource allocation table corresponding to the reference resource area, or the resource location of the first resource in the reference resource area, the reference resource area being configured or predefined through radio resource control (RRC) signaling.

[0300] In one possible implementation, a first radio network temporary identifier (RNTI) is used to scramble the physical downlink shared channel (PDSCH) for the first and second data.

[0301] In one possible implementation, the first RNTI is different from the cell-radio network temporary identifier (C-RNTI) of the first terminal device, and the first RNTI is different from the C-RNTI of the second terminal device.

[0302] In one possible implementation, the first RNTI is either shown in the first DCI or configured through RRC signaling.

[0303] In one possible implementation, the transmitting module 2102 is further configured to transmit a second DCI to a first terminal device, the second DCI is used to schedule a third data, the third data including the first data.

[0304] In one possible implementation, the device 2100 further includes a receiving module configured to receive feedback for a third data executed by a first terminal device based on HARQ-related information contained in a second DCI, the HARQ-related information including feedback resource information and feedback timing information for the third data.

[0305] In one possible implementation, the device 2100 further includes a receiving module configured to receive a first physical uplink control channel (PUCCH) that carries the results of PDSCH processing for third data.

[0306] In one possible implementation, the transmission of the first PUCCH by the first terminal device does not begin earlier than a first processing time from the end of the time unit of the physical downlink control channel (PDCCH) carrying the first DCI, or earlier than a second processing time from the end of the time unit of the PDCCH carrying the first DCI, where the second processing time is equal to the first processing time plus a time offset.

[0307] In one possible implementation, the transmission of the first PUCCH by the first terminal device does not begin earlier than a third processing time from the end of the time unit of the PDSCH scheduled by the first DCI.

[0308] In one possible implementation, the first processing time and / or the third processing time are either predefined or reported to the network device by the first terminal device.

[0309] In one possible implementation, the second data set has a smaller payload size than the third data set.

[0310] The wireless communication device may be applied to a network device as described in the above method embodiment, or it may be a network device as described in the above method embodiment. Those skilled in the art should understand that the relevant description of the module in the embodiments of the disclosure can be understood by referring to the relevant description of the wireless communication method in the embodiments of the disclosure.

[0311] One embodiment of this disclosure provides a terminal device including a processing circuit for performing one of the above-described wireless communication methods. The terminal device may perform steps performed by the first or second terminal device in the above-described method embodiment, which will not be repeated here.

[0312] One embodiment of the present invention provides a network device including a processing circuit for performing any of the above-described wireless communication methods. The network device may perform steps performed by the network device in the above-described method embodiments, which will not be repeated here.

[0313] One embodiment of the present invention provides a wireless communication device including a processor and memory. The memory stores instructions that cause the processor to execute one of the above-described wireless communication methods.

[0314] One embodiment of the present disclosure provides a wireless communication system including a network device, a first terminal device, and a second terminal device. The first terminal device is configured to perform steps performed by the first terminal device in any of the above wireless communication methods, the second terminal device is configured to perform steps performed by the second terminal device in any of the above wireless communication methods, and the network device is configured to perform steps performed by the network device in any of the above wireless communication methods.

[0315] One embodiment of the present disclosure provides a computer-readable medium for storing computer execution instructions, which, when executed by a processor, cause the processor to perform one of the wireless communication methods described above.

[0316] One embodiment of the present invention provides a computer program product including a computer execution instruction, which, when executed by a processor, causes the processor to perform one of the above-described wireless communication methods.

[0317] This disclosure describes methods and processes having steps in a certain order, but one or more steps of the methods and processes may be omitted or modified as appropriate. One or more steps may be performed in an order other than the order in which they are described, as appropriate.

[0318] It should be noted 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 one can select either A or B, or both A and B. Similarly, the expression "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". This refers to a list in which one can select either 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 to longer lists having the same format.

[0319] While this disclosure describes methods at least in part, those skilled in the art will understand that this disclosure is also directed toward various components for performing at least some of the aspects and features of the methods described, whether by hardware components, software, or any combination of the two. Thus, the technical solutions of the present invention may be embodied in the form of software products. A suitable software product may be stored on a pre-recorded storage device or other similar non-volatile or non-temporary computer-readable medium, including, for example, a DVD, CD-ROM, USB flash disk, removable hard disk, or other storage medium. The software product includes instructions tangibly stored thereon that enable a processing device (e.g., a personal computer, server, or network device) to perform an example of the method disclosed herein. Machine-executable instructions may be in the form of code sequences, configuration information, or other data that, when executed, cause a machine (e.g., a processor or other processing device) to perform a step in the method according to the example of the present disclosure.

[0320] This disclosure may be embodied in other specific forms without departing from the subject matter of the claims. The exemplary embodiments described should be considered in all respects to be illustrative and not restrictive. Selected features from one or more of the embodiments described above may be combined to create alternative embodiments not expressly described, and features suitable for such combinations will be understood within the scope of this disclosure.

[0321] All values ​​and sub-ranges within the disclosed scope are also disclosed. Furthermore, while the systems, devices, and processes disclosed and shown herein may include a certain number of elements / components, the systems, devices, and assemblies may be modified to include additional or fewer such elements / components. For example, any of the disclosed elements / components may be referred to as singular, but embodiments disclosed herein may be modified to include multiple such elements / components. The subject matter described herein is intended to encompass and include all appropriate modifications in the art.

[0322] While embodiments have been described above with reference to the accompanying drawings, those skilled in the art will understand that modifications and alterations can be made without departing from the scope defined by the accompanying claims.

Claims

1. A wireless communication method: The first terminal device receives a first instruction from a network device, the first instruction indicating joint coding on a first resource, the steps include: method.

2. The method according to claim 1, wherein the joint coding in the first resource is joint coding for first data for the first terminal device and for second data for the second terminal device.

3. The first data of the first terminal device and the second data of the second terminal device are jointly coded into a first codeword. The first codeword comprises a plurality of encoded blocks generated by encoding the first data and the second data with an error-correcting code, the plurality of encoded blocks comprising a self-decodeable encoded block corresponding to the second data, the self-decodeable encoded block being decodeable independently of the other encoded blocks of the plurality of encoded blocks of the first codeword, and the self-decodeable encoded block being decodeable jointly with one or more of the other encoded blocks of the plurality of encoded blocks of the first codeword. The method according to claim 2.

4. The first instruction is conveyed in the first downlink control information (DCI), The method according to claim 2 or 3, wherein the first DCI represents at least one of the coding rate of the first data, the coding rate of the second data, resource information of the second data, and the code block index of the first data.

5. The first DCI refers to the first resource in the reference resource area, A bitmap M × N time-frequency bitmap corresponding to the aforementioned reference resource area, wherein M and N are integers greater than 0; The index in the resource allocation table corresponding to the aforementioned reference resource area; The resource location of the first resource in the reference resource area, This is demonstrated by at least one of the following: The aforementioned reference resource area is configured through radio resource control (RRC) signaling or is predefined. The method according to claim 4.

6. The first terminal device further includes the step of buffering the data received in the reference resource area, The method according to claim 5.

7. The method according to any one of claims 4 to 6, wherein a first radio network temporary identifier (RNTI) is used to scramble a physical downlink sharing channel (PDSCH) for the first data and the second data.

8. The method according to claim 7, wherein the first RNTI is different from the Cell Radio Network Temporary Identifier (C-RNTI) of the first terminal device, and the first RNTI is different from the C-RNTI of the second terminal device.

9. The method according to claim 7 or 8, wherein the first RNTI is indicated in the first DCI or is configured through RRC signaling.

10. The first terminal device receives a second DCI from the network device, the second DCI being used to schedule third data, the third data including the first data, further comprising the steps of: The method according to any one of claims 4 to 9.

11. The method according to claim 10, wherein feedback to the third data is performed by the first terminal device based on HARQ-related information included in the second DCI, and the HARQ-related information includes feedback resource information and feedback timing information for the third data.

12. After the first terminal device receives the first instruction from the network device, the method: The first terminal device determines that the second resource scheduled by the second DCI for the third data overlaps with at least a portion of the first resource; The first terminal device determines that the data scheduled by the second DCI on the second resource is not transmitted by the network device. The method according to claim 10 or 11, further comprising:

13. The first terminal device further includes transmitting a first physical uplink control channel (PUCCH) to the network device, which carries the results of the PDSCH processing for the third data. The method according to any one of claims 10 to 12.

14. The method according to claim 13, wherein the start of transmission of the first PUCCH is no earlier than a first processing time after the end of the time unit of the physical downlink control channel (PDCCH) carrying the first DCI, or no earlier than a second processing time after the end of the time unit of the PDCCH carrying the first DCI, the second processing time being equal to the first processing time plus a time offset.

15. The method according to claim 13, wherein the start of the transmission of the first PUCCH is not earlier than the end of the time unit of the PDSCH scheduled by the second DCI after a third processing time.

16. The method according to claim 14 or 15, wherein the first processing time and / or the third processing time are predefined or reported to the network device by the first terminal device.

17. The method according to any one of claims 10 to 16, wherein the second data has a smaller payload size than the third data.

18. A wireless communication method: A network device transmits a first instruction to a first terminal device, the first instruction indicating joint coding on a first resource, the step of method.

19. The method according to claim 18, wherein the joint coding in the first resource is joint coding for first data for the first terminal device and for second data for the second terminal device.

20. The first data of the first terminal device and the second data of the second terminal device are jointly coded into a first codeword. The first codeword comprises a plurality of encoded blocks generated by encoding the first data and the second data with an error-correcting code, the plurality of encoded blocks comprising a self-decodeable encoded block corresponding to the second data, the self-decodeable encoded block being decodeable independently of the other encoded blocks of the plurality of encoded blocks of the first codeword, and the self-decodeable encoded block being decodeable jointly with one or more of the other encoded blocks of the plurality of encoded blocks of the first codeword. The method according to claim 19.

21. The first instruction is conveyed in the first downlink control information (DCI), The first DCI indicates at least one of the coding rate of the first data, the coding rate of the second data, resource information of the second data, and the code block index of the first data. The method according to claim 19 or 20.

22. The first DCI refers to the first resource in the reference resource area, A bitmap M × N time-frequency bitmap corresponding to the aforementioned reference resource area, wherein M and N are integers greater than 0; The index in the resource allocation table corresponding to the aforementioned reference resource area; Resource location of the first resource in the reference resource area This is demonstrated by at least one of the following: The aforementioned reference resource area is configured or predefined through radio resource control (RRC) signaling. The method according to claim 21.

23. The method according to claim 21 or 22, wherein a first radio network temporary identifier (RNTI) is used to scramble a physical downlink sharing channel (PDSCH) for the first data and the second data.

24. The method according to claim 23, wherein the first RNTI is different from the Cell Radio Network Temporary Identifier (C-RNTI) of the first terminal device, and the first RNTI is different from the C-RNTI of the second terminal device.

25. The method according to claim 23 or 24, wherein the first RNTI is shown in the first DCI or is configured through RRC signaling.

26. The step of transmitting a second DCI to the first terminal device via the network device, the second DCI being used to schedule third data, the third data including the first data, further comprising: The method according to any one of claims 21 to 25.

27. The method according to claim 26, further comprising the step of receiving feedback from the network device to the third data performed by the first terminal device based on HARQ-related information included in the second DCI, wherein the HARQ-related information includes feedback resource information and feedback timing information for the third data.

28. The network device further includes receiving a first physical uplink control channel (PUCCH) from the first terminal device that carries the results of PDSCH processing for the third data, The method according to claim 26 or 27.

29. The method according to claim 28, wherein the first terminal device starts transmitting the first PUCCH no earlier than a first processing time after the end of a time unit of the physical downlink control channel (PDCCH) carrying the first DCI, or no earlier than a second processing time after the end of a time unit of the PDCCH carrying the first DCI, the second processing time being equal to the first processing time plus a time offset.

30. The method according to claim 29, wherein the start of the transmission of the first PUCCH by the first terminal device is no earlier than the end of the time unit of the PDSCH scheduled by the first DCI after a third processing time.

31. The method according to claim 29 or 30, wherein the first processing time and / or the third processing time are predefined or reported to the network device by the first terminal device.

32. The method according to any one of claims 26 to 31, wherein the second data has a smaller payload size than the third data.

33. A wireless communication device: A receiving module configured to receive a first instruction from a network device, wherein the first instruction indicates joint coding in a first resource, the receiving module comprises Device.

34. The apparatus according to claim 33, wherein the joint coding in the first resource is joint coding for first data for a first terminal device containing the apparatus and for second data for a second terminal device.

35. The first data of the first terminal device and the second data of the second terminal device are jointly coded into a first codeword. The first codeword comprises a plurality of encoded blocks generated by encoding the first data and the second data with an error-correcting code, the plurality of encoded blocks comprising a self-decodeable encoded block corresponding to the second data, the self-decodeable encoded block being decodeable independently of the other encoded blocks of the plurality of encoded blocks of the first codeword, and the self-decodeable encoded block being decodeable jointly with one or more of the other encoded blocks of the plurality of encoded blocks of the first codeword. The apparatus according to claim 34.

36. The first instruction is conveyed in the first downlink control information (DCI), The apparatus according to claim 34 or 35, wherein the first DCI represents at least one of the coding rate of the first data, the coding rate of the second data, resource information of the second data, and the code block index of the first data.

37. The first DCI refers to the first resource in the reference resource area, A bitmap M × N time-frequency bitmap corresponding to the aforementioned reference resource area, wherein M and N are integers greater than 0; The index in the resource allocation table corresponding to the aforementioned reference resource area; The resource location of the first resource in the reference resource area, This is demonstrated by at least one of the following: The aforementioned reference resource area is configured through radio resource control (RRC) signaling or is predefined. The apparatus according to claim 36.

38. The system further includes a processing module configured to buffer data received in the aforementioned reference resource area. The apparatus according to claim 37.

39. The apparatus according to any one of claims 36 to 38, wherein a first radio network temporary identifier (RNTI) is used to scramble a physical downlink sharing channel (PDSCH) for the first data and the second data.

40. The apparatus according to claim 39, wherein the first RNTI is different from the cell radio network temporary identifier (C-RNTI) of the first terminal device, and the first RNTI is different from the C-RNTI of the second terminal device.

41. The apparatus according to claim 39 or 40, wherein the first RNTI is indicated in the first DCI or is configured through RRC signaling.

42. The receiving module is further configured to receive a second DCI from the network device, the second DCI being used to schedule a third data, the third data including the first data. The apparatus according to any one of claims 36 to 41.

43. The apparatus according to claim 42, wherein feedback to the third data is performed by the first terminal device based on HARQ-related information included in the second DCI, and the HARQ-related information includes feedback resource information and feedback timing information for the third data.

44. It is determined that the second resource scheduled by the second DCI for the third data overlaps with at least a portion of the first resource; It is determined that the data scheduled by the second DCI on the second resource is not transmitted by the network device. The apparatus according to claim 42 or 43, further comprising a processing module configured as such.

45. The system further comprises a transmitting module configured to transmit a first physical uplink control channel (PUCCH) to the network device, which carries the results of PDSCH processing on the third data. The apparatus according to any one of claims 42 to 44.

46. The apparatus according to claim 45, wherein the start of transmission of the first PUCCH is no earlier than a first processing time after the end of the time unit of the physical downlink control channel (PDCCH) carrying the first DCI, or no earlier than a second processing time after the end of the time unit of the PDCCH carrying the first DCI, the second processing time being equal to the first processing time plus a time offset.

47. The apparatus according to claim 45, wherein the start of the transmission of the first PUCCH is not earlier than the end of the time unit of the PDSCH scheduled by the second DCI after a third processing time.

48. The apparatus according to claim 46 or 47, wherein the first processing time and / or the third processing time are predefined or reported to the network device by the first terminal device.

49. The apparatus according to any one of claims 42 to 48, wherein the second data has a smaller payload size than the third data.

50. A wireless communication device: A transmission module configured to transmit a first instruction to a first terminal device, wherein the first instruction indicates joint coding in a first resource, the transmission module comprises Device.

51. The apparatus according to claim 50, wherein the joint coding in the first resource is joint coding for first data for the first terminal device and for second data for the second terminal device.

52. The first data of the first terminal device and the second data of the second terminal device are jointly coded into a first codeword. The first codeword comprises a plurality of encoded blocks generated by encoding the first data and the second data with an error-correcting code, the plurality of encoded blocks comprising a self-decodeable encoded block corresponding to the second data, the self-decodeable encoded block being decodeable independently of the other encoded blocks of the plurality of encoded blocks of the first codeword, and the self-decodeable encoded block being decodeable jointly with one or more of the other encoded blocks of the plurality of encoded blocks of the first codeword. The apparatus according to claim 51.

53. The first instruction is conveyed in the first downlink control information (DCI), The first DCI indicates at least one of the coding rate of the first data, the coding rate of the second data, resource information of the second data, and the code block index of the first data. The apparatus according to claim 51 or 52.

54. The first DCI refers to the first resource in the reference resource area, A bitmap M × N time-frequency bitmap corresponding to the aforementioned reference resource area, wherein M and N are integers greater than 0; The index in the resource allocation table corresponding to the aforementioned reference resource area; Resource location of the first resource in the reference resource area This is demonstrated by at least one of the following: The aforementioned reference resource area is configured or predefined through radio resource control (RRC) signaling. The apparatus according to claim 53.

55. The apparatus according to claim 53 or 54, wherein a first radio network temporary identifier (RNTI) is used to scramble a physical downlink sharing channel (PDSCH) for the first data and the second data.

56. The apparatus according to claim 55, wherein the first RNTI is different from the cell radio network temporary identifier (C-RNTI) of the first terminal device, and the first RNTI is different from the C-RNTI of the second terminal device.

57. The apparatus according to claim 55 or 56, wherein the first RNTI is indicated in the first DCI or is configured through RRC signaling.

58. The transmission module is further configured to transmit a second DCI to the first terminal device, the second DCI being used to schedule a third data, the third data including the first data. The apparatus according to claim 55 or 56.

59. The apparatus according to claim 58, further comprising a receiving module configured to receive feedback to the third data executed by the first terminal device based on HARQ-related information contained in the second DCI, wherein the HARQ-related information includes feedback resource information and feedback timing information for the third data.

60. The system further includes a receiving module configured to receive a first physical uplink control channel (PUCCH) that carries the results of PDSCH processing for the third data, The apparatus according to claim 58 or 59.

61. The apparatus according to claim 60, wherein the first terminal device starts transmitting the first PUCCH no earlier than a first processing time after the end of a time unit of the physical downlink control channel (PDCCH) carrying the first DCI, or no earlier than a second processing time after the end of a time unit of the PDCCH carrying the first DCI, the second processing time being equal to the first processing time plus a time offset.

62. The apparatus according to claim 61, wherein the start of the transmission of the first PUCCH by the first terminal device is no earlier than the end of the time unit of the PDSCH scheduled by the first DCI after a third processing time.

63. The apparatus according to claim 61 or 62, wherein the first processing time and / or the third processing time are predefined or reported to the network device by the first terminal device.

64. The apparatus according to any one of claims 58 to 63, wherein the second data has a smaller payload size than the third data.

65. A first terminal device comprising a processing circuit for performing the method according to any one of claims 1 to 17.

66. A network device comprising a processing circuit for performing the method according to any one of claims 18 to 32.

67. A wireless communication system comprising a first terminal device according to claim 65 and a network device according to claim 66.

68. A computer-readable medium storing computer execution instructions that, when executed by a processor, cause the processor to perform the method according to any one of claims 1 to 17 or the method according to any one of claims 18 to 32.

69. A computer program product comprising a computer execution instruction, when executed by a processor, causing the processor to perform the method according to any one of claims 1 to 17 or the method according to any one of claims 18 to 32.

Images