Method, system and apparatus for multiplex transmissions of different transmission types

Abstract

Methods and apparatus for preemptive coding are described. A second data set belonging to a second preemptive transmission type is received during a scheduled transmission of the first data set belonging to the first existing transmission type to the intended receiving node. At least one bit of the first data set and at least one bit of the second data set are multiplexed to generate at least one multiplexed code block comprising information from the first and second data sets. And sending the multiplexing code block to one or more expected receivers.

Description

Technical Field

[0001] This application relates to methods and apparatuses for wireless communication for different transmission types, particularly wireless communication in which a preemptive transmission type preempts the transmission of an existing transmission type. Background Art

[0002] Wireless communication can involve different transmission types, which may have different requirements. Ultra-reliable low latency communication (URLLC), enhanced mobile broadband (eMBB), and massive machine type communication (mMTC) are transmission types defined for 5G wireless communication, and these transmission types have different requirements for latency, reliability, connectivity, etc. For example, URLLC is expected to be used for critical transmissions with strict requirements for latency and reliability (e.g., in autonomous driving applications, emergency services, etc.).

[0003] In some examples, it may be desirable to allow one transmission type (e.g., a high-priority transmission type, such as a URLLC transmission) to preempt another transmission type (e.g., a low-priority transmission type, such as an eMBB transmission). However, such preemption may cause a significant reduction in the performance of the preempted transmission type.

[0004] Therefore, it would be useful to provide techniques that enable different transmission types to coexist, which can avoid or reduce the performance degradation caused by preemption. Summary of the Invention

[0005] In various examples, this application describes methods and apparatuses for wireless communication using multiplexed transmission (also referred to as multiplexed traffic). Specifically, in multiplexed transmission, an existing (i.e., currently scheduled or currently ongoing) transmission type (e.g., eMBB) is multiplexed with a preemptive transmission type (e.g., URLLC or mMTC). The technical advantage of this is that the existing data may not be severely affected by the preemptive transmission, thus helping to avoid or reduce the need for retransmission of the existing data.

[0006] In addition, the examples of this application enable the preemptive transmission type to be sent with low latency, which may be very important for some transmission types with strict latency requirements. Similarly, in some examples, the coding gain of the preemptive data may be increased due to the increased code length when multiplexing with the existing data.

[0007] In an example aspect, the present application describes a method performed in a transmitting node, the method comprising: obtaining a second data set belonging to a second (e.g., preemptive) transmission type to be transmitted to the same or a different intended receiving node during or before scheduling transmission of a first data set belonging to a first (e.g., existing) transmission type to an intended receiving node; multiplexing at least one bit of the first data set and at least one bit of the second data set to generate at least one multiplexed code block comprising information from both the first and second data sets; outputting (e.g., transmitting) the at least one multiplexed code block.

[0008] In an example of the above example aspect of the method, the first and second data sets may be transmitted to the same intended receiving node, and multiplexing at least one bit of the first data set and at least one bit of the second data set may comprise: jointly encoding at least one bit of the first data set and at least one bit of the second data set into a jointly encoded codeword.

[0009] In an example of the above example aspect of the method, the first and second data sets may be transmitted to the same intended receiving node, and multiplexing at least one bit of the first data set and at least one bit of the second data set may comprise: scrambling at least one bit of the first data set using a bit mask generated from at least one bit of the second data set.

[0010] In an example of the above example aspect of the method, the first and second data sets may be transmitted to the same intended receiving node, and multiplexing at least one bit of the first data set and at least one bit of the second data set may comprise: interleaving at least one bit of the first data set using a permutation sequence generated from at least one bit of the second data set.

[0011] In an example of any of the above example aspects of the method, there may be multiple multiplexed code blocks, and one or more bits of the second data set may be multiplexed in each of the multiple multiplexed code blocks.

[0012] In an example of the above example aspect of the method, the first and second data sets may be transmitted to different intended receiving nodes, and multiplexing at least one bit of the first data set and at least one bit of the second data set may comprise: performing multilevel coding between at least one bit of the first data set and at least one bit of the second data set to obtain multilevel coded symbols; and the multiplexed code block comprising the multilevel coded symbols may be transmitted to the different intended receiving nodes.

[0013] In an example of the foregoing example aspect of the method, performing multi-level coding may include: mapping the at least one bit of the first data set and the at least one bit of the second data set to respective different levels; for each level, encoding one or more bits carried on the level into a respective codeword; jointly mapping at least one code bit selected from each codeword to the multi-level coding symbol.

[0014] In an example of the foregoing example aspect of the method, the first and second data sets may be sent to different intended receiving nodes, and multiplexing the at least one bit of the first data set and the at least one bit of the second data set may include: performing mask repetition coding between the at least one bit of the first data set and the at least one bit of the second data set to obtain a mask repetition coding symbol; and sending the multiplexed code block including the mask repetition coding symbol to the different intended receiving nodes.

[0015] In an example of the foregoing example aspect of the method, performing mask repetition coding may include: generating a first codeword from the at least one bit of the first data set, generating two or more copies of the first codeword; generating a second codeword from the at least one bit of the second data set; masking the second codeword onto at least one copy of the first codeword, and the mask repetition coding symbol is generated from the at least one masked copy.

[0016] In an example of any of the foregoing example aspects of the method, the method may include: resuming the scheduled transmission of the first data set after all bits of the second data set have been sent.

[0017] In an example of any of the foregoing example aspects of the method, the method may include: sending control information to at least one intended receiving node, the control information including information for decoding the at least one multiplexed code block.

[0018] In an example of the foregoing example aspect of the method, an updated transport block size may be calculated for the multiplexed code block, and the updated transport block size is included in the sent control information.

[0019] In an example of any of the foregoing example aspects of the method, the method may include: mapping symbols of the at least one multiplexed code block to non-contiguous resource units; and after the mapping, sending the at least one multiplexed code block.

[0020] In an example of any of the above-described aspects of the method, the first data set belonging to the first existing transmission type may be enhanced mobile broadband (eMBB) data, and the second data set belonging to the second pre-emptive transmission type may be high-priority small-packet data.

[0021] In an example of the above-described aspect of the method, the high-priority small-packet data may be ultra-reliable low latency communication (URLLC) data or massive machine type communication (mMTC) data.

[0022] In another example aspect, the present application describes a method performed in a receiving node, the method comprising: receiving at least one multiplexed code block generated by multiplexing at least one bit of a first data set and at least one bit of a second data set to include information from the first and second data sets, the first data set belonging to a first transmission type and scheduled for the receiving node, the second data set belonging to a second transmission type and intended for the same receiving node or a different receiving node; and at least decoding the information from the first data set.

[0023] In another example aspect, the present application describes a method performed in a receiving node, the method comprising: receiving at least one multiplexed code block generated by multiplexing at least one bit of a first data set and at least one bit of a second data set to include information from the first and second data sets, the first data set belonging to a first transmission type and scheduled for the same receiving node or a different receiving node, the second data set belonging to a second transmission type and intended for the same receiving node; and at least decoding the information from the second data set.

[0024] In another example aspect, the present application describes an apparatus comprising a processing unit for causing the apparatus to perform any of the above-described aspects of the method.

[0025] In another example aspect, the present application describes a non-transitory computer-readable medium storing machine-executable instructions, wherein when the processing unit of a device executes the instructions, the instructions cause the device to perform any of the above-described aspects of the method.

[0026] In another exemplary aspect, the present application describes a system including a sending node and a receiving node. The sending node is configured to send at least one multiplexed code block generated by multiplexing at least one bit of a first data set and at least one bit of a second data set to include information from the first and second data sets, where the first data set belongs to a first transmission type and is scheduled for an intended receiving node, and the second data set belongs to a second transmission type and is intended for the same receiving node or a different receiving node. The receiving node is configured to receive the at least one multiplexed code block and decode at least one of the information from the first data set or the information from the second data set. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] The following drawings by way of example illustrate the exemplary embodiments of the present application, where:

[0028] Figure 1 is a schematic diagram of an exemplary wireless communication system suitable for implementing the examples described herein;

[0029] Figure 2 is a block diagram of an exemplary device suitable for implementing the examples described herein;

[0030] FIG. 3 is a schematic diagram showing a conventional coexistence scheme;

[0031] Figure 4 is a schematic diagram of an example of a preemptive coding scheme using combined data coding according to an example of the present application;

[0032] Figures 5A to 5C is a schematic diagram of an example of combined data coding implemented at a sending node according to an example of the present application;

[0033] Figure 5D and Figure 5E shows an example of how combined data coding according to an example of the present application affects code blocks;

[0034] Figure 6A and Figure 6B is a schematic diagram of an example of preemptive coding using multilevel coding according to an example of the present application;

[0035] Figures 7A to 7C is a schematic diagram of an example of multilevel decoding according to an example of the present application;

[0036] Figure 8A is a schematic diagram of an example of preemptive coding based on masked repetition coding according to an example of the present application;

[0037] Figure 8B is a schematic diagram of an example of demasking and decoding according to an example of the present application;

[0038] Figure 9 is a schematic diagram of an example of a discontinuous mapping from symbols to resource units according to an example of the present application;

[0039] Figure 10 is a flowchart of an exemplary method for preemptive coding according to an example of the present application;

[0040] Figures 11A to 11C is according to an example of the present application Figure 10 flowchart of an exemplary implementation of the method of.

[0041] Similar reference numerals may be used to represent similar components in different figures. Detailed Description

[0042] To assist in understanding the present application, an exemplary wireless communication system is first described.

[0043] Figure 1 An example wireless communication system 100 (also referred to as wireless system 100) in which embodiments of the present application may be implemented is shown. Generally, wireless system 100 enables multiple wireless or wired elements to transmit data and other content. Wireless system 100 may enable content (e.g., voice, data, video, text, etc.) to be transmitted between entities of system 100 (e.g., via broadcast, narrowcast, user equipment to user equipment, etc.). Wireless system 100 may operate by sharing resources such as bandwidth. Wireless system 100 may be suitable for wireless communication using 5G technology and / or next-generation wireless technology. In some examples, wireless system 100 may also be compatible with some traditional wireless technologies (e.g., 3G or 4G wireless technologies).

[0044] In the example shown, wireless system 100 includes user equipment (UE) 110, radio access network (RAN) 120, core network 130, public switched telephone network (PSTN) 140, Internet 150, and other networks 160. In some examples, one or more of these networks may be omitted or replaced with different types of networks. Other networks may be included in wireless system 100. Although Figure 1 a certain number of these components or elements are shown, any suitable number of these components or elements may be included in wireless system 100.

[0045] The UE 110 is used for operation and / or communication in the wireless system 100. For example, the UE 110 can be used to send and / or receive messages via wireless or wired communication channels. The term "UE" can be used to represent any suitable end-user device that performs wireless operations, and can include the following devices (or can be referred to as): wireless transmit / receive unit (WTRU), mobile station, mobile relay, fixed or mobile subscriber unit, cellular phone, station (STA), machine type communication (MTC) device, personal digital assistant (PDA), smart phone, laptop computer, computer, tablet, wireless sensor, internet of things (IoT) device, network-enabled vehicle, or consumer electronic device, etc. In some examples, the term electronic device (ED) can be used instead of UE. Generally, it should be understood that using the term UE in this application does not necessarily limit this application to any specific wireless technology.

[0046] In Figure 1 the RAN 120 includes a base station (BS) 170. Although Figure 1It is shown that each RAN 120 includes a single respective BS170, but it should be understood that any given RAN 120 may include more than one BS170, and any given RAN 120 may also include one or more base station controllers (BSCs), one or more radio network controllers (RNCs), relay nodes, elements, and / or devices. Each BS170 is used to make a wireless connection with one or more of the UEs 110 so as to be able to access any other BS170, the core network 130, the PSTN 140, the Internet 150, or other networks 160. For example, the BS170 may also be referred to as (or include) a base transceiver station (BTS), a radio base station, a Node-B (NodeB), an evolved NodeB (eNodeB or eNB), a home base station, a gNodeB (gNB) (sometimes referred to as a next-generation NodeB), a transmission point (TP), a transmission and reception point (TRP), a site controller, an access point (AP), or a wireless router, etc. The next-generation BS170 may be referred to using other terms. In some examples, the term TRP may be used to include the BS170 or any other node that may be used to send and receive communications. Thus, although this application refers to the BS170, it should be understood that this is not intended to be limiting. Alternatively or additionally, any UE 110 may be used to access any other BS170, the Internet 150, the core network 130, the PSTN 140, other networks 160, or any combination of the foregoing, or to be connected or communicate therewith. In some examples, the BS170 may access the core network 130 via the Internet 150.

[0047] UE 110 and BS170 are examples of communication devices that can be used to implement some or all of the functions and / or embodiments described herein. Any BS170 can be a single element, as shown, or multiple elements, distributed in the corresponding RAN 120, etc. Each BS170 transmits and / or receives wireless signals within a particular geographical area or region (sometimes referred to as a "cell" or "coverage area"). A cell can be further divided into cell sectors. For example, a BS170 can use multiple transceivers to provide service to multiple sectors. In some embodiments, there can be established pico-cells or femto-cells supported by a wireless access technology. A macro-cell can include one or more smaller cells. The number of RANs 120 shown is merely exemplary. Any number of RANs can be considered when designing the wireless system 100.

[0048] BS170 communicates with one or more UEs 110 via one or more uplink (UL) / downlink (DL) wireless interfaces 190 (e.g., via radio frequency (RF), microwave, infrared, etc.). The UL / DL interface 190 can also be referred to as a UL / DL connection, a UE-BS link / connection / interface, a UE-network link / connection / interface, etc. The UEs 110 can also communicate directly with each other via one or more sidelink (SL) wireless interfaces 195 (i.e., without involving BS170). The SL interface 195 can also be referred to as an SL connection, a UE-to-UE link / connection / interface, a vehicle-to-vehicle (V2V) link / connection / interface, a vehicle-to-everything (V2X) link / connection / interface, a vehicle-to-infrastructure (V2I) link / connection / interface, a vehicle-to-pedestrian (V2P) link / connection / interface, a device-to-device (D2D) link / connection / interface, or simply as SL, etc. The wireless interfaces 190 and 195 can use any suitable radio access technology. For example, the wireless system 100 can implement one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), or single-carrier FDMA (SC-FDMA), for wireless communication.

[0049] The RAN 120 communicates with the core network 130 to provide various services to the UE 110, such as voice, data, and other services. The RAN 120 and / or the core network 130 may communicate directly or indirectly with one or more other RANs (not shown), which may or may not be directly served by the core network 130 and may or may not use the same radio access technology. The core network 130 may also serve as a gateway access between (i) the RAN 120 or the UE 110 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 UEs 110 may include functionality to communicate with different wireless networks via different wireless links using different wireless technologies and / or protocols. Instead of (or in addition to) wireless communication, the UE 110 may communicate with a service provider or a switch (not shown) and the Internet 150 via a wired communication channel. The PSTN 140 may include a circuit-switched telephone network for providing plain old telephone service (POTS). The Internet 150 may include computer networks and / or subnets (intranets) and includes protocols such as the Internet Protocol (IP), the Transmission Control Protocol (TCP), and the User Datagram Protocol (UDP). The UE 110 may be a multi-mode device capable of operating according to multiple radio access technologies and incorporating multiple transceivers required to support such technologies.

[0050] Figure 2 An exemplary apparatus 200 in which examples disclosed herein may be implemented is shown. Figure 2 A possible embodiment of the UE 110 or the BS 170 is shown, but is not intended to be limiting.

[0051] As Figure 2 shown, the exemplary apparatus 200 (e.g., an exemplary embodiment of the UE 110 or the BS 170) includes at least one processing unit 201. The processing unit 201 implements various processing operations of the apparatus 200. The processing unit 201 may perform signal encoding, data processing, power control, input / output processing, or any other function of the apparatus 200. The processing unit 201 may also be used to implement some or all of the functions and / or embodiments described in more detail herein. Each processing unit 201 includes any suitable processing device or computing device for performing one or more operations. Each processing unit 201 may include a microprocessor, a microcontroller, a digital signal processor, a field programmable gate array, or an application specific integrated circuit, etc.

[0052] Device 200 includes at least one communication interface 202 for wired communication and / or wireless communication. One or more communication interfaces 202 may be used in device 200. Each communication interface 202 includes any suitable structure for generating signals for wireless or wired transmission and / or for processing signals received wirelessly or wiredly. Although shown as a single functional unit, communication interface 202 may also be implemented using at least one transmitter interface and at least one separate receiver interface. In some examples, one or more transmitters and one or more receivers may be implemented by communication interface 202.

[0053] Device 200 includes one or more antennas 204 for wireless communication. Each antenna 204 includes any suitable structure for transmitting and / or receiving wireless signals. In some examples, device 200 may include multiple antennas 204 to support multiple-input multiple-output (MIMO) communication. There may be multiple antennas 204, which together form an antenna array that may be used for beamforming and beam control operations. In some examples, there may be one or more antennas 204 for transmitting signals and different one or more antennas 204 for receiving signals.

[0054] Device 200 further includes one or more input / output devices 206 or input / output interfaces (such as a wired interface connected to the Internet 150). One or more input / output devices 206 allow interaction with a user or other devices in the wireless system 100. Each input / output device 206 includes any suitable structure for providing information to the user or receiving information from the user (including network interface communication), such as a speaker, a microphone, a keypad, a keyboard, a display, or a touch screen.

[0055] In addition, device 200 includes at least one memory 208. Memory 208 stores instructions and data used, generated, or collected by device 200. For example, memory 208 may store software instructions or modules executed by one or more processing units 201 for implementing some or all of the functions and / or embodiments described herein. Each memory 208 includes any applicable one or more volatile and / or non-volatile storage and retrieval devices. Any suitable type of non-transitory memory may be used, such as random access memory (RAM), read only memory (ROM), hard disk, optical disk, subscriber identity module (SIM) card, memory stick, secure digital (SD) memory card, etc.

[0056] A wireless system (e.g., Figure 1 wireless system 100) can support different transmission types, also referred to as transmission services (or simply services). For example, ultra-reliable low latency communication (URLLC), enhanced mobile broadband (eMBB), and massive machine type communication (mMTC) are transmission types defined for 5G wireless communication, and these transmission types have different requirements for latency, reliability, connectivity, etc. Specifically, URLLC is expected to be used for high-priority transmissions, such as transmissions in critical applications like public safety, telemedicine, emergency services, autonomous driving, and industrial automation. URLLC services have strict requirements for latency and reliability (e.g., latency less than 1 ms and reliability above 99%).

[0057] In an exemplary scenario, URLLC transmissions and eMBB transmissions can coexist in DL or UL communication. For example, a transmission from BS170 to UE 110 (or vice versa) may be mainly an eMBB transmission. However, a high-priority URLLC transmission may occasionally arrive and need to be sent immediately from BS170 (e.g., with a latency less than 1 ms). In another example, UE 110 can be a cluster head of an MTC device cluster, and UE 110 may need to send mMTC transmissions on top of existing eMBB transmissions. It should be understood that these examples are not intended to be limiting. The present application can be applicable to DL, UL, or SL transmissions and can include transmissions with one or more intended recipients. Thus, the present application will refer to transmissions from a sending node (which can be BS170 for DL transmission, or UE 110 for UL or SL transmission) and the reception of the transmissions by one or more receiving nodes (which can be BS170 for UL transmission, or UE 110 for DL or SL transmission).

[0058] To enable different transmission types to communicate according to their respective latency requirements, various service coexistence schemes have been developed. For example, compared with typical eMBB data packets, URLLC transmissions can be very small (e.g., lengths from a few bits to a few bytes). This can enable URLLC transmissions to preempt (i.e., take over) some of the resources allocated to eMBB transmissions. In another example, compared with eMBB transmissions, mMTC transmissions are usually very small but not usually time-critical. Since sending very small data packets is itself less efficient in terms of spectrum, mMTC data packets may experience latency until they can be sent together with larger eMBB data packets.

[0059] One drawback of existing coexistence schemes that allow preemption is that the performance of the preempted transmission is significantly degraded.

[0060] FIG. 3 is a schematic diagram of an example of how a URLLC transmission preempts an eMBB transmission according to some existing coexistence schemes.

[0061] Consider a scenario where a sending node uses some scheduled resources to send an eMBB data packet 302 to a receiving node in the current time slot. Thus, the eMBB transmission is the currently scheduled and ongoing transmission. This means that the receiving node may have received the scheduling signaling indicating the incoming eMBB transmission. However, a URLLC data packet arrives at the physical layer, and according to the coexistence scheme (which prioritizes URLLC transmissions), the sending node immediately allocates some resource positions (OFDM symbols) in the current time slot for the URLLC data packet 304. In other words, the URLLC data packet 304 has preempted (i.e., replaced) some of the symbols of the eMBB data packet 302. Typically, the URLLC data packet 304 only occupies part of the resource time slot because URLLC data packets are usually very small. Thus, the receiving node receives the eMBB data packet 302 with some of its symbols preempted by the URLLC data packet 304. It should be noted that although the receiving node is the intended recipient of the eMBB data packet 302, the same receiving node may or may not be the intended recipient of the URLLC data packet 304.

[0062] It should be noted that URLLC transmission preempts the scheduled eMBB transmission without sending any scheduling signaling to the receiving node in advance. At the beginning of the next time slot, a preemptive indicator is sent to the receiving node through the control channel (for example, sent in a control signal such as downlink control information (DCI) 306) to indicate the location of the preempted resources. In this way, the receiver knows which symbols belong to the URLLC packet 304 and which symbols belong to the eMBB packet 302. Therefore, when attempting to decode the eMBB packet 302, the receiving node clears (i.e., discards) the soft decision bits (usually represented as log-likelihood ratio (LLR)) that belong to the URLLC packet 304. Conceptually, this may be equivalent to treating the eMBB packet 302 as a punctured packet for rate matching. However, correct puncturing requires careful design of the puncturing pattern so that the punctured packet can be recovered. In the case where the URLLC packet 302 preempts a part of the eMBB packet 302, the preempted symbols can be arbitrarily selected. Usually, the eMBB packet 302 is severely damaged, so a retransmission 308 of the eMBB packet is required.

[0063] Therefore, the existing coexistence scheme enables the URLLC packet to preempt the eMBB packet to ensure that the URLLC packet is received with lower latency, but at the cost of a significant reduction in the performance of the eMBB transmission. Although the above discussion describes the preemption of the eMBB transmission by the URLLC packet, generally speaking, this drawback may occur in any coexistence scheme where the first existing transmission (for example, a low-priority transmission) can be preempted by the second transmission (for example, a high-priority transmission). Therefore, the problems solved by this application are not limited to the problems caused by the URLLC transmission preempting the eMBB transmission.

[0064] Another drawback of the existing coexistence scheme is that when the preempting packet (for example, the URLLC packet) is very small (for example, including less than 10 bits), even after setting the code rate very low, the coding gain is relatively small. According to coding theory, the coding gain mainly stems from a long code length, which may be limited in the existing coexistence scheme. Therefore, for these small packets, their error correction performance can be further improved.

[0065] This application describes a coexistence scheme that can help avoid or reduce at least some of the above drawbacks.

[0066] In the examples of this application, various preemptive coding schemes are described. Preemptive coding can also be referred to as multi-service multiplexing (i.e., multiplexing of different transmission types corresponding to different services). In the disclosed preemptive coding schemes, the information of both the first existing transmission (e.g., low-priority transmission) and the second transmission (e.g., high-priority transmission) is retained and recoverable, which is different from existing preemptive schemes that actually cause the second transmission to puncture the first transmission. Preemptive coding can be performed in various ways, such as jointly coding multiple payloads, scrambling or permuting one transmission to carry the data of an additional transmission, multilevel coding, or mask repetition coding. These techniques will be described in detail below.

[0067] This application also describes an exemplary resource mapping scheme. In existing preemptive schemes, the symbols of the second data packet (e.g., high-priority data packet, e.g., URLLC data packet) are mapped to consecutive physical resource blocks of the existing first data packet (e.g., low-priority data packet, e.g., eMBB data packet) (thus preempting consecutive symbols); in contrast, the exemplary resource mapping scheme disclosed herein can map the symbols of the second data packet to spaced-apart resource units. Some techniques of this mapping will be further described below. Since a time slot may include code blocks (CBs) of multiple first data packets, by extending the symbols of the second data packet in this way, each CB of the first data packet may only be slightly interfered with, thus reducing the negative impact on the successful decoding of the CB.

[0068] An exemplary preemptive coding scheme using joint coding, scrambling, or permutation is first described. This preemptive coding scheme enables the data of the second data packet (e.g., high-priority data packet, e.g., URLLC data packet) to be explicitly or implicitly embedded into the data of the existing first data packet (e.g., low-priority data packet, e.g., eMBB data packet). In this application, the preemptive coding scheme that embeds the data of the second data packet into the data of the existing first data packet can be referred to as combined data coding (to distinguish it from other types of preemptive coding, such as multilevel coding and mask repetition coding discussed further below). As discussed further below, the preemptive coding scheme using combined data coding can use joint coding, scrambling, or permutation, etc. Different from existing preemptive schemes, in the combined data coding scheme disclosed herein, the symbols of the first data packet are not removed or replaced by the second data packet. Instead, one or more CBs of the first data packet are replaced by corresponding one or more combined data-coded CBs, where one or more combined data-coded CBs are coded with the payload data of the first and second data packets. Then, when a data packet including one or more combined data-coded CBs is received by the receiving node, the receiving node can jointly decode the received data packet without having to clear a portion of the received signal.

[0069] Figure 4 It is a schematic diagram of an example of an exemplary preemptive coding scheme using combined data coding.

[0070] Figure 4 It shows a scenario similar to that in FIG. 3, where high-priority second data (e.g., URLLC data) arrives during the transmission of low-priority data (e.g., eMBB data). The low-priority data is an ongoing existing transmission that is currently scheduled (e.g., scheduling signaling may have been sent to the receiving node to indicate this transmission). The high-priority data arrives and will be transmitted without first being scheduled with the receiving node; thus, the high-priority data preempts the low-priority transmission. However, using the example of the combined data coding scheme disclosed herein, parts of the low-priority data are not completely replaced by the high-priority second data. Instead of removing the symbols of one or more existing eMBB CBs 402, one or more eMBB CBs 402 are replaced with corresponding one or more combined data-coded CBs 404. The combined data-coded CB 404 is generated by the transmitting node using a combination of the existing low-priority data and the newly arrived high-priority data (e.g., using joint coding, scrambling, or permutation operations). When all the high-priority data has been (together with the existing low-priority data) encoded into one or more combined data-coded CBs 404, the transmitting node can resume the transmission of the eMBB CBs 402 (the eMBB CBs 402 only include low-priority eMBB data).

[0071] At the beginning of the next time slot, a preemptive coding indicator (e.g., sent in a control signal such as DCI 406, etc.) is sent to the receiving node via a control channel to indicate the positions of one or more preemptively coded CBs (i.e., one or more combined data-coded CBs 404), and additional information required for the receiving node to decode one or more combined data-coded CBs 404 (e.g., the type of preemptive coding performed by the transmitting node, the updated TB size, etc.). Thus, the receiving node is able to decode one or more combined data-coded CBs 404 to recover the existing low-priority data (e.g., eMBB data) and the high-priority data (e.g., URLLC data). It should be noted that although Figure 4 shown as DCI 406, any suitable control signaling can be used. For example, if the transmission is an uplink transmission, the control information (including the preemptive coding indicator) can be included in an uplink control information (UCI) signal.

[0072] Figures 5A to 5C It shows some examples of how combined data coding can be implemented at a transmitting node (e.g., BS170 or UE 110). For example,Figures 5A to 5C The exemplary coding chains shown can be implemented using the processing unit 201 and the communication interface 202 of the device 200 acting as a sending node. A single sending node can be configurable to implement Figures 5A to 5C any of the exemplary coding chains shown, or can implement only Figures 5A to 5C one or two of the coding chains shown.

[0073] Figure 5A An example of performing combined data coding using joint coding is shown. Before the arrival of a second data set (e.g., high-priority or high-urgency data, such as URLLC data), a transport block (TB) including a first data set (e.g., low-priority data, such as eMBB data) is processed by a coding chain including operations 502 to 514. The TB can be divided into one or more CBs (not shown). Each CB is encoded in coding operation 502 (e.g., using a low-density parity-check (LDPC) code), followed by an interleaving operation 504 (and possibly other operations such as rate matching). The resulting coded bit sequence is processed by a scrambling operation 506, which may involve performing a bitwise XOR operation between the coded bit sequence and a scrambling sequence. After the scrambling operation 506 is a modulation operation 508 that modulates the scrambled bit sequence into modulation symbols. Optionally, the symbols are mapped by a layer mapping / precoding operation 510 and then mapped to resource units by a resource element mapping operation 512. Finally, the signal is multiplexed onto a carrier frequency and transmitted by a multiplexing operation 514 (e.g., using orthogonal frequency-division multiplexing (OFDM)).

[0074] When the second data arrives, the sending node can identify the second data as data with strict latency requirements that should be sent immediately (instead of waiting for resource scheduling). The arrival of the second data may interrupt the current processing of the first data (which may be in the process of being processed from the buffer). Instead of processing the waiting bits of the first data using the regular coding operation 502, the bits of the first data and the bits of the second data are jointly encoded using a joint coding operation 520. The joint coding can be performed using any suitable coding method that combines the bits of the first data and the bits of the second data, such as a linear combination among other possibilities. Then, the jointly encoded bits are processed by the interleaving operation 504 and the subsequent operations 506 to 514 of the coding chain as described above. When all the bits of the second data have been jointly encoded, the remaining bits of the first data (which may still be waiting in the buffer) can be processed using the regular coding operation 502 and the remaining operations 504 to 514. Then, the resulting one or more combined data-coded CBs are sent.

[0075] Figure 5A For the coding strand, the second data is embedded into the first data using combined coding, which can be applicable to the case where the second data has a small to medium payload size (e.g., about 10 bits to several bytes). To ensure that the second data with strict latency requirements is received earlier, the combined-coded bits can be mapped to earlier decoded bit positions or high-priority bit positions.

[0076] Figure 5B Another exemplary coding strand is shown, where combined data coding is performed using a scrambling operation. Figure 5B Some components of the shown coding strand are similar to Figure 5A those, and the similar components will not be elaborated.

[0077] Before the second data set (e.g., high-priority or high-urgency data, such as URLLC data) arrives, the transport block (TB) including the first data set (e.g., low-priority data, such as eMBB data) is processed by the coding strand including operations 502 to 514 as described above. When the second data arrives and is recognized by the sending node as data with strict latency requirements that should be sent immediately, the bits of the second data are first processed by the bit mask generation operation 530. The bit mask generation operation 530 generates a scrambling pattern in the form of a bit mask using the bits of the second data. For example, the bit pattern of the second data can be used in a function or formula to generate a binary sequence (e.g., a Gold sequence or any other suitable randomization sequence), which can then be used as the bit mask. In some examples, the bits of the second data can simply be repeated until a sufficient bit length is obtained to generate the bit mask. Then, the bit mask (which can have the same bit length as the codeword generated by the bits of the first data) is used in the scrambling operation 506. In this way, the bits of the URLLC data are encoded in the scrambled bit sequence generated by the scrambling operation 506. Then, the scrambled bit sequence is processed according to the usual subsequent operations 508 to 514, and then the resulting one or more combined data-coded CBs are sent.

[0078] Figure 5C Another exemplary coding strand is shown, where combined data coding is performed using a permutation operation. Figure 5C Some components of the shown coding strand are similar to Figure 5A those, and the similar components will not be elaborated.

[0079] Before the arrival of a second data set (e.g., high-priority or high-urgency data, such as URLLC data), a transport block (TB) including a first data set (e.g., low-priority data, such as eMBB data) is processed by an encoding chain including operations 502 to 514, as described above. When the second data arrives and is recognized by the transmitting node as data with strict latency requirements that should be transmitted immediately, the bits of the second data are first processed by a permutation generation operation 540. The permutation generation operation 540 uses the bits of the second data as a permutation sequence to determine how to permute the bits of the first data in the interleaving operation 504 (it should be noted that this operation can also be referred to as a permutation operation rather than an interleaving operation). For example, if the codeword generated by the bits of the first data is a cyclic code of length 8, there are 8 possible unique permutations such that the binary vector after applying the permutation is also a valid codeword (this is a property of cyclic codes). Then, each possible permutation can be associated with a corresponding 3-bit permutation sequence. For example, the permutation sequence 001 can be associated with a cyclic shift of 1, and the permutation sequence 010 can be associated with a cyclic shift of 2. Thus, if the bits of the URLLC data are "010", the permutation generation operation 540 determines that a cyclic shift of 2 should be performed in the interleaving operation. In this way, the bits of the URLLC data are encoded in the interleaved bit sequence generated by the interleaving operation 504. Then, the interleaved bit sequence is processed according to the usual subsequent operations 506 to 514, and then the resulting one or more combined data-encoded CBs are transmitted.

[0080] Use scrambling or permutation (e.g., using Figure 5B or Figure 5CThe combined data encoding of the exemplary encoding chain implicitly embeds the second data set into the first data set. Specifically, the second data set (e.g., URLLC data) is implicitly embedded into the scrambling sequence or permutation sequence of the bits applied to the first data set (e.g., eMBB data). Scrambling or permutation may be applicable when the payload size of the second data set is small (e.g., less than or equal to 10 bits in size). The receiving node receives an indicator (e.g., via a control signal) indicating whether scrambling or permutation is used for combined data encoding. At the decoder of the receiving node, blind decoding can be performed, where the decoder attempts to decode one or more combined data-encoded CBs using all possible scrambling sequences or permutation sequences (depending on whether scrambling or permutation is used for combined data encoding). When the decoder finds a scrambling sequence or permutation sequence that successfully decodes one or more combined data-encoded CBs, the payload corresponding to the successful scrambling sequence or permutation sequence is determined to be the decoded second data set (e.g., decoded URLLC bits). For example, the receiving node can use a predefined look-up table, predefined rule, or predefined function (e.g., as defined in a standard) that maps the scrambling sequence or permutation sequence to a bit sequence; thus, the predefined table, rule, or function can be used to map the successful scrambling sequence or permutation sequence to a specific bit sequence that forms the decoded bits of the second data set.

[0081] It should be noted that when combined data encoding is employed, whether using joint encoding, scrambling, or permutation, the length of the transmitted codeword can be unchanged by the combined data encoding. This means that, in the case of joint encoding, the code rate can be increased. Similarly, the size of the TB can be changed by adding a second data set embedded in one or more combined data-encoded CBs. Therefore, a TB size calculation step may be required to update the size of the TB based on the payload size of the additional second data set. The transmitting node can recalculate the TB size and provide information about the updated TB size in control information (e.g., in DCI, UCI, or other control signaling).

[0082] As described above, combined data encoding will increase the code rate of the CB. Figure 5D and Figure 5E illustrates an example of how the code rate of the CB can be increased by additional bits of the second data set.

[0083] In Figure 5D and Figure 5E In two examples, the existing first data set is eMBB data and the second data set is URLLC data. The URLLC information bits (denoted as I u ) are added to the existing eMBB information bits (denoted as I m) and in one or more CBs with parity check bits (denoted as P). In these simplified examples, there are four CBs (denoted as CB1 to CB4) belonging to a CB group (CBG).

[0084] In Figure 5D the CBG 550, the URLLC information bits I u are all added to CB1. As a result, the code rate of CB1 is significantly increased, and the performance of CB1 (e.g., block error rate (BLER)) is significantly reduced. At the same time, the code rates and performances of CB2 to CB4 remain unchanged. In Figure 5E another example CBG 555, the URLLC information bits I u are distributed among all the CBs of CBG 555. The URLLC information bits I u can be evenly distributed, approximately evenly distributed (e.g., if the number of URLLC information bits I u cannot be evenly distributed according to the number of CBs), or unevenly distributed. Regardless of how the URLLC information bits I u are distributed among the CBs of CBG 555, the result is that multiple (or all) CBs of CGB 555 have a moderate or slight increase in code rate and a moderate or slight decrease in performance.

[0085] In some examples, when bits of a second data set are added to a CB that includes bits of a first data set (e.g., for joint coding), the added bits of the second data set may preferably be multiplexed among multiple CBs rather than all multiplexed into only one CB to avoid a significant reduction in the performance of that CB.

[0086] The exemplary techniques disclosed herein for combined data encoding of first and second data sets belonging to different transmission types can be applied to the case where both the first and second data sets are expected to be used by the same receiving node. This is because the receiving node needs to be able to decode the first and second data sets from one or more combined data - encoded CBs. For example, UL transmissions of two different transmission types (e.g., eMBB data and URLLC data) from UE 110 to BS170 can be expected to be used by the same receiving node (i.e., the same BS170). DL transmissions and SL transmissions of two different transmission types are less likely to be expected to be used by the same receiving node.

[0087] This document discloses other preemptive coding schemes, which may be applicable to cases where the first and second data sets are expected to be used by different receiving nodes, which may be a common scenario for DL transmissions and SL transmissions. For example, the first data set (e.g., eMBB data) may be expected to be received by the first UE 110, and the second data set (e.g., URLLC data or mMTC data) may be expected to be received by the second UE 110.

[0088] An exemplary preemptive coding scheme using multi-level coding (MLC) is now described. MLC is a coding technique that has been described above (e.g., see “A new multilevel coding method using error-correcting codes” by Imai et al., IEEE Transactions on Information Theory, 1977, which is incorporated herein by reference). However, MLC has not been adapted for multiplexing the first and second data sets belonging to different transmission types. This application describes a preemptive coding scheme that adapts MLC for multiplexing two data sets belonging to different transmission types, where the two data sets are expected to be used by different receivers.

[0089] In preemptive coding using MLC, separate codewords are generated for each data set belonging to each respective transmission type (e.g., data bits from an eMBB transmission are encoded into one codeword, while data bits from a URLLC transmission are encoded into a separate codeword). The different codewords are mapped onto common symbols on the constellation such that the transmitted symbols carry bits from the different codewords belonging to the respective different transmissions.

[0090] Consider an example where there is a first data set belonging to a first existing transmission type (e.g., existing, low - priority transmission) and a second data set belonging to a second preemptive transmission type (e.g., newly arrived, high - priority transmission). Each data set is intended for a corresponding different recipient (e.g., the first data set is intended for a first receiving node, while the second data set is intended for a second receiving node). Preemptive encoding using MLC can include first encoding the payload data of each transmission type into one or more codewords. Then, a certain number of code bits are selected from one or more codewords belonging to each transmission type, and the selected code bits are concatenated together to form a bit vector. The code bits in the bit vector can be sorted such that the code bits selected from one or more codewords belonging to the second (e.g., high - priority) transmission type (also simply referred to as second code bits) are placed in one or more least significant bit (LSB) positions, and the code bits selected from one or more codewords belonging to the first (e.g., existing, low - priority) transmission type (also simply referred to as first code bits) are placed in one or more most significant bit (MSB) positions. The code bits of the second transmission type can be placed in one or more LSB positions because LSBs are demodulated earlier than MSBs and are not affected by error propagation. Then, the bit vector is mapped to a symbol. Thus, the first and second code bits (carrying information corresponding to the first and second data sets) are jointly mapped to a symbol. Then, this symbol can be sent by the sending node to different intended receiving nodes. Each receiving node receives the sent symbol, demodulates the symbol, and decodes the bits. It is worth noting that since decoding typically starts from the LSB positions, the second receiving node (which is the intended recipient of the second data set) may only need to decode the second code bits (the second code bits correspond to the second data set and are in the LSB positions), without having to decode the first code bits. This helps reduce the latency of the second data set belonging to a latency - sensitive transmission type (e.g., URLLC).

[0091] Figure 6A is a schematic diagram of an example of preemptive encoding using MLC, which can be implemented at the sending node to jointly map the code bits generated from the first and second data sets to a common MLC symbol.

[0092] In this example, the first data set corresponds to a first existing transmission type (e.g., a low-priority transmission, such as an eMBB transmission), while the second data set corresponds to a newly arrived second preemptive transmission type for a different service (e.g., a high-priority transmission, such as a URLLC transmission). A serial-to-parallel (S / P) conversion operation 602 is performed on the payload bits of each data set. The payload bits from the second data set are divided into u1 and u2 information vectors (each information vector being one or more bits), and the payload bits from the first data set are divided into u3, u4, …, u M-1 information vectors. More generally, if the modulation order is m, there are m levels (i.e., the number of levels is equal to the modulation order), where m1 levels are allocated for carrying information vectors from the first data set and m2 levels are allocated for carrying information vectors from the second data set (where m1 + m2 = m). Then, each information vector carried on each level is encoded into a corresponding codeword by an encoder 604. Thus, MLC is performed between the data bits of the first and second data sets and within the data bits of the first data set.

[0093] Then, one code bit is extracted from each codeword, and these code bits are jointly mapped to symbols. Typically, m1 codewords are taken from the m1 codewords generated from the second data set and m2 codewords are taken from the m2 codewords generated from the first data set. In the example shown, one bit is extracted from each codeword such that code bits c1 and c2 (referred to as second code bits) are extracted from the codewords generated by the second data set (belonging to the second transmission type) and code bits c3, c4, …, c M-1 (referred to as first code bits) are extracted from the codewords generated by the first data set (belonging to the first transmission type).

[0094] The first and second code bits are concatenated by a concatenation operation 608. The concatenation can be performed such that the higher-priority second code bits are placed in the LSB positions of the resulting bit vector c M-1 、…、c4、c3、c 2、 c1. The bit vector includes m bits, corresponding to m-order modulation. The bit vector is mapped to a single symbol in the constellation using a constellation mapping operation 610 (e.g., using 2 m -QAM modulation). For constellation mapping, Ungerboeck set partitioning can be used. One advantage of using Ungerboeck set partitioning is that as more bits are decoded at the receiving node, the Euclidean distance also increases. However, other forms of partitioning can also be used.

[0095] Figure 6BSchematic diagram of another example of preemptive coding using MLC, which can be implemented at the transmitting node to jointly map the code bits generated from the first and second data sets to common symbols.

[0096] Similar to the example of Figure 6A In Figure 6B , the first data set corresponds to the first existing transmission type (e.g., low-priority transmission, such as eMBB transmission), while the second data set corresponds to the newly arrived second preemptive transmission type for different services (e.g., high-priority transmission, such as URLLC transmission). Compared with the example of Figure 6A In the example of Figure 6B , the number of levels is less than the modulation order.

[0097] The payload bits of the second data set are encoded by the encoder 622 into a single codeword, and the payload bits of the first data set are encoded by another encoder 622 into another codeword. Each codeword is processed by the S / P conversion 624 into a corresponding code vector, from which the second code bits c1 and c2 and the first code bits c3, c4,..., c M-1 are extracted. For example, if the S / P conversion 624 divides the codeword generated from the second data set into m1 second code vectors and divides the codeword generated from the first data set into m2 first code vectors, then m1 code bits are extracted from the m1 code vectors generated from the second data set, and m2 code bits are extracted from the m2 code vectors generated from the first data set.

[0098] Then, similar to the example of Figure 6A , the first and second code bits are concatenated by the concatenation operation 628. The concatenation can be performed such that the high-priority second code bits are placed in the LSB positions of the resulting bit vector c M-1 ,..., c4, c3, c 2、 c1. The bit vector is mapped to a single symbol in the constellation using the constellation mapping operation 630. This example can correspond to 2-level MLC, where MLC is performed between the first and second data sets, and bit interleaved coded modulation (BICM) is performed within the first data set and within the second data set.

[0099] In this example, since the number of levels used for MLC is less than the modulation order (e.g., for 2 m -QAM modulation performs l-level MLC, where l < m), a hybrid set partitioning can be used. For example, Ungerboeck set partitioning can be performed between consecutive levels, and Gray labeling can be performed within each level.

[0100] Compared with the example of Figure 6A InFigure 6B In the example of [[ID=]], there are fewer levels. This allows the receiving node to implement a simpler decoder (instead of a decoder designed to decode each level bit by bit).

[0101] Regardless of how MLC-based preemptive coding is performed, after the first and second data sets have been jointly mapped to symbols, for example, as Figure 6A or Figure 6B shown, the sending node sends the symbols to the first and second receiving nodes (the first and second receiving nodes are the intended recipients of the first and second data sets, respectively). At each receiving node, the decoder is used to decode the signal received through the transmission channel. Each receiving node can implement one of several possible decoders, some examples of which will be described below.

[0102] Figure 7A is a schematic diagram of an example of multilevel decoding, which can be implemented at the receiving node when MLC-based preemptive coding is used at the sending node.

[0103] In this example, multilevel decoding is used. The value of the received signal for each level is represented as l1, l2, l3, ……, l M-1 . Each level is decoded separately by the corresponding decoder 702. The decoded bits from each lower-level decoding are fed to the higher-level decoder 702 to assist in decoding. For example, the decoded bits decoded from level l1 and are fed to the next-level decoder 702 to assist in decoding level l2, and so on. The decoded bits belonging to each corresponding data set are processed and output through a parallel-to-serial (P / S) conversion 704. The receiving node can know from the control information sent by the sending node which level corresponds to which data set, and thus can separate the two data sets accordingly. In this example, the decoded bits M-1 from level l1 and level l2 and are known to belong to the second data set (belonging to the second transmission type, which can be a high-priority transmission, such as URLLC), and the decoded bits

[0104] from level l3 to l M-1 are known to belong to the first data set (belonging to the first existing transmission type, which can be a low-priority transmission, such as eMBB).

[0104] It should be noted that the receiving node can be the intended recipient of only a specific one of the first or second data sets. Therefore, only the decoded bits belonging to the specific data set related to the receiving node can be processed and output by the P / S conversion 704. If the receiving node is the intended recipient of the second data set, the decoding can stop after the bits corresponding to the second data set have been decoded (for example, it may not be necessary to decode the remaining levels l3 to lM-1 ) This may help reduce unnecessary processing at the receiving node. If the receiving node is the intended recipient of the first data set, it may be necessary to first decode the bits corresponding to the second data set before decoding the bits corresponding to the first data set (and then the decoded bits corresponding to the second data set can be discarded).

[0105] Figure 7B is a schematic diagram of an example of hybrid decoding, which can be implemented at the receiving node when MLC-based preemptive coding is used at the sending node.

[0106] Compared with Figure 7A the multilevel decoding shown, Figure 7B the hybrid decoding shown may have suboptimal performance (i.e., does not fully utilize the multilevel gain), but can reduce the complexity implemented at the receiving node.

[0107] In Figure 7B , all values corresponding to the levels of the second data set (i.e., levels l1 and l2) are decoded by a single decoder 722. The decoded bits corresponding to the second data set and are used to assist in decoding the bits of the first data set, all of which are decoded by another decoder 722. Then, similar to the example of Figure 7A , the decoded bits belonging to each corresponding data set are processed and output by the corresponding P / S conversion 724. If the receiving node is only the intended recipient of the second data set, it may only be necessary to decode the bits on levels l1 and l2. If the receiving node is only the intended recipient of the first data set, all bits can be decoded, and the bits corresponding to the second data set can be discarded.

[0108] Figure 7C is a schematic diagram of an example of independent decoding, which can be implemented at the receiving node when MLC-based preemptive coding is used at the sending node.

[0109] Compared with Figure 7A the multilevel decoding shown and Figure 7B the hybrid decoding shown, Figure 7C the independent decoding shown may have worse performance, but may be easier to implement at the receiving node.

[0110] In Figure 7CIn the example, all levels are modulated and decoded in parallel. Specifically, a single decoder 742 decodes the levels corresponding to the second data set, while another decoder 742 decodes the levels corresponding to the first data set. However, the decoded bits of the second data set are not used to assist in decoding the bits of the first data set. The decoded bits output by each decoder 742 are processed and output by the corresponding P / S conversion 744. If the receiving node is only the intended recipient of the second data set, it may only be necessary to decode the bits on levels l1 and l2. If the receiving node is only the intended recipient of the first data set, all bits can be decoded and the bits corresponding to the second data set can be discarded.

[0111] Preemptive coding using MLC can be applied to cases using high signal-to-noise ratio (SNR) modulation schemes, such as 16QAM (where QAM stands for quadrature amplitude modulation), 32QAM, or 64QAM. Other preemptive coding schemes using masked repetition coding (MRC) may be applicable to cases using low SNR modulation schemes, such as 4QAM or quadrature phase shift keying (QPSK). An example of preemptive coding using MRC is now described.

[0112] In MRC-based preemptive coding, the codeword generated by the high-priority second data set (the second data set is of the second preemptive transmission type) is masked onto a part of the repeated symbols generated by the low-priority first data set (the first data set is of the first existing transmission type). It should be noted that such repetition is usually performed to ensure communication reliability when the SNR is low (e.g., for eMBB receiving nodes). The masking can be performed using modulo-2 addition (i.e., XOR) in the binary domain. MRC-based preemptive coding can be used in scenarios where the first and second data sets are intended for different recipients, however this is not intended to be limiting.

[0113] In short, preemptive coding using MRC involves first identifying two or more copies (also called repetitions) of the first codeword (or symbol) generated by the first data set of the first existing transmission type. Then, the second codeword generated by the second data set of the second preemptive transmission type is masked onto one or some (but not all) of the copies of the first codeword. Then, the masked bits are remodulated into one or more new symbols to replace one or more corresponding symbols of the first transmission type.

[0114] Figure 8A is a schematic diagram of an example of MRC-based preemptive coding, which can be implemented by a sending node.

[0115] In this example, the first data set belonging to the first existing transmission type may be eMBB data, and the second data set belonging to the second preemptive transmission type may be URLLC data, although this is not intended to be limiting. As shown, there may be two copies of the first codeword 802 generated from the first data set. The second codeword 804 generated from the second data set is masked onto one copy of the first codeword 802 using a masking operation 806, resulting in a masked codeword 808 that replaces one copy of the first codeword 802. Then, the remaining (unmasked) copies of the first codeword 802 and the masked codeword 808 are further mapped to a first symbol 812 and a masked symbol 814, respectively, and transmitted by the transmitting node. Thus, the masked symbol 814, which includes information from the first data set as well as the preemptive second data set, replaces one instance of the first symbol 812, but not all instances of the first symbol 812.

[0116] Figure 8B FIG. 5 is a schematic diagram of an example of demasking and decoding that can be implemented at the receiving node. The receiving node may be the intended recipient of the first data set, the second data set, or both.

[0117] The first symbol 812 and the masked symbol 814 are first demodulated by a demodulation operation 822. The log-likelihood ratio (LLR) of the bits of the second codeword (which has been masked onto a copy of the first codeword) can be recovered by a demasking operation 824 that uses a demasking function (also referred to as the f function). The demasking function can be expressed as follows:

[0118] l = sgn(l1, l2) min(l1, l2)

[0119] where l1 is the LLR of the bits of the first codeword, l2 is the LLR of the bits of the masked codeword, l is the LLR of the bits of the recovered second codeword, and sgn represents the sign function (a function that extracts the sign of a real number). After all the LLRs of the bits of the second codeword have been recovered from the demasking operation 824, the second codeword can be decoded by a second transmission type decoder 826 (e.g., a URLLC decoder in the case where the second transmission type is URLLC transmission) to recover the second data set. The decoded second codeword can be fed together with the demodulated symbols to a first transmission type decoder 828 (e.g., an eMBB decoder in the case where the first transmission type is eMBB transmission) to recover the first data set.

[0120] If the receiving node is only an intended recipient of the second data set, the receiving node does not need to decode the first data set (and does not need to use the first transmission type decoder 828). If the receiving node is only an intended recipient of the first data set, the receiving node may only need to decode the unmasked first codeword using the first transmission type decoder 828, without having to perform the demasking 824 operation or decode the second codeword. Alternatively, even if the receiving node is not an intended recipient of the second data set, the receiving node can still perform the demasking operation 824 and decode the bits of the second codeword to assist in decoding the first codeword (and thus benefit from the repetition gain).

[0121] In the above discussion, different techniques for performing preemptive coding are described. It should be understood that the sending node can be capable of performing any of the above preemptive coding techniques and can be used to use the selected preemptive coding technique based on one or more intended receiving nodes and / or the available SNR. For example, when the data of the first existing transmission type and the second preemptive transmission type are both intended for the same receiving node, the sending node can use a preemptive coding scheme that combines data coding. In another example, when the data for the first existing transmission type and the data for the second preemptive transmission type are intended for corresponding different receiving nodes, the sending node can use the MLC preemptive coding scheme when the SNR is high, or can use the MRC preemptive coding scheme when the SNR is low.

[0122] Regardless of how the sending node performs preemptive coding, in some examples, the sending node can map the preemptively encoded symbols to non - contiguous physical resource blocks (PRBs).

[0123] Referring again to Figure 3. Conventionally, the symbols belonging to one CB that preempt an existing eMBB data packet 302 (e.g., all symbols belonging to the URLLC data packet 304) are mapped to contiguous PRBs. This means that one or more eMBB CBs are severely punctured and thus are likely to not be successfully decoded. This drawback can be reduced by the non - contiguous mapping disclosed herein.

[0124] Figure 9 is a schematic diagram of an example of non - contiguous mapping that can be performed by the sending node as disclosed herein.

[0125] The preemptively encoded CB 904 can be generated by a transmitting node using any suitable preemptive encoding scheme (e.g., the MLC preemptive encoding scheme) as described above. The preemptively encoded CB 904 includes a plurality of preemptively encoded symbols 904b. The transmitting node applies a discontinuous mapping pattern 910 to map the symbols 904b of the preemptively encoded CB 904 to different discontinuous resource elements (REs) that are currently used for transmitting the existing CB 902. The discontinuous mapping pattern 910 can be a sparse pattern such that each existing CB 902 is only slightly disturbed (compared to the conventional case shown in FIG. 3). For example, the discontinuous mapping pattern 910 can map the preemptively encoded symbols 904b to equally spaced REs or pseudo-randomly selected REs. For example, the discontinuous mapping pattern 910 can define a mapping that maps the preemptively encoded symbols 904b to REs at regularly defined intervals (e.g., if the interval is represented as p, the preemptively encoded symbols 904b can be mapped to the REs at positions 1, p + 1, 2p + 1, etc.). In another example, the discontinuous mapping pattern 910 can be specified using a pseudo-random sequence, where the index in the pseudo-random sequence indicates the RE to which the preemptively encoded symbol 904b is to be mapped.

[0126] The discontinuous mapping pattern 910 can be predefined (e.g., in a standard) and can be indicated to the receiving node in a subsequently transmitted DCI 906 (transmitted in the next time slot) so that the receiving node can identify and decode the preemptively encoded symbols 904b. It should be noted that although Figure 9 shown as DCI 906, any suitable control signaling can be used. For example, if the transmission is an uplink transmission, the control information (including the indication of the discontinuous mapping pattern 910) can be included in the UCI.

[0127] The transmitting node can use the discontinuous mapping pattern 910 to map symbols of the preemptive transmission type, even if the preemptive encoding disclosed herein is not used. For example, the transmitting node can use the discontinuous mapping pattern 910 disclosed herein to map the symbols of the URLLC packet 304 in FIG. 3 to discontinuous REs to help reduce interference to the existing eMBB packet 302, and the discontinuous mapping pattern 910 can be indicated in the DCI 306 (or other control signaling).

[0128] To support the preemptive encoding scheme disclosed herein, suitable control signaling can be used to enable the receiving node to appropriately decode data of the first or second transmission type. For example, see Figure 4 and Figure 9, the DCI 406, 906 sent in the time slot after transmitting the preemptively encoded CB404 or the non - consecutively mapped preemptively encoded symbol 904b can be used to convey preemptive encoding information to the receiving node. Generally, the preemptive encoding information can be conveyed in any suitable control signal, and the control signal can be a DCI signal, a UCI signal, or other control signaling.

[0129] The preemptive encoding information that can be included in the control signaling can include the number of existing CBs preempted and the locations of the preempted existing CBs; the type of preemptive encoding used (e.g., none, combined data encoding (specifically, whether joint encoding, scrambling, or permutation is used), MLC, or MRC); and / or the updated TB size and MCS index (e.g., code length, information length) of each preempted CB. The code length and code rate used in the existing transmission type encoding, and the code length and code rate used in the preemptive transmission type encoding can be included in the control signaling.

[0130] In addition, depending on the preemptive encoding scheme used by the transmitting node, the control signaling can include additional information. If combined data encoding with joint encoding is used, the code types for both the existing and preemptive transmission types can be indicated in the control signaling. If combined data encoding with scrambling is used, the set of scrambling sequences used (e.g., Gold sequences or M sequences) can be indicated in the control signaling. If combined data encoding with permutation is used, the set of permutation sequences used (e.g., automorphism group) can be indicated in the control signaling. If MLC preemptive encoding is used, the layers selected for each transmission type, the constellation mapping (e.g., hybrid set partitioning), and the rate allocation between the two transmission types can be indicated in the control signaling. If MRC preemptive encoding is used, the rate allocation between the two transmission types, and which existing block is masked can be indicated in the control signaling.

[0131] In an example where preemptively encoded symbols are mapped to non - consecutive REs using a non - consecutive mapping mode, the non - consecutive mapping mode can be indicated in the control signaling. In some examples, the non - consecutive mapping mode or the set of available non - consecutive mapping modes can be predefined (e.g., defined in a standard), and the control signaling can include an indicator (e.g., in a digital field) indicating which predefined non - consecutive mapping mode is used.

[0132] This information enables the receiving node to identify which portions of the received transmission include pre-emptively encoded data. As described above, instead of flushing the soft LLR corresponding to this portion of the transmission and thus losing any soft information included in the soft LLR (as is the case in traditional pre-emptive transmissions), the receiving node can use the soft decoding information to assist in decoding the first or second transmission type. For example, although the signal quality of the bits of the first existing transmission type may be low (due to interference caused by the bits of the second pre-emptive transmission type), there is still soft information (e.g., likelihood information) about the bits of the first transmission type included in the soft LLR that can be used to assist in decoding the bits of the first transmission type.

[0133] Figure 10 is a flowchart of an exemplary method 1000 for multiplexing a first data set belonging to a first existing transmission type (e.g., eMBB data) with a second data set belonging to a second pre-emptive transmission type (e.g., URLLC data) using pre-emptive coding. Method 1000 may be performed by a sending node, which may be Figure 1 a BS 170, a UE 110, or other sending device in a wireless system such as wireless communication system 100. For example, method 1000 may be performed by a processing unit executing non-transitory computer-readable instructions stored in a memory.

[0134] At 1002, the sending node performs a scheduled transmission of a first data set belonging to a first existing transmission type (e.g., eMBB transmission) to a intended recipient.

[0135] At 1004, during or before the scheduled transmission of the first existing transmission type, a second data set belonging to a second pre-emptive transmission type (e.g., URLLC transmission) is obtained or received. The second transmission type may be any transmission type that is considered to have a higher priority than the first transmission type (e.g., has a more stringent low-latency requirement than the first transmission type) and thus needs to be transmitted without waiting for the first transmission type to complete transmission. For example, the second data set may be a set of URLLC data received by the sending node from another node or generated internally by the sending node that should be transmitted at the earliest opportunity. The second data set may be intended for the same recipient as the first data set or for a different recipient.

[0136] At 1006, at least one bit of the first data set is multiplexed with at least one bit of the second data set. Various techniques may be used to perform this multiplexing, including combined data coding (e.g., joint coding, scrambling, permutation) as disclosed herein, MLC, or MRC. Regardless of how the multiplexing is performed, the result is a multiplexed code block that includes at least one multiplexed symbol that includes information from both the first and second data sets.

[0137] At 1008, the sending node outputs a multiplexed code block, e.g., by transmitting the multiplexed code block. The multiplexed code block may replace an existing code block that includes only information from the first data set. The multiplexed code block may be sent to the intended recipient(s) of the first and second data sets (if the two data sets have the same intended recipient), or to the intended recipient of the first data set and another intended recipient of the second data set (if the two data sets have two different intended recipients).

[0138] Although not shown in Figure 10 After transmitting the multiplexed code block, control signaling may be transmitted (e.g., in the next time slot), which enables one or more intended recipients to correctly decode and recover the information of the first and second data sets (e.g., the control information as described above).

[0139] Figures 11A to 11C FIG. is a flow chart of an example of how to perform method 1000 using various preemptive coding techniques disclosed herein.

[0140] Figure 11A is a flow chart of an exemplary method 1100, which is Figure 10 an exemplary implementation of method 1000, in which multiplexing is performed using combined data coding between data of a first existing transmission type and data of a second preemptive transmission type.

[0141] Method 1100 includes steps 1002 and 1004, which are described above in connection with Figure 10 respectively.

[0142] At 1106 (which is an exemplary implementation of step 1006), a combined data code block is generated by at least one bit of the first data set and at least one bit of the second data set (the combined data code block may be an exemplary implementation of the multiplexed code block). For example, the combined data code block may be generated by performing steps 1106a, 1106b, or 1106c.

[0143] At 1106a, at least one bit of the first data set and at least one bit of the second data set are jointly encoded (e.g., as shown in Figure 5A ), and the jointly encoded codeword is further processed by an encoding chain.

[0144] At 1106b, at least one bit of the second data set is used to generate a bit mask. At least one bit of the first data set is scrambled by the bit mask (e.g., as shown in Figure 5B ), and is further processed by the encoding chain.

[0145] At 1106c, at least one bit of the second data set is used to generate a permutation sequence. At least one bit of the first data set is interleaved using the permutation sequence (e.g., as shown inFigure 5C as shown), and further processed by the coding chain.

[0146] Regardless of how the combined data code block is generated, at 1108 (which is an exemplary implementation of step 1008), for example, the sending node outputs the combined data code block by sending the combined data code block. The combined data code block is sent in place of the existing code block that only includes information from the first transmission type.

[0147] Figure 11B is a flowchart of an exemplary method 1110, which is Figure 10 an exemplary implementation of the method 1000, in which MLC is used for multiplexing between data of the first existing transmission type and data of the second preemptive transmission type.

[0148] Method 1110 includes steps 1002 and 1004, which are described above in conjunction with Figure 10 respectively.

[0149] At 1116 (which is an exemplary implementation of step 1006), MLC is performed between one or more bits of the first data set and one or more bits of the second data set. For example, steps 1118 to 1122 can be used to perform MLC.

[0150] At 1118, one or more bits of the first data set and one or more bits of the second data set are mapped to different levels. It should be noted that the bits of the first and second data sets are mapped to different levels such that there is no level that carries bits from both the first and second data sets. In some examples, the number of levels can be equal to the modulation order (e.g., as Figure 6A shown); in other examples, the number of levels can be less than the modulation order (e.g., as Figure 6B shown).

[0151] At 1120, the one or more bits carried on each level are encoded into corresponding codewords by the respective encoders. Since each level only carries one or more bits from the first data set or one or more bits from the second data set, this means that one or more bits of the first data set and one or more bits of the second data set are encoded into different codewords.

[0152] At 1122, one or more code bits are selected from each codeword generated in step 1120, and these code bits are jointly mapped to multilevel coded symbols. For example, this can include concatenating one or more code bits selected from the codewords generated by the first data set with one or more code bits selected from the codewords generated by the second data set to obtain a bit vector that includes bits from different codewords (e.g., as Figure 6A or Figure 6Bas shown). Then, the bit vector is mapped to a symbol. Since the symbol includes code bits corresponding to different levels, the symbol is referred to as a multi-level coded symbol.

[0153] At 1124 (which is an exemplary implementation of step 1008), for example, the transmitting node outputs a code block including a multi-level coded symbol by transmitting a code block including the multi-level coded symbol. The MLC code block is transmitted in place of the existing code block that includes only information from the first transmission type.

[0154] Figure 11C is a flowchart of an exemplary method 1130, which is an exemplary implementation of the method 1000 Figure 10 wherein MRC is used for multiplexing between data of the first existing transmission type and data of the second preemptive transmission type.

[0155] Method 1110 includes steps 1002 and 1004, which are described above in connection with Figure 10 respectively.

[0156] At 1136 (which is an exemplary implementation of step 1006), MRC is performed between one or more bits of the first data set and one or more bits of the second data set. For example, MLC can be performed using steps 1138 to 1142.

[0157] At 1138, a first codeword is generated from one or more bits of the first data set. Specifically, two or more than two copies of the first codeword are generated.

[0158] At 1140, a second codeword is generated from one or more bits of the second data set.

[0159] At 1142, the second codeword is masked onto one or some (but not all) copies of the first codeword. The result is at least one (unmasked) copy of the first codeword and one or more copies of the masked codeword (e.g., as Figure 8A shown). Both the unmasked codeword and the masked codeword are modulated into symbols. Specifically, one or more masked repeated coded symbols are generated from one or more masked codewords.

[0160] At 1144 (which is an exemplary implementation of step 1008), for example, the transmitting node outputs a code block including one or more masked repeated coded symbols by transmitting a code block including one or more masked repeated coded symbols. The MRC code block is transmitted in place of the existing code block that includes only information from the first transmission type.

[0161] In various examples, the present application has described methods and systems in which existing transmission types (e.g., eMBB) are multiplexed with preemptive transmission types (e.g., URLLC) in multiplexed transmissions. Using the exemplary preemptive coding techniques disclosed herein, rather than having to discard the preempted existing data (which can be considered equivalent to puncturing existing transmissions), data of the preemptive transmission type is multiplexed with data of the existing transmission type and sent together with the data of the existing transmission type. This may help avoid the high likelihood of being unable to decode the preemptive data of the existing transmission and may also eliminate the need for external erasure codes. At the same time, data of the preemptive transmission type can be sent at the earliest opportunity, thus enabling low-latency transmission of latency-sensitive data.

[0162] The present application describes different preemptive coding techniques that can be used to multiplex data of an existing transmission type with data of a preemptive transmission type. The different preemptive coding techniques disclosed herein can be applicable to different transmission scenarios, including scenarios where the same receiving node is the intended recipient of both transmission types, where different receiving nodes are the intended recipients of different transmission types, and scenarios of high SNR or low SNR transmissions.

[0163] Examples of the present application can be implemented in current and next-generation mobile and wireless networks (e.g., 5G networks, 5G+ networks, 6G networks, WiFi networks, non-terrestrial networks, distributed networks, or ad-hoc networks), including cloud and edge computing services and sensing services. Wireless systems in which examples of the present application can be implemented can include cellular networks, ad-hoc networks, etc., and can involve BS-UE communication, UE-UE (or device-to-device) communication, etc.

[0164] Examples of the present application are useful in any application involving hybrid transmission types (e.g., hybrid URLLC and eMBB traffic, hybrid mMTC and eMBB traffic, hybrid IoT and eMBB traffic, etc.). For example, human-centric communications (e.g., where wearable devices can communicate with a wireless network and a smartphone), autonomous or semi-autonomous industrial applications (e.g., where URLLC traffic can be used together with eMBB or other large data packet traffic to control autonomous robots in a factory), or distributed sensing systems (e.g., where sensors send small mMTC data packets that overlap with eMBB or other large data packet traffic) can benefit from the examples disclosed herein.

[0165] Although the present application has described BS and UE as examples of sending and receiving nodes, it should be understood that other wireless communication devices can perform the functions of the sending and / or receiving nodes disclosed herein. For example, the present application can be implemented using BS, UE, autonomous devices, robots, drones, vehicles with wireless communication capabilities, satellites, smart appliances, etc.

[0166] Although the present application describes methods and processes by steps executed in a certain order, one or more steps in the methods and processes may be appropriately omitted or changed. Where appropriate, one or more steps may be executed in an order other than the described order.

[0167] Although the present application is described at least in part in terms of methods, those of ordinary skill in the art will understand that the present application also relates to various components for performing at least some aspects and features of the described methods, whether hardware components, software, or any combination of the two. Accordingly, the technical solutions of the present application may be implemented in the form of software products. A suitable software product may be stored in a pre-recorded storage device or other similar non-volatile or non-transitory computer-readable medium, including DVDs, CD-ROMs, USB flash drives, removable hard disks, or other storage media, etc. The software product includes instructions tangibly stored thereon that enable a processing device (e.g., a personal computer, server, or network device) to execute examples of the methods disclosed herein. The machine-executable instructions may be in the form of a code sequence, configuration information, or other data, which, when executed, cause a machine (e.g., a processor or other processing device) to perform the steps in the methods provided by the examples of the present application.

[0168] Without departing from the subject matter of the claims, the present application may be implemented in other specific forms. The described exemplary embodiments are illustrative in all respects and not restrictive. Features selected from one or more of the above embodiments may be combined to create alternative embodiments not explicitly described, and features suitable for such combinations may be understood to be within the scope of the present application.

[0169] All values and sub-ranges within the scope disclosed herein are disclosed. Additionally, although the systems, devices, and processes disclosed and illustrated herein may include a specific number of elements / components, these systems, devices, and components may be modified to include more or fewer such elements / components. For example, although any disclosed element / component may be a single quantity, the embodiments disclosed herein may be modified to include multiple such elements / components. The subject matter described herein is intended to cover and encompass all suitable technical variations.

Claims

1. A method performed in a sending node, characterized in that, Comprising: Obtaining a second data set belonging to a second transmission type to be sent to the same or a different intended receiving node during or before scheduling the transmission of a first data set belonging to a first transmission type to an intended receiving node; Multiplexing at least one bit of the first data set and at least one bit of the second data set to generate at least one multiplexed code block including information from the first and second data sets; Outputting the at least one multiplexed code block.

2. The method according to claim 1, wherein The first and second data sets are to be sent to the same intended receiving node, and the multiplexing the at least one bit of the first data set and the at least one bit of the second data set includes: Jointly encoding the at least one bit of the first data set and the at least one bit of the second data set into a jointly encoded codeword.

3. The method according to claim 1, characterized in that, The first and second data sets are to be sent to the same intended receiving node, and the multiplexing the at least one bit of the first data set and the at least one bit of the second data set includes: Scrambling the at least one bit of the first data set using a bit mask generated by the at least one bit of the second data set.

4. The method according to claim 1, characterized in that The first and second data sets are to be sent to the same intended receiving node, and the multiplexing the at least one bit of the first data set and the at least one bit of the second data set includes: Interleaving the at least one bit of the first data set using a permutation sequence generated by the at least one bit of the second data set.

5. The method according to any one of claims 2 to 4, characterized in that There are multiple multiplexed code blocks, and one or more bits of the second data set are multiplexed in each of the multiple multiplexed code blocks.

6. The method according to claim 1, characterized in that, The first and second data sets are to be sent to different intended receiving nodes, The multiplexing the at least one bit of the first data set and the at least one bit of the second data set includes: performing multilevel coding between the at least one bit of the first data set and the at least one bit of the second data set to obtain multilevel coding symbols; The outputting the at least one multiplexed code block includes: sending the multiplexed code block including the multilevel coding symbols to the different intended receiving nodes.

7. The method according to claim 6, wherein The performing multilevel coding includes: Mapping the at least one bit of the first data set and the at least one bit of the second data set to corresponding different levels; For each level, encoding one or more bits carried on the level into a corresponding codeword; Jointly mapping at least one code bit selected from each codeword to the multilevel coding symbols.

8. The method according to claim 1, characterized in that The first and second data sets are to be sent to different intended receiving nodes, The multiplexing the at least one bit of the first data set and the at least one bit of the second data set includes: performing mask repetition coding between the at least one bit of the first data set and the at least one bit of the second data set to obtain mask repetition coding symbols; The outputting the at least one multiplexed code block includes: sending the multiplexed code block including the mask repetition coding symbols to the different intended receiving nodes.

9. The method according to claim 8, characterized in that, The performing mask repetition coding includes: Generate a first codeword from the at least one bit of the first data set, wherein two or more copies of the first codeword are generated; Generate a second codeword from the at least one bit of the second data set; Mask the second codeword onto at least one copy of the first codeword, wherein the masked repeated coding symbols are generated by the at least one masked copy.

10. The method according to any one of claims 1 to 9, characterized in that Further includes: After all bits of the second data set have been sent, resume the scheduled transmission of the first data set.

11. The method according to any one of claims 1 to 10, characterized in that, Further includes: Send control information to at least one intended receiving node, wherein the control information includes information for decoding the at least one multiplexed code block.

12. The method according to claim 11, characterized in that Calculate an updated transport block size for the multiplexed code block, and the updated transport block size is included in the sent control information.

13. The method according to any one of claims 1 to 12, characterized in that, Further includes: Map the symbols of the at least one multiplexed code block to discontinuous resource units; After the mapping, send the at least one multiplexed code block.

14. The method according to any one of claims 1 to 13, characterized in that, The first data set belonging to the first transmission type is enhanced mobile broadband eMBB data, and the second data set belonging to the second transmission type is high-priority small packet data.

15. The method according to claim 14, wherein The high-priority small packet data is high-reliability low-latency communication URLLC data or massive machine communication mMTC data.

16. A method performed in a receiving node, characterized in that, Includes: Receive at least one multiplexed code block generated by multiplexing at least one bit of a first data set and at least one bit of a second data set to include information from the first and second data sets, the first data set belonging to a first transmission type and scheduled for the receiving node, and the second data set belonging to a second transmission type and intended for the same receiving node or a different receiving node; Decode at least the information from the first data set.

17. A method performed in a receiving node, characterized in that, Includes: Receive at least one multiplexed code block generated by multiplexing at least one bit of a first data set and at least one bit of a second data set to include information from the first and second data sets, the first data set belonging to a first transmission type and scheduled for the same receiving node or a different receiving node, and the second data set belonging to a second transmission type and intended for the same receiving node; Decode at least the information from the second data set.

18. A device, characterized in that, Includes a processing unit for causing the device to perform the method according to any one of claims 1 to 17.

19. A non-transitory computer-readable medium storing machine-executable instructions, characterized in that, When the processing unit of the device executes the instructions, the instructions cause the device to perform the method according to any one of claims 1 to 17.

20. A system, characterized in that, Includes: A sending node for sending at least one multiplexed code block generated by multiplexing at least one bit of a first data set and at least one bit of a second data set to include information from the first and second data sets, the first data set belonging to a first transmission type and scheduled for an intended receiving node, and the second data set belonging to a second transmission type and intended for the same receiving node or a different receiving node; A receiving node for receiving the at least one multiplexed code block and decoding at least one of the information from the first data set or the information from the second data set.

Images