Method and apparatus for broadcast, multicast or groupcast transmission using vertical check blocks

Abstract

The present application describes a two-dimensional (2D) encoding method and system for broadcast, multicast or groupcast applications. The method includes: sending two or more information code blocks (CBs) to multiple target receiving nodes; generating one or more cross-CB check blocks, wherein each cross-CB check block is generated according to a set of cross-CB bits, and the set of cross-CB bits includes at least one bit selected from each of at least two of the information CBs; sending at least one cross-CB check block to at least one of the multiple target receiving nodes.

Description

[0001] Cross-reference to related applications

[0002] This application claims priority to U.S. Provisional Patent Application No. 63 / 053,337, filed on July 17, 2020, entitled “METHODS AND APPARATUSES FOR BROADCAST MULTICAST OR GROUPCAST ​​TRANSMISSION USING VERTICAL CHECK BLOCKS”, and claims priority to U.S. Patent Application No. 17 / 368,500, filed on July 6, 2021, entitled “METHODS AND APPARATUSES FOR BROADCAST MULTICAST OR GROUPCAST ​​TRANSMISSION USING VERTICAL CHECKBLOCKS”, the entire contents of which are incorporated herein by reference. Technical Field

[0003] The present application relates to wireless communications, including the use of product coding in broadcast, multicast or groupcast wireless communications. Background Art

[0004] In typical cellular communications, unicast transmission is a common scenario. "Unicast" refers to a single sending node sending information to a single receiving node. Broadcast and multicast transmissions are increasingly used in cellular systems, for example in Multimedia Broadcast Multicast Service (MBMS). "Broadcast" refers to a single sending node sending information to all nodes connected to the sending node. "Multicast" refers to a single sending node sending information to multiple target receiving nodes. The applications of broadcast and multicast communications are constantly developing, especially multimedia services and vehicle to everything (V2X) communications.

[0005] V2X refers to a class of communication scenarios involving vehicles (acting as user equipment (UE)), including vehicle and another vehicle (V2V), vehicle to infrastructure (V2I), vehicle to pedestrian (V2P), and many other scenarios. Long term evolution-vehicle (LTE-V) is a standard that supports V2X communications using long term evolution (LTE) cellular technology. LTE-V focuses primarily on broadcast messages, such as safety messages. However, there is also interest in other applications. For example, New Radio (NR)-V2X based on NR cellular technology supports broadcast, multicast (which is a form of multicast between UEs), and unicast. Multicast and unicast applications can support feedback-based retransmissions, while broadcasts may only support blind retransmissions (i.e., retransmissions / repetitions without feedback). In broadcast, multicast, or multicast scenarios, the data received by each receiving node may have different errors. Existing retransmission schemes may not be suitable or efficient for broadcast, multicast or groupcast scenarios. Summary of the invention

[0006] In various examples, the present application describes methods and apparatus for physical (PHY) layer network coding based on two-dimension (2D) joint coding. The disclosed examples can be applicable to broadcast, multicast and groupcast transmissions and other applications.

[0007] Retransmission schemes used in traditional broadcast, multicast, and groupcast transmission methods suffer from inefficiency, high latency, and high overhead. These traditional retransmission schemes typically rely on retransmitting entire transport blocks or groups of code blocks in a highly redundant manner. Furthermore, retransmissions in broadcast, multicast, and groupcast scenarios further complicate the problem because different receivers may have different undecoded code blocks, which may require retransmission of entire transport blocks or groups of code blocks. Retransmissions based on outer erasure codes suffer from performance deficiencies when used in non-erased channels because undecoded code blocks are discarded without retaining soft information for joint decoding.

[0008] The embodiments of the present application use PHY layer network coding based on 2D joint coding to solve or improve some or all of these defects. Therefore, the method and apparatus provided by the present application can avoid the high cost and inefficient retransmission of traditional methods. In addition, the ability to use soft information generated by unsuccessful decoding attempts provides performance gains compared to retransmission schemes based on external erasure codes. In the examples described in this article, a single vertical check block can be multicast or broadcast to different receivers and used for decoding by different receivers, even if different receivers have different error code blocks in the initial transmission.

[0009] In one exemplary aspect, the present application describes a method. The method includes: sending two or more information code blocks (CBs) to multiple target receiving nodes; generating one or more cross-CB check blocks, wherein each cross-CB check block is generated according to a set of cross-CB bits, and the set of cross-CB bits includes at least one bit selected from each information CB in at least two of the information CBs; and sending at least one check block of the one or more cross-CB check blocks to at least one target receiving node among the multiple target receiving nodes.

[0010] In the above aspects of the method, the two or more information CBs can be sent to the multiple target receiving nodes in broadcast, multicast or groupcast transmission, and the at least one cross-CB check block can be sent to two or more target receiving nodes among the multiple target receiving nodes in broadcast, multicast or groupcast transmission.

[0011] In any of the above aspects of the method, the feedback of the multiple target receiving nodes may indicate whether the corresponding target receiving nodes successfully decoded the two or more information CBs. The method may also include: after determining that at least one of the multiple target receiving nodes failed to successfully decode the two or more information CBs based on receiving negative acknowledgement (NACK) feedback or no positive acknowledgement (ACK) feedback, sending the at least one cross-CB check block.

[0012] In any of the above aspects of the method, the corresponding one or more cross-CB check blocks may be sent in the corresponding retransmission for a predetermined number of retransmissions without requiring any feedback from any of the plurality of target receiving nodes for the initial transmission.

[0013] In any of the above aspects of the method, the method may further include: receiving an ACK feedback from at least one target receiving node after an initial transmission or a given retransmission. Any retransmission after the initial transmission or the given retransmission may not be sent to the at least one target receiving node that received the ACK feedback.

[0014] In any of the above aspects of the method, in the absence of negative acknowledgment (NACK) feedback, at least one of the one or more cross-CB check blocks can be repeatedly sent to the multiple target receiving nodes until positive acknowledgment (ACK) feedback is received from all of the multiple target receiving nodes.

[0015] In any of the above aspects of the method, the two or more information CBs may be sent to the multiple target receiving nodes in at least two separately sent data packets, and the one or more cross-CB check blocks may be generated based on bits selected from the CB of each of the at least two data packets.

[0016] In any of the above aspects of the method, the method may also include: sending a configuration signal or a control signal to the multiple target receiving nodes, wherein the configuration signal includes information about one or more parameters used to generate the one or more cross-CB check blocks. The configuration signal or the control signal may include information about one or more of the following: an indication of a new transmission or retransmission; a HARQ process identifier; a number of repetitions of retransmissions; a number of cross-CB check blocks sent; an index of the two or more information CBs used to generate the one or more cross-CB check blocks; an interleaver used to generate the one or more cross-CB check blocks; or an indication of how to generate a redundancy version (RV) or RV sequence of one or more cross-CB check blocks.

[0017] In any of the above aspects of the method, the method may further include: receiving a scheduling resource allocation for sending the two or more information CBs from a base station. Resources for sending the at least one cross-CB check block may also be allocated by the base station.

[0018] In the above aspects of the method, the method may also include: receiving feedback indicating whether at least one target receiving node failed to successfully decode at least one of the two or more information CBs; sending a negative acknowledgment NACK report to the base station; and receiving other scheduling resource allocations from the base station for sending the at least one cross-CB check block.

[0019] In any of the above aspects of the method, resources used for a predetermined number of cross-CB check block transmissions may also be allocated in the scheduling resource allocation of the base station.

[0020] In any of the above aspects of the method, the method may further include: selecting resources for sending the two or more information CBs from a resource pool. Resources for sending the at least one cross-CB check block may also be selected from the resource pool.

[0021] In one exemplary aspect, the present application describes an apparatus including a processing unit. The processing unit is configured to execute machine-readable instructions so that the apparatus performs the following operations: sending two or more information CBs to a plurality of target receiving nodes; generating one or more cross-CB check blocks, wherein each cross-CB check block is generated according to a set of cross-CB bits, wherein the set of cross-CB bits includes at least one bit selected from each information CB in at least two of the information CBs; and sending at least one check block of the one or more cross-CB check blocks to at least one target receiving node among the plurality of target receiving nodes.

[0022] In the above aspects of the device, the two or more information CBs can be sent to the multiple target receiving nodes in broadcast, multicast or groupcast transmission, and the at least one cross-CB check block can be sent to two or more target receiving nodes among the multiple target receiving nodes in broadcast, multicast or groupcast transmission.

[0023] In any of the above aspects of the device, the feedback of the multiple target receiving nodes may indicate whether the corresponding target receiving nodes successfully decoded the two or more information CBs. The processing unit may also be used to execute the instructions so that the device performs the following operations: after determining that at least one of the multiple target receiving nodes failed to successfully decode the two or more information CBs based on receiving negative acknowledgment NACK feedback or no positive acknowledgment ACK feedback, send the at least one cross-CB check block.

[0024] In any of the above aspects of the apparatus, corresponding one or more cross-CB check blocks may be sent in corresponding retransmissions for a predetermined number of retransmissions without requiring any feedback from any of the plurality of target receiving nodes for the initial transmission.

[0025] In any of the above aspects of the device, the processing unit may also be used to execute the instructions so that the device performs the following operations: sending a configuration signal or a control signal to the multiple target receiving nodes, wherein the configuration signal includes information about one or more parameters used to generate the one or more cross-CB check blocks. The configuration signal or the control signal may include information about one or more of the following contents: an indication of a new transmission or retransmission; a HARQ process identifier; the number of repetitions of retransmission; the number of cross-CB check blocks sent; an index of the two or more information CBs used to generate the one or more cross-CB check blocks; an interleaver used to generate the one or more cross-CB check blocks; or an indication of how to generate a redundant version RV or RV sequence of one or more cross-CB check blocks.

[0026] In any of the above aspects of the device, the processing unit can also be used to execute the instructions so that the device performs the following operations: receiving a scheduling resource allocation for sending the two or more information CBs from a base station. Resources for sending the at least one cross-CB check block can also be allocated by the base station.

[0027] In any of the above aspects of the device, the processing unit may also be used to execute the instruction so that the device performs the following operations: select resources for sending the two or more information CBs from a resource pool. Resources for sending the at least one cross-CB check block may also be selected from the resource pool.

[0028] In any of the above aspects of the apparatus, the processing unit may be configured to execute machine-readable instructions to cause the apparatus to perform any aspect of the above method.

[0029] In one exemplary aspect, the present application describes a computer-readable medium storing machine-executable instructions. When a processing unit in a device executes the instructions, the instructions cause the device to perform the following operations: send two or more information code blocks CB to multiple target receiving nodes; generate one or more cross-CB check blocks, wherein each cross-CB check block is generated according to a set of cross-CB bits, wherein the set of cross-CB bits includes at least one bit selected from each information CB in at least two of the information CBs; send at least one check block of the one or more cross-CB check blocks to at least one target receiving node among the multiple target receiving nodes.

[0030] In any aspect of the computer-readable medium, when a processing unit in a device executes the instructions, the instructions may cause the device to perform any aspect of the above method. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Reference will now be made by way of example to the accompanying drawings which show exemplary embodiments of the present application, in which:

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

[0033] Figure 2 and Figure 3 is a block diagram of an exemplary base station (BS) and an exemplary electronic device (ED) suitable for implementing the examples described herein;

[0034] Figure 4A and Figure 4B An exemplary code structure of a single transport block (TB) is shown, including a horizontal check block and a vertical check block;

[0035] Figure 5A and Figure 5B The use of different interleavers to generate multiple different sets of vertical check blocks is shown;

[0036] Figure 6 An exemplary code structure of a single TB based on a non-systematic code is shown, including a vertical check block;

[0037] Figure 7 An example code structure for generating a vertical check block from a plurality of TBs is shown;

[0038] Fig. 8A and Figure 8B is a signaling diagram for an example of broadcast, multicast or multicast transmission using vertical check blocks;

[0039] Figure 8C is based on Fig. 8A and Figure 8B A flowchart of an exemplary method that may be performed by a sending node;

[0040] Fig.8D and Fig. 8E Shown in Fig. 8A and 8B An example of a code block sent in an example of ;

[0041] Fig.9A and Fig. 9B is a flow chart of an exemplary method that may be performed by a sending node for acquiring transmission and retransmission resources in a multicast scenario;

[0042] Fig. 10A and Fig. 10B is a signaling diagram for an example of broadcast, multicast or groupcast transmission using vertical check blocks across packets;

[0043] Fig. 10C is based on Fig. 10A and Fig. 10B A flowchart of an exemplary method that may be performed by a sending node;

[0044] Fig. 10D and Fig. 10E Shown in Fig. 10A and Fig. 10B An example of a code block sent in an example of ;

[0045] Fig.11A is a flow chart of an exemplary method that may be performed by a transmitting node to include one or more vertical check blocks in an initial transmission;

[0046] Fig. 11B Shown in Fig.11A An example of a code block sent in the example of ;

[0047] Fig. 12A is a signaling diagram of an example of a broadcast, multicast or groupcast transmission involving multiple sending nodes;

[0048] Fig. 12B is based on Fig. 12A A flowchart of an exemplary method that may be performed by a sending node;

[0049] Fig. 12C Shown in Fig. 12A An example of a code block sent in the example of FIG.

[0050] Similar reference numerals may be used in different drawings to represent similar components. DETAILED DESCRIPTION

[0051] In various examples described herein, methods and apparatus for implementing HARQ-based retransmission or network coding are described. The examples described herein may help solve the difficulties in retransmission for broadcast, multicast, or groupcast transmissions. For example, in broadcast, multicast, or groupcast transmissions, there may be reception errors in different code blocks at each receiving node, and the transmission channel is typically not an erasure channel.

[0052] To help understand the present application, some existing retransmission methods are described below.

[0053] Hybrid automatic repeat request (H-ARQ / HARQ) is a common feature of wireless physical layer retransmissions. Typical HARQ implementations include the use of retransmissions based on incremental redundancy (IR), which sends additional bits from the mother code that were not sent when the initial transmission failed. In other words, the mother code is stored in a circular buffer, and after sending an initial code block including bits from the mother code as part of the HARQ process, the transmitter sends new IR bits from the circular buffer. The new IR bits form a new code block together with the previously sent data. This operation is repeated until the maximum number of retransmissions is reached or the code block is successfully decoded.

[0054] HARQ retransmission schemes include feedback-based retransmission schemes and blind retransmission schemes. In feedback-based retransmission, the receiving node must send back an acknowledgement (ACK) or a negative acknowledgement (NACK) to the sending node. If NACK is received, a retransmission is sent. In blind retransmission, the ACK / NACK response of the receiving node is optional. The sending node instead sends a predetermined number of retransmissions. For multicast SL transmission, there may be different options for the receiving node to send ACK / NACK. In one option, the receiving node only sends NACK (no ACK is sent upon successful reception). All receiving nodes share the same physical sidelink feedback channel (PSFCH) resources, resulting in the sending node possibly not knowing which receiving node sent which NACK. In another option, each receiving node has its own dedicated PSFCH resource to send ACK / NACK feedback.

[0055] Various retransmission schemes based on forward error correction (FEC) have been considered in broadcast or multicast transmission. Some existing methods are introduced below.

[0056] A fountain code is a rateless code. Fountain codes are suitable for broadcast or multicast transmissions without feedback. Traditional Multimedia Broadcast Multimedia Service (MBMS) systems use Athlon codes (which is an implementation of fountain codes) for FEC in the application layer without the need for HARQ retransmissions or HARQ feedback. However, fountain codes are used for high-level feedback, not for low layers of the protocol stack (e.g., transport blocks or code blocks on the physical (PHY) layer). Compared with technical solutions using PHY layer retransmissions, fountain codes have longer delays in retransmissions and are therefore not suitable for low-latency applications. In addition, fountain codes are erasure codes, so performance is degraded for transmissions in non-erasure channels.

[0057] Another existing method is erasure outer code. In erasure outer code, parity check code blocks are generated based on multiple code blocks for HARQ retransmission. Parity check code blocks can be used to correct different erased information code blocks. However, for transmission on non-erasure channels, performance will be reduced because undecoded code blocks are completely discarded. This means that each parity check code block can only correct one undecoded code block.

[0058] To help understand the present application, an exemplary wireless communication system is first described.

[0059] Figure 1 An exemplary wireless communication system 100 (also referred to as wireless system 100) in which embodiments of the present application may be implemented is shown. In general, 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., by broadcast, narrowcast, user device to user device, 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).

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

[0061] ED 110 is used to operate and / or communicate in the wireless system 100. For example, ED 110 can be used to send and / or receive messages through a wireless or wired communication channel. Each ED 110 represents any suitable terminal user device that performs wireless operations, and may include (or may be referred to as): user equipment (UE), wireless transmit / receive unit (WTRU), mobile station, mobile relay, fixed or mobile user unit, cellular phone, station (STA), machine type communication (MTC) device, personal digital assistant (PDA), smart phone, laptop, computer, tablet, wireless sensor, Internet of things (IoT) device, network-enabled vehicle or consumer electronic device, etc. The next generation of ED 110 may be referred to using other terms.

[0062] exist Figure 1 In the example, RAN 120 includes a base station (BS) 170. Figure 1Each RAN 120 is shown to include a corresponding BS 170, but it should be understood that any given RAN 120 may include more than one BS 170, 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 BS 170 is used to wirelessly connect to one or more EDs 110 to enable access to any other BS 170, core network 130, PSTN 140, Internet 150 and / or other networks 160. For example, BS 170 may also be referred to as (or include) a base transceiver station (BTS), a wireless base station, a 3G base station (NodeB), an evolved NodeB (eNodeB or eNB), a Home eNodeB, a gNodeB (gNB) (sometimes referred to as a next generation NodeB), a transmission point (TP), a transmission / reception point (TRP), a site controller, an access point (AP) or a wireless router, etc. The next generation BS 170 may be referred to using other terms. Any ED 110 may alternatively or additionally be used to connect, access or communicate with any other BS 170, the Internet 150, the core network 130, the PSTN 140, other networks 160, or any combination thereof. In some examples, BS 170 may access the core network 130 via the Internet 150.

[0063] ED 110 and BS 170 are examples of communication devices that can be used to implement some or all of the functions and / or embodiments described herein. Any BS 170 can be a single element as shown, or multiple elements distributed in a corresponding RAN 120, and so on. Each BS 170 sends and / or receives wireless signals within a specific geographic area or region (sometimes referred to as a "cell" or "coverage area"). The cell can be further divided into cell sectors, for example, BS 170 can use multiple transceivers to provide services to multiple sectors. In some embodiments, there may be established micro cells or femto cells supported by wireless access technology. A macro cell may include one or more smaller cells. In some embodiments, multiple transceivers can be used for each cell using multiple-input multiple-output (MIMO) technology, etc. The number of RAN 120 shown is exemplary only. Any number of RANs can be considered when designing the wireless system 100.

[0064] The BS 170 communicates with one or more EDs 110 via one or more uplink (UL) / downlink (DL) wireless interfaces 190 (e.g., via radio frequency (RF), microwave, infrared (IR), etc.). The UL / DL interface 190 may also be referred to as a UL / DL connection, an ED-BS link / connection / interface, or an ED-network link / connection / interface, etc. The EDs 110 may also communicate directly with each other (i.e., without involving the BS 170) via one or more sidelink (SL) wireless interfaces 195. The SL interface 195 may also be referred to as a 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, an ED-ED link / connection / interface, a device-to-device (D2D) link / connection / interface, or simply SL, etc. The wireless interfaces 190 and 195 may use any suitable wireless access technology. For example, the wireless system 100 may implement one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), or single-carrier FDMA (SC-FDMA), for wireless communication.

[0065] The RAN 120 communicates with the core network 130 to provide various services, such as voice, data, and other services to the ED 110. 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 ED 110 or both and (ii) other networks (e.g., the PSTN 140, the Internet 150, and other networks 160). In addition, part or all of the ED 110 may include the functionality to communicate with different wireless networks over different wireless links using different wireless technologies and / or protocols. The ED 110 may communicate with a service provider or switch (not shown) and with the Internet 150 over a wired communication channel instead of wireless communication (or also wireless communication). 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 may include protocols such as Internet Protocol (IP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), etc. The ED 110 may be a multi-mode device capable of operating according to a variety of wireless access technologies, and may include a plurality of transceivers required to support these technologies.

[0066] Figure 2 and Figure 3 Exemplary apparatus are shown that can implement the various methods and teachings provided herein. Figure 2 and Figure 3 Different possible embodiments of ED 110 and BS 170 are shown and are not intended to be limiting.

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

[0068] The device (e.g., ED 110 or BS 170) includes at least one communication interface 202 for wired communication and / or wireless communication. Each communication interface 202 includes any suitable structure for generating signals for wireless transmission or wired transmission and / or for processing signals received wirelessly or wired. The device in this example includes at least one antenna 204 (in other examples, antenna 204 may be omitted). Each antenna 204 includes any suitable structure for sending and / or receiving wireless signals or wired signals. One or more communication interfaces 202 may be used in the device. One or more antennas 204 may be used in the device. In some examples, one or more antennas 204 may be antenna arrays 204, which may be used to perform beamforming and beam steering operations. Although the device is shown as a separate functional unit, the device may also be implemented using at least one transmitter interface and at least one separate receiver interface.

[0069] The device (e.g., ED 110 or BS 170) also includes one or more input / output devices 206 or input / output interfaces (e.g., a wired interface connected to the Internet 150). One or more input / output devices 206 can interact with users or other devices in the network. Each input / output device 206 includes any suitable structure for providing information to a user or receiving information from a user, such as a speaker, a microphone, a keypad, a keyboard, a display, or a touch screen, including network interface communications.

[0070] In addition, the device (e.g., ED 110 or BS 170) includes at least one memory 208. The memory 208 stores instructions and data used, generated or collected by the device. For example, the memory 208 can store software instructions or modules for implementing some or all of the functions and / or embodiments described herein and executed by one or more processing units 201. Each memory 208 includes any suitable one or more volatile and / or non-volatile storage and retrieval devices. Any suitable type of memory can 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) card, etc.

[0071] like Figure 3As shown, another exemplary device (e.g., another exemplary embodiment of ED 110 or BS 170) includes at least one processing unit 250, at least one transmitter 252, at least one receiver 254, one or more antennas 256, at least one memory 258, and one or more input / output devices or interfaces 266. The processing unit 250 implements various processing operations of the device, such as signal encoding, data processing, power control, input / output processing, or any other function. The processing unit 250 can also be used to implement some or all of the functions and / or embodiments described herein. Each processing unit 250 includes any suitable processing or computing device for performing one or more operations. For example, each processing unit 250 may include a microprocessor, a microcontroller, a digital signal processor, a field programmable gate array, or an application-specific integrated circuit.

[0072] Each transmitter 252 includes any suitable structure for generating signals for wireless or wired transmission. Each receiver 254 includes any suitable structure for processing signals received wirelessly or wired. Although at least one transmitter 252 and at least one receiver 254 are shown as separate components, they can be combined into a transceiver. Each antenna 256 includes any suitable structure for sending and / or receiving wireless or wired signals. Although a common antenna 256 is shown coupled to both the transmitter 252 and the receiver 254, one or more antennas 256 can be coupled to one or more transmitters 252, and one or more separate antennas 256 can be coupled to one or more receivers 254. In some examples, one or more antennas 256 can be antenna arrays, which can be used for beamforming and beam steering operations. Each memory 258 includes any suitable one or more volatile and / or non-volatile storage and retrieval devices, such as those described above in conjunction with Figure 2 The memory 258 stores instructions and data used, generated or collected by the device. For example, the memory 258 may store software instructions or modules for implementing some or all of the functions and / or embodiments described herein and executed by one or more processing units 250.

[0073] Each input / output device / interface 266 can interact with users or other devices in the network. Each input / output device / interface 266 includes any suitable structure for providing information to a user or receiving / providing information from a user, including network interface communications.

[0074] The technology of jointly encoding multiple code blocks (CB) in a single transport block (TB), including generating vertical check blocks, has been described in U.S. patent application No. 16 / 665,121, filed on October 28, 2019, and entitled “SYSTEM AND METHOD FOR HYBRID-ARQ”, the entire contents of which are incorporated by reference in this application.

[0075] Figure 4A An exemplary code structure of a single TB is shown, including a horizontal check block and a vertical check block. TB 402 includes a plurality of information blocks 404 formed by encoder input bits (in this example, four information blocks 404 are shown for simplicity, but this is not intended to be limiting). Encoder input bits may also be referred to as information bits. The bits in this example are arranged in L rows and K columns. The code structure also includes a horizontal check block 406 (in this example, each information block 404 corresponds to a horizontal check block 406) and vertical check blocks 1 408-1 to vertical check blocks 4 408-4 (collectively referred to as one or more vertical check blocks 408). In this example, four vertical check blocks 408 are shown for simplicity, but this is not intended to be limiting. The number of vertical check blocks 408 to be used may depend on the configuration of the transmitter (e.g., BS 170 for downlink (DL) transmission, or ED 110 for uplink (UL) transmission or SL transmission) and / or be defined by the standard. In addition, the number of vertical check blocks 408 may or may not be equal to the number of horizontal check blocks 406. Each row in the code includes n1 bits, which include k1 encoder input bits (or information bits) (in one information block 404), and the corresponding horizontal check block 406 includes n1-k1 check bits. In the present application, the check bits may also be referred to as redundant bits, or in some examples (for example, in the case of systematic codes) as parity check bits.

[0076] Each information block 404 and the corresponding horizontal check block 406 can be regarded as n1 bits of information CB 410, wherein TB402 includes a plurality of information CB 410. Figure 4A In the example of , information CB 410 is a systematic CB because they both include systematic bits (in information block 404) and parity bits determined from the systematic bits (in horizontal parity block 406). In other examples (described further below), information CB 410 may be a non-systematic CB.

[0077] Each vertical check block 408 is generated based on k2 encoder input bits (or information bits) (also called cross-information block bits, cross-CB bits, or simply cross-block bits) selected across multiple information blocks 404. The k2 cross-block bits include M encoder input bits for each information CB in L information CBs 410, where M≥1, so that k2=M×L. In other words, the k2 cross-block bits include bits for one of the K columns, and each column is M bits wide. In some examples, the k2 cross-block bits may include a different number of information bits obtained from each information CB 410. This can be mathematically expressed as: k2=M1+…+M L , where M i is the number of information bits obtained from each of the L information CBs 410, M i >0; when p≠q, M is not required p =M q .

[0078] In the present application, reference is made to "horizontal" (such as in horizontal check block 406) and "vertical" (such as in vertical check block 408). These terms are intended to facilitate understanding of the layout in some drawings and to distinguish between two types of check blocks. However, these terms do not imply any physical structure. In general, the descriptors "horizontal" and "vertical" can be equivalently replaced by "first" and "second". For example, horizontal check block 406 and vertical check block 408 can be simply referred to as a first check block and a second check block. Specifically, each second (or vertical) check block is generated based on information bits selected from two or more information CBs 410. Horizontal CBs may also be referred to as information CBs. For ease of understanding, the present application uses the terms "horizontal" and "vertical" instead of "first" and "second", but this is not intended to be limiting.

[0079] Figure 4B Another exemplary code structure of a single TB is shown, including a horizontal check block and a vertical check block. Figure 4B The example shown in Figure 4A Similar to the example in , so Figure 4A Similar features to those in the examples are not described again. Figure 4BIn the example of , in addition to the vertical check blocks 1 408-1 to 4 408-4 described above, the code structure also includes vertical check blocks 5 408-5 to 7 408-7 (vertical check blocks 1 408-1 to 7 408-7 may be collectively referred to as one or more vertical check blocks 408). Vertical check blocks 5 408-5 to 7 408-7 are similar to vertical check blocks 1 408-1 to 4 408-4, except that vertical check blocks 5 408-5 to 7 408-7 are generated using bits selected from multiple horizontal check blocks 406 (rather than bits selected from multiple information blocks 404). In this way, the bits in vertical check blocks 5 408-5 to 7 408-7 may be referred to as "check on check" bits.

[0080] Figure 4A and Figure 4B Bits are shown arranged in rows and columns and have been described using this structure. For example, vertical check block 408 has a rectangular / two-dimensional structure. However, this is for illustration only and is not intended to limit how bits may be arranged logically or in transmission. In addition, Figure 4A and Figure 4B The code structure shown can be divided for transmission (as described in detail below). Typically, all bits in a vertical check block 408 are sent in the same transmission.

[0081] The check bits included in the horizontal check block 406 and the vertical check block 408 assist the receiver in decoding. For example, after each decoding attempt (with the check bits present) of the decoder, an error check may be performed to determine whether the information CB 410 has been successfully decoded. The vertical check block 408 includes check bits determined across multiple information CBs 410, thus providing information useful for decoding multiple information CBs 410. The decoder may use the check bits in the vertical check block 408 to assist in decoding the information CB 410.

[0082] In transmission, information CB 410 (sent and including corresponding horizontal check block 406) may be sent in an initial transmission. As discussed further below, vertical check block 408 may also be sent with information CB 410 in an initial transmission or in a separate transmission (which may be referred to as a retransmission). Although a retransmission may include only non-systematic coded bits in one or more vertical check blocks 408, a retransmission may also include some systematic bits (i.e., information bits) associated with one or more vertical check blocks 408 in the retransmission.

[0083] In an example where the information CB 410 is a systematic code (e.g., a low density parity check (LDPC) code or a Turbo code), the received CB can be decoded using an iterative decoding process at the decoder (at the receiver). The decoder calculates the log-likelihood ratio (LLR) of the bit values ​​during the decoding process of the information CB, which can be considered a "soft" output of the decoder. In the present application, a soft output can refer to a decoder output that has not yet been finalized (e.g., a bit value that has not yet been clearly determined to be 1 or 0) but can provide information that is still useful (e.g., in a subsequent decoding iteration). Such a soft output may be probabilistic in nature (e.g., an LLR). Processing the vertical check block 408 can help decode information CB 410 that is not correctly decoded (e.g., a check failure using the corresponding horizontal check block 406). Since vertical check block 408 is generated based on information bits selected from two or more (or all) information CBs 410, the soft output (e.g., LLR) generated by attempting to decode vertical check block 408 can help improve the decoding of information CB 410 (and vice versa). In at least this way, vertical check block 408 helps improve decoding.

[0084] Reference below Figure 5A and Figure 5B . As described above, the vertical check block 408 is determined based on the cross-block bits selected from the information CB 410. For a given vertical check block 408, the cross-block bits may include information bits obtained from different columns of different information CBs 410. For example, the cross-block bits may include input bits obtained from the x column of the first information CB 410, the y column of the second information CB 410, and the z column of the third information CB 410, where x, y, and z are different. Considering from another perspective, it can be considered that the cross-block bits used to generate the vertical check block 408 can be selected by obtaining the bits of the vertical column after the bits in the information row are optionally shuffled (also known as row-by-row shuffling). This row-by-row shuffling of information bits can also be called interleaving or row-by-row interleaving. A predefined shuffling scheme or a predefined interleaver can be used to perform this shuffling. The present application describes the use of an interleaver to perform this row-by-row reordering of information bits to generate different vertical check blocks 408. An interleaver can be a predefined algorithm or a predefined matrix (etc.) applied to a row of bits to obtain a row of reordered bits. It should be understood that other techniques (not necessarily limited to interleaving) may be used.

[0085] For example, Figure 5A4. The TB 402 includes four information CBs 410, wherein the information block 404 in each information CB 410 has been divided into four sub-blocks, for a total of 16 sub-blocks, denoted as IB1, IB2, ..., IB. 16 . Figure 5A The consecutive indices of the sub-blocks shown represent the natural order of the information bits in each information CB 410 (e.g., the order as output by the encoder). Figure 5A In the example above, no row shuffling is performed.

[0086] Instead, consider Figure 5B In this example, the information bits have been shuffled in at least one row (in Figure 5B 4). It can be seen that in the first row, the order of the sub-blocks is not changed, but in the second, third and fourth rows, the order is changed. It is worth noting that the specific sub-blocks belonging to each horizontal CB 410 are unchanged, only the order of the sub-blocks within each information CB 410 is changed. This means that the shuffling does not affect the horizontal check block 406 of each corresponding information CB 410. However, Figure 5B The vertical check block 408 in Figure 5A The vertical check block 408 in is different. Figure 5A The vertical check blocks 408 in the figure can be considered as the first group of vertical check blocks 408. Figure 5B The vertical check blocks 408 in can be considered as the second group of vertical check blocks 408.

[0087] Whether to perform shuffling and how the encoder input bits are shuffled in each row may be configured in the transmitter (e.g., BS 170 or ED 110) and / or defined by the standard. It is understood that shuffling the information bits using different interleavers may result in different sets of vertical check blocks 408 (e.g., as described above in Figure 5A and Figure 5B In some examples, multiple different sets of vertical check blocks 408 can be generated based on the same TB 402, which can help provide additional information for decoding purposes. For example, multiple different sets of vertical check blocks 408 can be generated for different retransmission attempts.

[0088] Although Figure 4A , Figure 4B , Figure 5A and Figure 5B A code structure based on a systematic code is shown, but this is only illustrative. The present application is not limited to systematic codes, and non-systematic codes are also applicable. In addition, although the present application describes an example of using vertical check block 408 in the context of multicast, groupcast, and broadcast transmission / retransmission, it should be understood that Figure 4A , Figure 4B , Figure 5A and Figure 5B The code structure shown may also be applicable to unicast transmission / retransmission, etc.

[0089] Figure 6 An exemplary code structure for a single TB based on a non-systematic code (e.g., polar code, block code, or convolutional code) is shown. Each non-systematic codeword is determined based on a set of encoder input bits, but the encoder input bits do not appear in the codeword as systematic bits. Unlike systematic codes, horizontal check bits cannot be simply appended at the end of each row.

[0090] TB 602 includes a plurality of non-systematic codewords 604. Each non-systematic codeword 604 can be regarded as information CB 610. Figure 4A , Figure 4B , Figure 5A and Figure 5B Unlike the example in FIG. 6 , the information CB 610 does not include different horizontal check blocks. Each vertical check block 608 is generated by obtaining one or more columns of bits across multiple information CBs 610, similar to Figure 4A and 4B described.

[0091] Those skilled in the art will appreciate that the following detailed discussion does not depend on whether the vertical check block is generated based on the system CB or the non-system CB. For simplicity, the following may refer to and use references to the system CB-based Figure 4A and Figure 4B It should be understood that this is not intended to be limiting.

[0092] In the present application, the vertical check block may also be referred to as a cross-block check block, because the bits used to generate each vertical check block are obtained across multiple information blocks. Similarly, generating horizontal check blocks may be referred to as block-by-block (or block-specific) coding, because the bits used to generate each horizontal check block are obtained from all bits of a single information block. Generating vertical check blocks may be referred to as two-dimensional (2D) coding, where 2D refers to generating vertical check blocks (and horizontal check blocks in the case of systematic codes). The terms "parity check block" or "redundancy block" may also be substituted for "check block". For ease of understanding, the following discussion relates to vertical check blocks and horizontal check blocks, but it should be understood that the terms "vertical" and "horizontal" are not intended to imply any physical structure or to limit.

[0093] The previous discussion describes the generation of a vertical check block based on cross-block bits in a single TB. A vertical check block can also be generated based on cross-block bits in two or more TBs (e.g., TBs sent as separate packets by a single source). To help understand this further application, a discussion on network coding is provided.

[0094] Network coding is a network technology in which transmitted data is encoded and decoded to help improve network throughput, help reduce latency and / or help improve the robustness of wireless networks. Network coding enables two data packets to be combined (using a specific defined algebraic algorithm, such as a bit-by-bit X-OR operation) and the cumulative message to be sent to the destination, rather than treating the two data packets as different, discrete units of information (as in traditional network routing). At the destination, the cumulative message is decoded (using the same defined algorithm). The two data packets combined in this way can come from two different sending nodes, or from two different sending sources from the same source or different sources (for example, two different antennas, two different transmitters, or two different communication interfaces). The two data packets can be sent to the same destination or two different destinations (for example, two different receiving devices). In the case where two data packets are sent to two different destinations, additional information can be used at each destination in order to decode and obtain data packets that are only sent to that destination.

[0095] When vertical check blocks are used with network coding, a given vertical check block is generated from bits obtained across two or more CBs or two or more data packets (which may be from a single TB or multiple TBs).

[0096] Figure 7 Shown with Figure 4A and Figure 4B An exemplary code structure similar to the code structure in Figure 4A and Figure 4B The difference is, Figure 7 The structure in includes multiple TBs, namely TB-1 402-1 and TB-2 402-2 in this example (collectively referred to as one or more TBs 402). It should be noted that one or more TBs 402 are not necessarily sent in the same transmission. In this example, two TBs 402 are shown for simplicity, but this is not intended to be limiting. TB-1 402-1 includes encoder input bits forming information blocks 404-1 arranged in rows (in this example, two information blocks 404-1 are shown for simplicity, but this is not intended to be limiting), and TB-2 402-2 includes encoder input bits forming information blocks 404-2 arranged in rows (in this example, two information blocks 404-2 are shown for simplicity, but this is not intended to be limiting). Information blocks 404-1 and 404-2 can be collectively referred to as one or more information blocks 404. It should be noted that the number of information blocks 404 in each TB 402 is not necessarily the same. In this example, a systematic code is shown, and a horizontal check block 406 is generated from each information block 404. In an example using a non-systematic code, there may not be any horizontal check blocks 406 different from the information blocks 404.

[0097] Vertical check blocks 1 408-1 to vertical check blocks 4 408-4 (collectively referred to as vertical check blocks 408) are generated using one or more columns of bits obtained across all information blocks 404 (and therefore across all TBs 402). That is, each vertical check block 408 is generated based on a set of bits including at least one bit in each information block 404 of each TB 402. In this example, four vertical check blocks 408 are shown for simplicity, but this is not intended to be limiting. The number of vertical check blocks 408 to be used may depend on the configuration of the transmitter (e.g., BS 170 for DL ​​transmission, or ED110 for UL transmission or SL transmission) and / or be defined by the standard. In addition, the number of vertical check blocks 408 may or may not be equal to the number of horizontal check blocks 406.

[0098] Similar to the above combination Figure 5A , Figure 5B and Figure 6 As discussed above, the vertical check blocks 408 generated across multiple TBs 402 can be generated based on information bits arranged in a natural order or based on shuffled (or interleaved) bits. Multiple sets of vertical check blocks 408 can be generated for the same set of TBs 402 using different interleavers (e.g., for different retransmissions). The vertical check blocks 408 can be generated for systematic codes or non-systematic codes.

[0099] The information CB 410 may come from a source, which may be a network node (e.g., BS 170 or ED 110) or a transmitting device in a network node (e.g., a transmitting antenna or a transmitter chain). In general, the term "network node" in this application may refer to any transmitting and / or receiving node (including a relay node) in a wireless network, and may include an end node (e.g., a terminal device such as ED 110) and a node further away in the uplink (e.g., BS 170 or a relay node). Those skilled in the art will appreciate that other variations may be used within the scope of this application.

[0100] Each TB may include a corresponding number of information CBs. In the present application, the information CB may be simply referred to as a CB. In some examples, the vertical check block may be generated using bits selected from all CBs of the TB (e.g., using an interleaver). In other examples, the vertical check block may be generated using bits selected from at least two but not all CBs of the TB. For example, a given interleaver may indicate that bits are selected from not all CBs (e.g., bits are selected only from CBs that the receiving node has not successfully decoded) to generate a vertical check block.

[0101] The present application describes a method and apparatus for performing multicast, broadcast or groupcast transmission using 2D coding. Specifically, one or more vertical check blocks in multiple CBs are retransmitted instead of retransmitting each CB individually. Compared with existing retransmission schemes, the examples disclosed in this article improve performance, such as reducing latency, reducing overhead or improving decoding efficiency.

[0102] In this application, the first transmission of a TB or data packet, referred to as an initial transmission, includes sending a CB (including one or more horizontal check blocks in the case of a system code) from a sending node to a receiving node. Subsequent transmissions associated with the same TB or data packet, referred to as retransmissions of the TB or data packet, include sending one or more vertical check blocks from the sending node to the receiving node. It should be noted that in some examples discussed herein, the initial transmission may include one or more vertical check blocks.

[0103] Since the vertical check block is generated using bits from multiple CBs, retransmission of one vertical check block can provide information to help decode multiple CBs. At the receiving node, the soft information generated by failed decoding attempts can be retained and combined with the information in the vertical check block to help decode multiple CBs. The ability to use soft information generated by unsuccessful decoding attempts provides significant performance gains compared to outer erasure codes and fountain codes. This also means that a single vertical check block can be multicast or broadcast to different receivers and used for decoding by different receivers, even if the different receivers have different erroneous CBs in the initial transmission.

[0104] Compared to conventional TB or CB group based HARQ, the examples described in this application may help reduce the redundancy and feedback required for retransmissions in broadcast or multicast.The examples disclosed herein may be implemented in feedback based schemes as well as rateless codes.

[0105] The following describes an example of using a vertical check block in a broadcast, multicast or multicast transmission application. The following example uses a certain number of participating entities (e.g., source, transmitter, destination, relay node, terminal device, UE, etc.) to describe and illustrate. The specific number shown is not intended to be limiting. For example, there may be any number of entities shown in multiple (e.g., two or more). Although not discussed in detail, different interleavers can be used to generate different vertical check blocks for HARQ retransmission.

[0106] In the examples disclosed herein, one or more retransmissions performed by a transmitter (or transmitting node) (Tx) may depend on predetermined parameters. The parameters used to perform retransmissions include: the number of retransmissions to be performed (which may be predetermined), the interleaver used to generate the corresponding vertical check block, the number of vertical check blocks included in each retransmission, and the like. The retransmission parameters may be predefined (e.g., defined in a standard), semi-statically configured (e.g., configured by high-level signaling such as radio resource control (RRC) signaling). In the example where Tx is ED 110, the retransmission parameters may be semi-statically indicated (e.g., configured authorization) or dynamically indicated (e.g., dynamic scheduling) by configuration signaling of BS 170. The semi-static configuration may be indicated by high-level signaling such as radio resource control (RRC) signaling. The dynamic indication may be indicated by physical layer (or layer 1) signaling such as downlink control information (DCI) transmission.

[0107] In order for the receiving node to correctly use the vertical (and horizontal) check blocks for decoding, the receiver (or receiving node) (Rx) also needs to understand how to generate the vertical check blocks. Information about the parameters for generating one or more vertical check blocks (also called vertical check block parameters) can be indicated to each Rx before, in, with, or immediately after the retransmission. If the Tx is BS 170, the information about the parameters for generating one or more vertical check blocks can be indicated in DCI or RRC, for example, similar to the description above. If the Tx is ED 110, the information about the vertical check block parameters can be indicated to other receiving ED 110 via sidelink RRC or PC5-RRC (in the case of semi-static configuration parameters) or via sidelink control information (SCI) on the sidelink control channel (in the case of dynamic indication parameters). If Tx is ED 110, and the transmission from Tx to Rx (which may be another ED 110) is scheduled by the network (or BS 170), information about the vertical check block parameters may also be indicated to Tx from BS 170, which may be semi-static (e.g., in RRC) or dynamic (e.g., in DCI). In other examples, the Tx ED may select some or all of the vertical check block parameters, in which case the information may not need to be transmitted / scheduled by the network / BS 170 to the Tx ED.

[0108] The information that needs to be indicated includes: a New Data Indicator (NDI) for indicating whether the transmission is a new (initial) transmission or a retransmission; a HARQ process ID for identifying a group of transmissions / retransmissions belonging to the same HARQ process; a predetermined number of repetitions / blind retransmissions (if applicable); and parameters for generating vertical check blocks. Exemplary vertical check block parameters that need to be indicated include: the number of vertical check blocks sent for each retransmission; the index of the CB used to generate the vertical check block and the number of CBs (which can be omitted if all CBs are used to generate vertical check blocks); an interleaver for generating vertical check blocks; and which bits / sub-blocks in each CB are used to generate vertical check blocks. In some examples, the parameters for generating one or more vertical check blocks for a given retransmission may be predefined based on the redundancy version (RV) of the retransmission, in which case the signaling may indicate the RV of the retransmission. The RV index or RV sequence corresponding to multiple transmissions / retransmissions of a TB may also be indicated. Information about one or more interleavers used to generate one or more vertical check blocks may be sent using a (random number generating) seed (or index) of one or more interleavers from a set of preconfigured and known (eg, standard defined) available interleavers.

[0109] Any of the above information may be predefined in a standard and / or preconfigured in a network system / device so that both the sending node and the receiving node are aware of the information. In some examples, different options or parameter values ​​may be defined by a standard, and signaling (e.g., RRC, PC5-RRC, DCI, or SCI) may be used to indicate (e.g., by referencing an index value) a specific option or parameter value to be used. Different types of signaling (e.g., RRC, PC5-RRC, DCI, or SCI) may be used to indicate short-term changes (e.g., selecting a specific interleaver to be used) or long-term changes (e.g., changing the number of scheduled retransmissions).

[0110] In some examples, the present application may refer to TBs or data packets. It should be understood that discussions in the context of TBs may similarly apply to data packets (and vice versa).

[0111] Fig. 8A is a signaling diagram of an example of using vertical check blocks in a feedback-based retransmission scheme. Fig. 8A (and other examples disclosed herein) are described in the context of transmission to multiple receiving nodes (e.g., multicast, broadcast, or groupcast transmission), but the signaling described herein (including configuration signaling or control signaling) may also be applicable to unicast transmission (i.e., transmission to a single receiving node). Fig. 8AIn the example, a transmitting node 12 (denoted as Tx 12) transmits to multiple receiving nodes (denoted as Rx-1 14-1, Rx-2 14-2 and Rx-3 14-3, collectively referred to as Rx 14). The transmission of Tx12 can be multicast, broadcast or groupcast transmission. Tx12 can be BS 170 (for example, for broadcast or multicast DL transmission to ED 110) or ED 110 (for example, for multicast SL transmission to other ED 110). In some examples, if Tx12 is ED 110, one of the Rx14 can be BS 170 (for example, UL transmission) and the other Rx14 can be other ED 110. Tx 12 may send a configuration signal or control signal to Rx 14 (e.g., before an initial transmission, before a retransmission, in a retransmission, together with a retransmission, or immediately after a retransmission) to provide information about parameters for generating a vertical check block, but this is not shown in the figure. Such information may be necessary for Rx 14 to use the vertical check block to assist in decoding. For example, Tx 12 may send control information including vertical check block parameters in sidelink control information (SCI). The SCI may be sent in a physical sidelink control channel (PSCCH) associated with data transmission in a physical sidelink shared channel (PSSCH), or the SCI may be sent in a PSSCH together with data transmission. Rx 14 may first decode the SCI to obtain control information including vertical check block parameters, and then use the obtained control information to further decode the data. The information included in the configuration signal or control signal may include, for example, an NDI for indicating whether a transmission is a new (initial) transmission or a retransmission; a HARQ process ID for identifying a group of transmissions / retransmissions belonging to the same HARQ process; a predetermined number of repetitions / blind retransmissions (if applicable); and parameters for generating vertical check blocks. Exemplary vertical check block parameters that need to be indicated include: the number of vertical check blocks sent for each retransmission; the index of the CB used to generate the vertical check block and the number of CBs (which may be omitted if all CBs are used to generate the vertical check block); the interleaver used to generate the vertical check block; which bits / sub-blocks in each CB are used to generate the vertical check block. In some examples, the parameters for generating one or more vertical check blocks for a given retransmission may be predefined based on the RV of the retransmission, in which case the signaling may indicate the RV of the retransmission. The RV index or RV sequence corresponding to multiple transmissions / retransmissions of a TB may also be indicated.Information about one or more interleavers used to generate one or more vertical check blocks may be sent using a seed (or index) of one or more interleavers from a set of preconfigured and known (eg, standard-defined) available interleavers.

[0112] At 802, Tx 12 sends a data packet or TB including multiple coded CBs (including information bits and horizontal check blocks for each CB in the case of systematic codes) to all target Rx 14. The transmission at 802 may be a broadcast, multicast or groupcast transmission. Each Rx 14 attempts to decode the received data packet or TB.

[0113] Each Rx 14 sends back ACK / NACK feedback depending on whether the TB or data packet is successfully decoded. In this example, Rx-1 14-1 successfully decodes the data packet or TB, so it sends back an ACK at 804. Rx-2 14-2 and Rx-3 14-3 fail to successfully decode the data packet or TB, so they send back NACKs at 806 and 808, respectively. It is worth noting that Rx-2 14-2 and Rx-3 14-3 fail to successfully decode different CBs in the data packet or TB. For example, if Fig.8D As shown, if the data packet or TB sent by Tx 12 at 802 includes CB1 to CB9, Rx-2 14-2 fails to successfully decode CB2 and CB8 (as shown by CB2 and CB8 being crossed out), and Rx-3 14-3 fails to successfully decode CB1, CB2 and CB6 (as shown by CB1, CB2 and CB6 being crossed out).

[0114] return Fig. 8A , if at least one Rx 14 indicates a decoding failure of a TB or data packet (e.g., one of the feedbacks indicates NACK), Tx 12 retransmits one or more vertical code blocks at 810. The one or more vertical code blocks are generated based on the TB or data packet sent in the initial transmission (at 802) and can be generated based on predefined parameters (e.g., an interleaver). In some examples, Tx 12 can adjust the retransmission at 810 to exclude the Rx 14 that feedbacks ACK (Rx-114-1 in this example), such as in the case of multicast or groupcast retransmissions. In other examples, Tx 12 can send a retransmission to all Rx 14 at 810. For example, if Fig.8D As shown, the first vertical check block (VCB1) is retransmitted to all Rx 14 at 810 (however, as described above, more than one vertical check block may be retransmitted at 810). It is noteworthy that the same vertical code block is sent to Rx-2 14-2 and Rx-3 14-3 at 810, even though Rx-2 14-2 and Rx-3 14-3 have different undecoded CBs.

[0115] Each Rx that failed to successfully decode the initial transmission (Rx-2 14-2 and Rx-3 14-3 in this example) combines the received one or more vertical check blocks with the initially received TB and the soft information generated by the previous decoding attempt to retry decoding the undecoded CB. The Rx that has successfully decoded the TB (Rx-1 14-1 in this example) can ignore the retransmission.

[0116] In this example, one or more vertical check blocks enable both Rx-2 14-2 and Rx-3 14-3 to successfully decode the TB. It is worth noting that even if Rx-2 14-2 and Rx-3 14-3 both fail to successfully decode different CBs, they can use the same one or more vertical check blocks. The same one or more vertical check blocks can help decode any erroneous CB, or even decode different erroneous CBs that appear in different Rx 14. In addition, a single vertical check block can be sent. A single vertical check block may be sufficient to help successfully decode multiple erroneous CBs because the soft information generated by the previous decoding attempt of the erroneous CB is retained and can be used for subsequent decoding attempts. It should be noted that the number of one or more vertical check blocks included in a single retransmission may be less than the number of undecoded CBs in the initial transmission, but the number may be more than one.

[0117] return Fig. 8A , Rx-2 14-2 and Rx-3 14-3 send back ACK at 814 and 816 respectively. Optionally, Rx-1 14-1 may also send back ACK again at 812 to confirm the decoding success. After Tx 12 receives the ACK feedback of all Rx 14, the retransmission may end.

[0118] Fig. 8A The example shows some advantages of the currently disclosed retransmission scheme compared to existing retransmission schemes.

[0119] For example, if conventional TB-based HARQ is used, the entire TB needs to be retransmitted in the retransmission. This means that there may be a lot of redundancy. For example, if only one CB fails to decode, only one CB provides useful information in the retransmission, and the other CBs are redundant, thus wasting transmission resources (e.g., time-frequency resources).

[0120] Another existing retransmission scheme is called code block group (CBG) based HARQ. CBG-based HARQ retransmission is similar to TB-based HARQ, but instead of retransmitting the entire TB, the TB is divided into multiple groups of multiple CBs (called CBGs), and only the CBGs including the undecoded CBs are retransmitted. However, since each receiving node must inform the sending node which CB needs to be retransmitted in order for the sending node to identify the CBG to be retransmitted, a large amount of feedback overhead is generated. In addition, if there are undecoded CBs belonging to different CBGs, multiple CBGs need to be retransmitted, which again increases redundancy. In addition, in the case of broadcast / multicast / groupcast, since there are multiple receiving nodes, different receiving nodes are likely to have errors in different CBGs. In this case, all CBGs that indicate errors occurring at any receiving node need to be retransmitted. For example, in Fig.8D In the example shown, if CBG-based HARQ is used, CB1, CB2, and CB3 can be classified into one CBG (e.g., CBG1); CB4, CB5, and CB6 can be classified into another CBG (e.g., CBG2); and CB7, CB8, and CB9 can be classified into a third CBG (e.g., CBG3). Then, after the first round of feedback, Tx 12 needs to retransmit CBG1 and CBG3 to Rx-2 14-2 (because Rx-2 14-2 failed to successfully decode CB2 belonging to CBG1 and failed to successfully decode CB8 belonging to CBG3), and retransmit CB1 and CB2 to Rx-3 14-3 (because Rx-3 14-3 failed to successfully decode CB1 and CB2 belonging to CBG1 and failed to successfully decode CB6 belonging to CBG2). This means that Tx 12 needs to retransmit all 3 CBGs, so that even if the feedback overhead increases, the complete TB needs to be retransmitted. In this example, CBG-based HARQ is not efficient, which may not be possible for broadcast / multicast / groupcast transmission.

[0121] Another existing retransmission scheme is outer erasure coding. However, as described above, this approach does not use the soft information generated by the previous decoding attempt to assist the current decoding attempt, so the performance is not as good as the example disclosed in this article. In addition, outer erasure codes are used for transmissions on erasure channels, and on non-erasure channels, the performance will be degraded. In addition, if any receiving node loses or fails to successfully decode K CBs (where K is a positive integer) in the initial transmission, the Tx needs to send at least K parity code blocks generated using outer erasure codes in the retransmission to enable the receiving node to recover the lost K CBs. This can be avoided if vertical check blocks are used in the retransmission, as described in this article. In Fig.8DIn the example of , Rx-3 14-3 failed to successfully decode 3 CBs (CB1, CB2, CB6) in the first transmission. Therefore, if outer erasure codes are used, at least 3 parity CBs need to be retransmitted to recover the 3 information CBs. However, by using vertical check block based retransmission, as described in this article, only one vertical check block can be retransmitted, and Rx-3 14-3 will be able to recover all CBs after one retransmission.

[0122] Figure 8B is a signaling diagram of another example of using vertical check blocks in a retransmission scheme without ACK / NACK. In a retransmission without ACK / NACK, the feedback of the receiving node is optional or omitted. The retransmission scheme without ACK / NACK can be used for rateless codes. The retransmission scheme without ACK / NACK is beneficial for broadcast transmission because the sending node broadcasts to a large number of unknown receiving nodes. Figure 8B Similar to Fig. 8A , involving a transmitting node 12 (denoted as Tx 12) transmitting to multiple receiving nodes (denoted as Rx-1 14-1, Rx-2 14-2 and Rx-3 14-3, collectively referred to as Rx 14). The transmission of Tx 12 can be a multicast, broadcast or groupcast transmission. Tx 12 can be a BS 170 (e.g., for broadcasting or multicasting DL transmission to ED 110) or an ED 110 (e.g., for multicasting SL transmission to other ED 110). In some examples, if Tx 12 is ED 110, one of the Rx 14 can be a BS 170 (e.g., UL transmission) and the other Rx 14 can be other ED 110. Tx 12 can send a configuration signal or a control signal to Rx 14 (e.g., before an initial transmission, in a retransmission, together with a retransmission, or immediately after a retransmission) to provide information about parameters for generating a vertical check block, but this is not shown in the figure. This type of information may be necessary for Rx 14 to use the vertical check block to aid decoding.

[0123] At 852, Tx 12 sends a data packet or TB including a plurality of encoded CBs to all target Rx 14. The transmission at 852 may be a broadcast, multicast or groupcast transmission. Each Rx 14 attempts to decode the received data packet or TB.

[0124] Similar to the rateless code, after each transmission, Rx 14 may not have PHY layer ACK / NACK feedback. If the TB decoding is successful, Rx 14 may send an optional higher layer ACK. In this example, Rx-1 14-1 successfully decodes the TB, so optionally sends back an ACK at 854. Rx-2 14-2 and Rx-3 14-3 fail to successfully decode the TB, so no feedback is sent. It is worth noting that Rx-2 14-2 and Rx-3 14-3 fail to successfully decode different CBs in the TB. For example, if Fig. 8E As shown, if the TB sent by Tx 12 at 852 includes CB1 to CB9, Rx-2 14-2 fails to successfully decode CB2 and CB8 (as shown by crossed-out CB2 and CB8), and Rx-3 14-3 fails to successfully decode CB1, CB2 and CB6 (as shown by crossed-out CB1, CB2 and CB6).

[0125] Tx 12 may be used to send a predetermined number of retransmissions. Tx 12 may also be used to generate one or more vertical code blocks for each retransmission using predetermined parameters. Tx 12 may send a predetermined number of retransmissions until an optional high-level ACK is received for each Rx 14. Alternatively, Tx 12 may send a predetermined number of retransmissions regardless of any feedback (or whether any feedback exists). Tx 12 may send retransmissions only to Rx 14 that did not send a high-level ACK (e.g., for multicast or groupcast retransmissions). Sending a predetermined number of retransmissions that are not triggered by feedback (or no feedback is received between transmissions / retransmissions) may be referred to as repeats or blind retransmissions.

[0126] like Figure 8B and Fig. 8E As shown, in this example, Tx 12 receives the high-level ACK of Rx-1 14-1, but Rx-2 14-2 and Rx-3 14-3 do not send feedback. At 856, Tx 12 retransmits one or more vertical code blocks (such as Fig. 8E The one or more vertical code blocks are generated based on the TB or data packet sent in the initial transmission (at 852) and may be generated based on predefined parameters (e.g., an interleaver). The retransmission at 856 sends the same one or more vertical check blocks to Rx-2 14-2 and Rx-3 14-3.

[0127] Each Rx (Rx-2 14-2 and Rx-3 14-3 in this example) that failed to successfully decode the initial transmission uses the received one or more vertical check blocks together with the initially received TB and the soft information generated by the previous decoding attempt to re-attempt decoding of the undecoded CB. In this example, Rx-2 14-2 successfully decodes the TB using the one or more vertical check blocks and the soft information generated by the previous decoding attempt, and therefore optionally sends back an ACK at 858. Rx-3 14-3 still did not successfully decode the TB, so no feedback is sent.

[0128] Tx 12 continues to send a predetermined number of retransmissions at 860 and 862. A different set of one or more vertical check blocks (such as Fig. 8E 14-3). For example, each set of vertical check blocks may be generated using different parameters (e.g., different interleavers). In some examples, even if an ACK is not received from Rx-3 14-3, the retransmission ends after a predetermined number of retransmissions (three retransmissions in this example) are completed. In another example, the number of retransmissions is not predetermined, but Tx 12 continues to send one or more other vertical check blocks until Tx 12 receives ACKs from all Rx 14. For example, in the case where the optional ACK is Figure 8B and Fig. 8E In the case of sending in the middle, Tx 12 can keep sending one (or more) vertical check blocks at a time. After the third retransmission (for example, after sending the third vertical check block VCB3), Tx12 receives an ACK for Rx-3 14-3. In addition to the ACKs of Rx-1 14-1 and Rx-2 14-2 previously received by Tx 12 (at 854 and 858), Tx 12 determines that ACKs for all target Rx 14 have been received, so Tx 12 stops sending more vertical check blocks. In some examples, Tx 12 can be scheduled to send a predetermined maximum number of retransmissions or a predetermined maximum number of vertical check blocks, and if the maximum number of retransmissions or the maximum number of vertical check blocks has been reached, or ACKs for all target Rx14 have been received, stop sending more vertical check blocks.

[0129] Figure 8C is based on Fig. 8A and Figure 8B Flowchart of an exemplary method 870 of signaling example that may be performed by a sending node.

[0130] At 874, Tx 12 sends an initial transmission to multiple target Rx 14 (e.g., at Fig. 8A and Figure 8B The initial transmission may be a broadcast, groupcast or multicast transmission. The initial transmission includes a plurality of information CBs.

[0131] Optionally, at 876, feedback may be received from one or more Rx 14. For example, in a feedback-based retransmission scheme, each Rx 14 may need to send ACK / NACK feedback back to Tx 12 (e.g., Fig. 8A In the retransmission scheme without ACK / NACK, ACK feedback may be optional (e.g., in Figure 8B ), so there can be no NACK feedback.

[0132] Optionally, at 878, Tx 12 determines whether at least one Rx 14 has a reception failure. The reception failure of one Rx 14 indicates that Rx 14 cannot successfully decode at least one information CB. In the case of a feedback-based retransmission scheme, if at least one NACK is received at step 876, Tx 12 can determine that at least one Rx 14 has failed to successfully decode the CB. In the case of a retransmission scheme without ACK / NACK, if Tx 12 does not receive ACKs for all target Rx 14, Tx 12 can determine that at least one Rx 14 has failed to successfully decode the CB. Based on the feedback received at step 876, Tx 12 can also identify which Rx 14 has a reception failure.

[0133] In some examples, such as in a broadcast scenario, Tx 12 does not receive any feedback from any Rx 14, so Tx 12 can perform a predetermined number of retransmissions (also known as a blind retransmission scheme). In this case, steps 876 and 878 can be omitted.

[0134] At 880, Tx 12 generates one or more vertical check blocks. The one or more vertical check blocks are generated using bits selected from at least two CBs sent in the initial transmission at step 874. It should be noted that the one or more vertical check blocks can be generated at any time in method 870 before sending the one or more vertical check blocks. For example, the one or more vertical check blocks can be generated before the initial transmission, or after optional steps 876 and 878.

[0135] Optionally, at 881, a configuration signal or control signal (e.g., an RRC signal, a PC5-RRC signal, a DCI transmission, or an SCI transmission) may be sent by Tx 12 to provide Rx 14 with information about one or more parameters for generating one or more vertical check blocks. Information about how to generate one or more vertical check blocks enables each Rx 14 to use one or more vertical check blocks (to be sent in retransmission) to help decode the information CB in the initial transmission. The signal may be used to indicate NDI, HARQ process ID, number of repetitions, number of one or more vertical check blocks sent, and parameters for generating one or more vertical check blocks, such as code block partitioning, interleaver selection, RV or RV sequence, coding rate, index of CB for generating one or more vertical check blocks, and / or other information related to generating one or more vertical check blocks, as described above. The configuration signal or control signal may be received before or at the beginning of method 870, or may be received at any time in method 870, including in, together with, or after sending one or more vertical check blocks to Rx 14. For example, step 881 may occur in step 882.

[0136] In some examples, configuration signals or control signals may not need to be sent, and thus step 881 may be omitted. For example, parameters for generating one or more vertical check blocks may be predetermined (eg, defined in a standard), and thus do not need to be sent from Tx 12 to each Rx 14.

[0137] At 882, at least one vertical check block is sent to at least one Rx 14. One or more vertical check blocks may be sent to multiple Rx 14s (e.g., in a broadcast, multicast, or groupcast, similar to the initial transmission). In some examples, one or more vertical check blocks may be sent to all Rx 14s in a broadcast, multicast, or groupcast, regardless of whether a given Rx 14 successfully decoded the initial transmission (e.g., in Fig. 8A In other examples, one or more vertical check blocks may be sent in a multicast or groupcast only to Rx 14 (e.g., Figure 8B of signal 856).

[0138] The further steps of optionally receiving feedback and sending one or more subsequent retransmissions may be performed as needed (eg, according to a predetermined number of retransmissions).

[0139] The examples disclosed herein may also be applicable to multicast or groupcast transmissions in V2X communications. It should be noted that although this discussion is provided in the context of V2X communications, these examples may also be applicable to other applications. The NR-V2X standard defines some resource allocation modes and options for V2X multicast. There are two modes for defining resource allocation for the sending node (a vehicle in V2X). In mode 1, BS 170 schedules the resources that the sending node is to use for initial transmission and any subsequent retransmissions. The sending node may report to BS 170 (e.g., a positive acknowledgment ACK or a negative acknowledgment NACK) so that additional resources are scheduled for retransmission. In mode 2, the sending node selects resources for transmission and subsequent retransmissions from a preconfigured resource pool.

[0140] Fig.9A 9 is a flow chart of an exemplary method 900 for multicast or groupcast communication using Mode 1 defined in NR-V2X that can be performed by a transmitting node. The transmitting node can be a connected vehicle, generally represented as Tx. The multicast or groupcast communication is directed to multiple receiving nodes (generally represented as Rx), which can include other EDs 110 (e.g., other vehicles, UEs, IoT devices, surrounding sensors, etc.) and / or BSs 170.

[0141] Optionally, at 902, Tx requests resource allocation (e.g., time-frequency resources) from BS 170 (e.g., gNB). The step of requesting resource allocation can be implemented by, for example, sending a scheduling request (SR) to the BS. At 904, BS 170 allocates scheduling resources and indicates them to Tx. Optionally, if the scheduled transmission to be performed by Tx (at 906 below) includes one or more retransmissions, the scheduling signaling can also provide information about one or more parameters for generating one or more vertical check blocks to Tx (e.g., in a configuration signal or control signal such as an RRC signal or DCI transmission). The signal can be used to indicate NDI, HARQ process ID, number of repetitions, number of one or more vertical check blocks sent, and parameters for generating one or more vertical check blocks, such as code block partitioning, interleaver selection, RV or RV sequence, coding rate, index of CB used to generate one or more vertical check blocks, and / or other information related to generating one or more vertical check blocks, as described above.

[0142] Optionally, at 905, if the scheduled transmission includes the transmission of one or more vertical check blocks, Tx may provide information about one or more parameters for generating one or more vertical check blocks to Rx (e.g., in a configuration signal or control signal such as a PC5-RRC signal or an SCI transmission). Information about how to generate one or more vertical check blocks enables each Rx to use one or more vertical check blocks to help decode information CB. The configuration indicated to Rx may be a configuration previously indicated to Tx by BS170. The configuration signal or control signal may be sent in, together with, or after sending one or more vertical check blocks to Rx. For example, step 905 may occur in step 906.

[0143] At 906, Tx performs an initial transmission to multiple Rxs (e.g., in V2X multicast). In some examples, Tx may send only an initial transmission of data at 906, and may require further resource allocation from BS 170 for any retransmissions associated with the same data. In other examples, Tx may have been allocated resources for a predetermined number of transmissions and retransmissions (each retransmission being a set of one or more vertical check blocks).

[0144] At 908, the Tx determines whether any Rx failed to successfully receive the transmission.

[0145] For example, Tx may determine whether any Rx failed to successfully receive the transmission based on the ACK / NACK feedback of the Rx. In some examples, such as when Tx may not be fully aware of the Rx, each Rx may only send a NACK if the transmission was not successfully received. At 910, if any NACK is received for any Rx, Tx reports NACK feedback to BS 170. Otherwise, if Tx does not receive any NACK feedback, Tx reports ACK.

[0146] In another example, Tx may be fully aware of Rx. For example, each Rx may have a dedicated PSFCH resource, so each Rx sends ACK / NACK feedback on its own dedicated PSFCH resource. In this case, at 910, if ACK feedback is received for all Rx, Tx reports ACK to BS 170, and if at least one NACK is received for Rx, Tx reports NACK to BS 170.

[0147] If Tx performs a predetermined number of retransmissions at 906 (in addition to the initial transmission), then at 908, Tx can determine whether at least one Rx still has a reception failure (for example, at least one NACK feedback is still received) even after the predetermined number of retransmissions, and therefore report the feedback to BS 170 at 910.

[0148] If all Rxs are received successfully (eg, NACK of any Rx is not received, or ACK of all Rxs is received), then at 910, Tx reports ACK to BS 170, and thus method 900 ends.

[0149] If Tx reports NACK to BS 170 at 910, the report of NACK can be interpreted by BS 170 as a request for further resource allocation. After BS 170 receives the NACK report of Tx, at 912, BS 170 schedules and indicates further resource allocation to enable Tx to perform a predetermined number of retransmissions. Tx can be scheduled to perform one or more retransmissions, each retransmission can independently be a transmission of one or more vertical check blocks. Optionally, the scheduling signaling can also provide Tx (for example, in a configuration signal or control signal such as an RRC signal or DCI transmission) with information about one or more parameters for generating one or more vertical check blocks. The signal can be used to indicate NDI, HARQ process ID, number of repetitions, number of one or more vertical check blocks sent, and parameters for generating one or more vertical check blocks, such as code block partitioning, interleaver selection, RV or RV sequence, coding rate, index of the CB used to generate one or more vertical check blocks, and / or other information related to generating one or more vertical check blocks, as described above.

[0150] Optionally, at 913, Tx may provide information about one or more parameters for generating one or more vertical check blocks to Rx (e.g., in a configuration signal or control signal such as a PC5-RRC signal or an SCI transmission). Information about how to generate one or more vertical check blocks enables each Rx to use one or more vertical check blocks to help decode information CB. The configuration indicated to Rx may be a configuration that BS 170 optionally indicates to Tx at 912. The configuration signal or control signal may be sent in, together with, or after sending one or more vertical check blocks to Rx. For example, step 913 may occur in step 914.

[0151] At 914, Tx performs one or more retransmissions (up to a predetermined number of retransmissions allowed by the allocated resources). The one or more retransmissions may be sent to all Rxs (e.g., if Tx does not fully understand Rx), or only to Rxs that have failed to receive (e.g., if Tx fully understands Rx).

[0152] Fig. 9B9 is a flow chart of an exemplary method 950 for multicast or groupcast communication using Mode 2 defined in NR-V2X that can be performed by a transmitting node. The transmitting node can be a connected vehicle, generally represented as Tx. The multicast or groupcast communication is directed to multiple receiving nodes (generally represented as Rx), which can include other EDs 110 (e.g., other vehicles, UEs, IoT devices, surrounding sensors, etc.) and / or BSs 170.

[0153] At 952, Tx selects necessary resources (e.g., time-frequency resources) from a resource pool. The resource pool may be preconfigured or configured in advance by the network. BS 170 does not participate in allocating ED specific resources to Tx in every transmission. Tx selects resources based on a predetermined number of transmissions / retransmissions.

[0154] Optionally, in 953, if the transmission includes the transmission of one or more vertical check blocks, Tx may provide information about one or more parameters for generating one or more vertical check blocks to Rx (e.g., in a configuration signal or control signal such as a PC5-RRC signal or an SCI transmission). Information about how to generate one or more vertical check blocks enables each Rx to use one or more vertical check blocks to help decode information CB. The signal may be used to indicate NDI, HARQ process ID, number of repetitions, number of one or more vertical check blocks sent, and parameters for generating one or more vertical check blocks, such as code block partitioning, interleaver selection, RV or RV sequence, coding rate, index of CB for generating one or more vertical check blocks, and / or other information related to generating one or more vertical check blocks, as described above. The configuration signal or control signal may be sent in, together with, or after sending one or more vertical check blocks to Rx. For example, step 905 may occur in step 906.

[0155] At 954, the Tx performs an initial transmission to multiple Rxs (e.g., in V2X multicast). Fig.9A In some examples, Tx may send only the initial transmission at 954, and may require more resources for any retransmissions. In other examples, Tx may have selected resources for a predetermined number of retransmissions (each retransmission being a set of one or more vertical check blocks).

[0156] At 956, the Tx determines whether any Rx failed to successfully receive the transmission.

[0157] For example, Tx may determine whether any Rx failed to successfully receive the transmission based on the ACK / NACK feedback from the Rx. In some examples, such as where Tx may not be fully aware of the Rx, each Rx may only send a NACK if the transmission was not successfully received. If any NACK is received from any Rx, then Tx determines that the reception failed. Otherwise, Tx determines that all Rx successfully received the transmission.

[0158] In another example, Tx may be aware of Rx. For example, each Rx may have a dedicated PSFCH resource, so each Rx sends ACK / NACK feedback on its own dedicated PSFCH resource. In this case, if any NACK is received from any Rx, Tx determines that reception failed, or if ACK feedback is received from all Rx, Tx determines that transmission is successful.

[0159] If Tx performs a predetermined number of retransmissions at 954 (in addition to the initial transmission), then at 956, Tx may determine whether at least one Rx still has a reception failure (eg, still receives at least one NACK feedback) even after the predetermined number of retransmissions.

[0160] If all Rxs are received successfully (eg, NACK is not received for any Rx, or ACK is received for all Rxs), then at 956, Tx determines that reception failure does not occur for any Rx, and thus method 950 ends.

[0161] If at least one Rx fails to receive in 956, then Tx selects other resources from the resource pool to perform one or more retransmissions in 958. The number of retransmissions to be performed and the number of one or more vertical check blocks to be sent in each retransmission can be preconfigured in Tx.

[0162] Optionally, at 959, Tx may provide information about one or more parameters for generating one or more vertical check blocks to Rx (e.g., in a configuration signal or control signal such as a PC5-RRC signal or an SCI transmission). Information about how to generate one or more vertical check blocks enables each Rx to use one or more vertical check blocks to help decode information CB. The signal may be used to indicate NDI, HARQ process ID, number of repetitions, number of one or more vertical check blocks sent, and parameters for generating one or more vertical check blocks, such as code block partitioning, interleaver selection, RV or RV sequence, coding rate, index of CB for generating one or more vertical check blocks, and / or other information related to generating one or more vertical check blocks, as described above. The configuration signal or control signal may be sent in, together with, or after sending one or more vertical check blocks to Rx. For example, step 959 may occur in step 960.

[0163] At 960, Tx performs one or more retransmissions (up to a predetermined number of retransmissions allowed by the selected resources). The one or more retransmissions may be sent to all Rxs (e.g., if Tx does not fully understand Rx), or only to the Rx that experienced the reception failure (e.g., if Tx fully understands Rx).

[0164] It should be noted that for broadcast transmissions, in some examples, only blind retransmissions (i.e., retransmissions without ACK / NACK) may be supported. In blind retransmissions, Tx sends an initial transmission and a predetermined number of retransmissions (each retransmission is a set of corresponding one or more vertical check blocks). For blind retransmissions, Tx may have resources allocated by BS 170 (in Mode 1), or may select resources sufficient for the initial transmission and a predetermined number of retransmissions from a resource pool (in Mode 2).

[0165] The present application also describes an example of generating vertical check blocks based on multiple TBs or data packets. It should be understood that the following discussion, which in some cases involves data packets, may also apply to TBs. These vertical check blocks may be referred to as cross-packet check blocks.

[0166] Fig. 10A 1 is a signaling diagram of an example of using vertical check blocks across packets in multicast, groupcast or broadcast transmission. The sending node 12 (denoted as Tx 12) and the receiving node 14 (denoted as Rx-1 14-1, Rx-2 14-2 and Rx-3 14-3, collectively referred to as Rx 14) can be similar to Fig. 8A and Figure 8B The transmitting node and receiving node in the figure. Tx 12 may send a configuration signal or control signal to Rx 14 (e.g., before an initial transmission, in a retransmission, with a retransmission, or immediately after a retransmission) to provide information about the parameters used to generate the vertical check block, but this is not shown in the figure. Such information may be necessary for Rx 14 to use the vertical check block to assist in decoding.

[0167] like Fig. 10A As shown, Tx 12 sends multiple TBs to Rx 14. Each TB is sent in a corresponding data packet (data packet 1, data packet 2, and data packet 3 at 1002, 1004, and 1006 in this example). Each TB includes one or more CBs, and each TB may include a different number of CBs. Each transmission at 1002, 1004, and 1006 may be referred to as an initial transmission of the corresponding data packet (i.e., 1002 is the initial transmission of data packet 1, 1004 is the initial transmission of data packet 2, and 1006 is the initial transmission of data packet 3).

[0168] and FIG. 8A to FIG. 8ESimilarly, the retransmission scheme can be a feedback-based scheme (where ACK / NACK feedback is required for each Rx 14) or a no-ACK / NACK scheme (where ACK / NACK feedback is optional or omitted). If feedback is sent, each Rx 14 can provide feedback after attempting to decode each data packet (i.e., after each transmission at 1002, 1004, 1006) or after attempting to decode all data packets (i.e., after the last transmission at 1006). The Tx can inform the Rx 14 in a configuration signal or control signal how many data packets to expect and / or how many transmissions to expect before providing feedback.

[0169] exist Fig. 10A In the example of , after the transmission of the last data packet at 1006, Tx 12 does not receive any feedback. Tx 12 determines that at least one Rx 14 failed to successfully decode at least one of the three data packets. Fig. 10D As shown, Tx 12 sends CB1 and CB2 in packet 1 at 1002, sends CB3 and CB4 in packet 2 at 1004, and sends CB5 and CB6 in packet 3 at 1006. Rx-1 14-1 fails to successfully decode CB5 (as shown by the crossed-out CB5), Rx-2 14-2 fails to successfully decode CB2 and CB5 (as shown by the crossed-out CB2 and CB5), and Rx-3 14-3 fails to successfully decode CB1, CB2, and CB5 (as shown by the crossed-out CB1, CB2, and CB5). It is worth noting that each Rx 14 fails to successfully decode a different packet. Tx 12 uses CBs in multiple packets to generate one or more vertical check blocks. For example, one or more vertical check blocks can be generated by obtaining cross-block bits from all CBs across all packets 1 to packet 3, as shown in FIG. Fig. 10D As shown by arrow 1018 in FIG.

[0170] like Fig. 10A and Fig. 10DAs shown, at 1008, Tx 12 sends one or more vertical check blocks to Rx 14. Tx12 can continue to generate and send cross-packet vertical check blocks until ACKs are received for all Rx 14. In this example, only Rx-1 14-1 successfully decodes all three packets after the first retransmission at 1008, so ACK is sent to Tx 12 at 1010. Since Rx-2 14-2 and Rx-3 14-3 do not send ACK, Tx 12 performs a second retransmission. In some examples, Tx 12 can use CBs in all packets to generate other one or more vertical check blocks for the second retransmission. In other examples, the vertical check blocks for the first retransmission and the second retransmission can be generated together, but sent in separate retransmissions. A second retransmission using other one or more vertical check blocks is performed at 1012 (optionally, Rx-1 14-1 can be excluded from the second retransmission). The one or more vertical check blocks sent at 1012 can be generated by obtaining cross-block bits from all CBs across all packets 1 to 3. In this example, Rx-2 14-2 and Rx-3 14-3 successfully decode all three packets after the second retransmission, and therefore send ACKs to Tx 12 at 1014 and 1016, respectively. At this point, Tx 12 stops retransmitting. In some examples, Tx 12 performs up to a maximum predetermined number of retransmissions.

[0171] Fig. 10B is a signaling diagram of another example of using vertical check blocks across packets in multicast, groupcast or broadcast transmission. Fig. 10E Shown in Fig. 10B 14-1, Rx-2 14-2, and Rx-3 14-3 (collectively referred to as Rx 14). Tx 12 may send a configuration signal or control signal to Rx 14 (e.g., before an initial transmission, in a retransmission, with a retransmission, or immediately after a retransmission) to provide information about parameters for generating a vertical check block, but this is not shown in the figure. Such information may be necessary for Rx 14 to use the vertical check block to assist in decoding.

[0172] exist Fig. 10B and Fig. 10E In the embodiment of the present invention, Rx 14 can provide feedback after each transmission of a data packet. For example, after the transmission of data packet 1 at 1052, at least one Rx 14 can send at least one NACK to Tx 12 at 1054 to indicate that data packet 1 was not successfully decoded. For example, in Fig. 10EIn the example, Rx-2 14-2 and Rx-3 14-3 failed to successfully decode all CBs in packet 1 and therefore sent back NACK, while Rx-1 14-1 successfully decoded packet 1 and therefore sent back ACK. Optionally, the Rx 14 that failed to successfully decode packet 1 failed to successfully send ACK instead of sending NACK. Tx 12 uses the feedback (receiving NACK from at least one Rx or not receiving ACK from all Rx) to determine that at least one Rx 14 failed to successfully decode packet 1.

[0173] Tx 12 may wait to send a retransmission until after all three target packets have completed their initial transmission. At 1056, Tx 12 sends Packet 2 to all Rx 14. In this case, Rx 14 receives ACKs from all Rx 14 at 1058, indicating that all Rx 14 successfully received and decoded Packet 2.

[0174] At 1060, Tx 12 sends Packet 3 to all Rx 14. At 1062, at least one Rx 14 may send at least one NACK to Tx 12 to indicate that Packet 3 was not successfully decoded. Fig. 10E In the example, all Rx 14 failed to successfully decode all CBs in the packet 3, and therefore sent back NACK (each Rx 14 failed to successfully decode a different CB in the packet 3). Optionally, the Rx 14 that failed to successfully decode the packet 3 failed to successfully send ACK instead of sending NACK. The Tx 12 uses the feedback (receiving NACK from at least one Rx or not receiving ACK from all Rx) to determine that at least one Rx 14 failed to successfully decode the packet 3.

[0175] Tx 12 generates one or more cross-packet vertical check blocks using only the CBs belonging to one or more packets that are not successfully decoded by all Rx 14. In this example, Tx 12 generates one or more cross-packet vertical check blocks using the CBs in Packet 1 and Packet 3, but not Packet 2 (which is successfully decoded by all Rx 14) (e.g., Fig. 10E1064). One or more vertical check blocks are sent in the retransmission at 1064. In the configuration signaling or control signaling sent by Tx 12 to Rx 14, Tx 12 can indicate that the one or more vertical check blocks sent at 1064 are generated using the CB in data packet 1 and data packet 3, so that Rx 14 can use this information to correctly use the one or more received vertical check blocks to help decode the CB in data packet 1 and data packet 3. In this example, Tx 12 receives ACKs from all Rx 14 at 1066, indicating that all Rx 14 have successfully decoded all three data packets. At this time, Tx 12 stops retransmission. In some examples, Tx 12 performs up to a maximum predetermined number of retransmissions.

[0176] exist Fig. 10A and Fig. 10B In the example of , the vertical check block is generated using CBs belonging to multiple TBs (rather than using a single TB). This can help further improve the retransmission efficiency. The information generated by a single retransmission helps decode CBs in different TBs. Fig. 10B In the example above), the CBs used to generate a set of vertical check blocks can be selected only from TBs that were not successfully decoded (based on feedback from multiple Rxs), which can further help improve efficiency.

[0177] Fig. 10C is based on Fig. 10A and Fig. 10B Flowchart of an exemplary method 1070 of signaling example that may be performed by a sending node.

[0178] At 1074, Tx 12 sends multiple initial transmissions of a corresponding plurality of data packets to multiple target Rx 14 (each initial transmission is a transmission of a corresponding different data packet) (e.g., at Fig. 10A signal 1002 to signal 1006, or at Fig. 10B The initial transmission may be a broadcast, groupcast or multicast transmission. Each data packet sent in the corresponding initial transmission includes one or more information CBs.

[0179] Optionally, at 1076, feedback may be received from one or more Rx 14. For example, in a feedback-based retransmission scheme, each Rx 14 may need to send ACK / NACK feedback back to Tx 12 after each initial transmission or after an expected number of initial transmissions (e.g., if Rx 14 knows the expected number of initial transmissions from a configuration signal or control signal). In a retransmission scheme without ACK / NACK, ACK feedback may be optional, so there may be no NACK feedback.

[0180] Optionally, at 1078, Tx 12 determines whether at least one Rx 14 has failed to successfully receive at least one data packet. The reception failure of one Rx 14 indicates that Rx 14 has failed to successfully decode the information CB in at least one data packet. In the case of a feedback-based retransmission scheme, if at least one NACK is received at step 1076, Tx 12 can determine that at least one Rx 14 has failed to successfully decode at least one data packet. In the case of a retransmission scheme without ACK / NACK, if Tx 12 does not receive ACKs for all target Rx 14, Tx 12 can determine that at least one Rx 14 has failed to successfully decode a data packet. In some examples, if feedback is received after the transmission of each data packet, Tx 12 can also determine which data packet or packets at least one Rx 14 has failed to successfully decode (it should be noted that different Rx 14s have failed to successfully decode different data packets). Based on the feedback received at step 1076, Tx 12 can also identify which Rx 14 has failed to receive.

[0181] In some examples, such as in a broadcast scenario, Tx 12 does not receive any feedback from any Rx 14, so Tx 12 can perform an initial transmission and a predetermined number of retransmissions (also known as a blind retransmission scheme). In this case, step 1076 can be omitted.

[0182] At 1080, Tx 12 generates one or more vertical check blocks. The one or more vertical check blocks are generated using bits selected from the CBs of at least two data packets sent in the initial transmission at step 1074. Information bits belonging to at least one CB are selected from each of the at least two data packets to generate one or more vertical check blocks. In an example where Tx 12 receives feedback indicating that a specific data packet was not successfully decoded (at optional step 1076), one or more vertical check blocks can be generated using only bits in these specific data packets. One or more vertical check blocks can be generated at any time in method 1070 before sending one or more vertical check blocks. For example, one or more vertical check blocks can be generated before the initial transmission, or after optional steps 1076 and 1078.

[0183] Optionally, at 1081, a configuration signal or control signal (e.g., an RRC signal, a PC5-RRC signal, a DCI transmission, or an SCI transmission) may be sent by Tx 12 to provide Rx 14 with one or more parameters for generating one or more vertical check blocks. Information about how to generate one or more vertical check blocks enables each Rx 14 to use one or more vertical check blocks (to be sent in retransmission) to help decode information CB. The configuration signal or control signal may be used to indicate NDI, HARQ process ID, number of repetitions, number of one or more vertical check blocks sent, and parameters for generating one or more vertical check blocks, such as code block partitioning, interleaver selection, RV or RV sequence, coding rate, index of CB for generating one or more vertical check blocks, and / or other information related to generating one or more vertical check blocks, as described above. The configuration information may also indicate which data packets are used to generate one or more vertical check blocks. The configuration information may be received before or at the beginning of method 1070, or may be received at any time in method 1070, including in, together with, or after sending one or more vertical check blocks to Rx 14. For example, step 1081 may occur during step 1082 .

[0184] In some examples, configuration signals or control signals may not need to be sent, and thus step 1081 may be omitted. For example, parameters for generating one or more vertical check blocks may be predetermined (eg, defined in a standard), and thus do not need to be sent from Tx 12 to each Rx 14.

[0185] At 1082, at least one vertical check block is sent to at least one Rx 14. One or more vertical check blocks may be sent to multiple Rx 14s (e.g., in a broadcast, multicast, or groupcast, similar to the initial transmission). In some examples, one or more vertical check blocks may be sent to all Rx 14s in a broadcast, multicast, or groupcast, regardless of whether a given Rx 14 successfully decodes the initial transmission. In other examples, one or more vertical check blocks may be sent in a multicast or groupcast only to Rx 14s that determined (at optional step 1078) that the initial transmission was not successfully decoded.

[0186] The further steps of optionally receiving feedback and sending one or more subsequent retransmissions may be performed as needed (eg, according to a predetermined number of retransmissions).

[0187] In the above examples, the sending node sends information CB in the initial transmission and sends one or more vertical check blocks in subsequent retransmissions. However, it should be understood that in any example discussed herein, at least one vertical check block may be sent in the initial transmission together with information CB.

[0188] The signaling performed is similar to that described previously Fig. 8A , Figure 8B , Fig. 10A and Fig. 10B The signaling is different in that the initial transmission includes at least one vertical check block and information CB. The sending node generates one or more vertical check blocks using CB before the initial transmission, and includes one or more vertical check blocks in the initial transmission. The sending node may send a configuration signal or a control signal before the initial transmission to indicate to the receiving node that one or more vertical check blocks are included in the initial transmission. Subsequent one or more retransmissions of the other one or more vertical check blocks may be performed as needed (e.g., based on a predetermined number of retransmissions or based on feedback from the receiving node), similar to the previous description.

[0189] In this example, since at least one vertical check block is sent with the initial transmission, the one or more vertical check blocks are generated and sent by the sending node without any feedback from any receiving node. Therefore, in some examples, the one or more vertical check blocks can be generated according to predetermined parameters (e.g., the number of vertical check blocks to be generated, the bits selected for generating the one or more vertical check blocks, etc.).

[0190] In some examples, the number of one or more vertical check blocks included in the initial transmission together with the information CB can be determined by the sending node according to channel characteristics. The sending node can use the transmission channel of all target receiving nodes (for example, using the channel feedback of the receiving node) to determine the code rate of the vertical check block used for the initial transmission. The code rate can be determined based on the trade-off between the increased overhead (due to the addition of one or more vertical check blocks in the initial transmission) and the possibility that any receiving node can fully decode the information CB (due to poor channel quality). For example, the code rate in the initial transmission can be determined based on channel state information feedback (for example, the SNR of each receiving node). For example, if the SNR of the receiving node with the worst channel quality is less than a certain threshold, a certain number of vertical check blocks can be sent in the initial transmission. The threshold and the corresponding number of vertical check blocks can be determined by achieving the minimum probability of all receiving nodes successfully decoding the data packet after the initial transmission, etc. For example, there can be multiple predefined SNR thresholds, and each SNR threshold can predefine a corresponding number of vertical check blocks. For example, this information can be predefined in the standard. In some examples, the average channel quality of all receiving nodes, the channel quality of a portion of the receiving nodes, or other statistical values ​​of the channel quality of the receiving nodes can be used instead of using the receiving node with the worst channel quality as the criterion for determining the code rate. For example, if it is known that the channel quality of one or more receiving nodes is poor (and therefore redundant information may be needed to help decode the CB), it is more efficient to include one or more vertical check blocks in the initial transmission instead of waiting for NACKs from these receiving nodes.

[0191] The initial transmission including the CB and one or more vertical check blocks may then be multicast, groupcast, or broadcast to target receiving nodes (eg, similar to fountain codes used for MBMS).

[0192] If additional one or more vertical check blocks are needed after the initial transmission, the additional one or more vertical check blocks may be generated using an interleaver or RV different from the one or more vertical check block interleavers or RVs used for the one or more vertical check blocks included in the initial transmission.

[0193] Fig.11A is a flow chart of an example method 1100 that may be performed by a transmitting node in which one or more vertical check blocks are included in an initial transmission. Fig. 11B An exemplary transmission by Tx 12 to Rx-1 14-1, Rx-2 14-2, and Rx-3 14-3 (collectively, Rx14) is shown.

[0194] Optionally, at 1102, the transmitting node receives channel feedback from the target receiving node. Using the channel feedback information, the transmitting node can determine the code rate and thereby determine the number of vertical check blocks that should be included in the initial transmission. In some cases, the code rate and / or the number of vertical check blocks included in the initial transmission may be predetermined (e.g., according to a standard, or pre-configured), and thus step 1102 may be omitted. It should be noted that step 1102 may determine that the number of vertical check blocks included in the initial transmission is 0.

[0195] At 1104, Tx 12 generates one or more vertical check blocks. The one or more vertical check blocks are generated using bits selected from at least two CBs to be sent in the initial transmission.

[0196] Optionally, at 1106, a configuration signal or control signal (e.g., an RRC signal, a PC5-RRC signal, a DCI transmission, or an SCI transmission) may be sent by Tx 12 to provide Rx 14 with one or more parameters for generating one or more vertical check blocks. Information about how to generate one or more vertical check blocks enables each Rx 14 to use one or more vertical check blocks (to be sent in a retransmission) to help decode the information CB in the initial transmission. The configuration signal or control signal may be used to indicate the NDI, HARQ process ID, number of repetitions, number of one or more vertical check blocks sent, and parameters for generating one or more vertical check blocks, such as code block partitioning, interleaver selection, RV or RV sequence, coding rate, index of the CB for generating one or more vertical check blocks, and / or other information related to generating one or more vertical check blocks, as described above. The configuration information may be received before or at the beginning of method 1100, or may be received at any time in method 1100, including in, together with, or after sending one or more vertical check blocks to Rx 14. For example, step 1106 may occur in step 1108. The configuration information may include an indication whether and how many vertical check blocks are included in the initial transmission together with the information CB.

[0197] In some examples, configuration signals or control signals may not need to be sent, and thus step 1106 may be omitted. For example, parameters for generating and sending one or more vertical check blocks may be predetermined (e.g., defined in a standard), and thus do not need to be sent from Tx 12 to each Rx 14.

[0198] At 1108, Tx 12 sends an initial transmission to multiple target Rx 14. The initial transmission includes information CB and at least one vertical check block. The initial transmission can be a broadcast, groupcast or multicast transmission. Fig. 11B In the example of , the initial transmission at 1152 includes CB1 to CB9 and two vertical check blocks (VCB1 and VCB2).

[0199] Optionally, at 1110, feedback may be received from one or more Rx 14. For example, in a feedback-based retransmission scheme, each Rx 14 may need to send ACK / NACK feedback back to Tx 12. In a retransmission scheme without ACK / NACK, ACK feedback may be optional, so there may be no NACK feedback. Fig. 11B In the example of , both Rx-2 14-2 and Rx-3 14-3 failed to successfully decode at least one information CB (Rx-2 14-2 and Rx-3 14-3 failed to successfully decode different CBs), so NACK is sent back at 1154, while Rx-1 14-1 successfully decodes all CBs, so ACK is sent back at 1154.

[0200] Optionally, at 1112, Tx 12 determines whether at least one Rx 14 has a reception failure. The reception failure of one Rx 14 indicates that Rx 14 has failed to successfully decode the information CB. In the case of a feedback-based retransmission scheme, if at least one NACK is received in step 1110, Tx 12 may determine that at least one Rx 14 has failed to successfully decode the CB. In the case of a retransmission scheme without ACK / NACK, if Tx 12 does not receive ACKs for all target Rx 14, Tx 12 may determine that at least one Rx 14 has failed to successfully decode the CB. Based on the feedback received in step 1110, Tx 12 may also identify which Rx 14 has a reception failure.

[0201] In some examples, such as in a broadcast scenario, Tx 12 does not receive any feedback from Rx 14, so Tx 12 may perform a predetermined number of retransmissions (also known as a blind retransmission scheme). In this case, steps 1110 and 1112 may be omitted.

[0202] Optionally, at 1114, Tx 12 generates one or more other vertical check blocks. Step 1114 can be performed based on determining at optional step 1112 that at least one Rx 14 has a reception failure. Optionally, step 1114 can be performed in a blind retransmission scheme as part of a predetermined number of retransmissions. At step 1106, an interleaver different from the interleaver used to generate the one or more vertical check blocks can be used to generate the other one or more vertical check blocks. Other configuration or control signals can be sent to Rx 14 to indicate parameters for generating the other one or more vertical check blocks.

[0203] Optionally, at 1115, a configuration signal or control signal (e.g., an RRC signal, a PC5-RRC signal, a DCI transmission, or an SCI transmission) may be sent by Tx 12 to provide one or more parameters for generating other one or more vertical check blocks to Rx 14, similar to step 1106 above. For example, step 1115 may occur in step 1116.

[0204] In some examples, the configuration signal or control signal for the other one or more vertical check blocks may not need to be sent, and thus step 1115 may be omitted. For example, the parameters for generating the one or more vertical check blocks may be predetermined (e.g., defined in the standard), and thus do not need to be sent from Tx 12 to each Rx 14, or the parameters for generating the other one or more vertical check blocks may have been indicated at step 1106.

[0205] Optionally, at 1116, at least one other vertical check block is sent to at least one Rx 14. The other one or more vertical check blocks may be sent to multiple Rx 14s (e.g., in a broadcast, multicast, or groupcast, similar to the initial transmission). In some examples, the other one or more vertical check blocks may be sent to all Rx 14s in a broadcast, multicast, or groupcast, regardless of whether a given Rx 14 successfully decodes the initial transmission. In other examples, the other one or more vertical check blocks may be sent in a multicast or groupcast only to Rx 14s that determined (at optional step 1112) that they failed to successfully decode the initial transmission. Fig. 11B In the example of , one other vertical check block (VCB3) is sent at 1156.

[0206] In some examples, the other one or more vertical check blocks sent at optional step 1116 may be from the vertical check blocks generated at step 1106 (in which case step 1114 may be omitted). For example, a subset of the one or more vertical check blocks generated may be included in the initial transmission, and the remaining one or more vertical check blocks may be sent at step 1116.

[0207] Optionally, the further steps of receiving feedback and sending one or more subsequent retransmissions may be performed as needed (e.g., based on a predetermined number of retransmissions). Fig. 11B In the example of , ACKs for all Rx 14 are received at 1158 .

[0208] In the above example, the sending node that sends the information CB in the initial transmission is also responsible for sending one or more vertical check blocks in the retransmission. However, it should be understood that in any example discussed in this article, at least one vertical check block can be sent by another auxiliary sending node. The vertical check blocks can be generated independently by different sending nodes without coordination. Therefore, multiple sending nodes can work together to implement the retransmission scheme. This is very suitable for blind retransmission schemes (e.g., for rateless codes), where the auxiliary sending node does not require feedback from the receiving node.

[0209] Fig. 12A 1 is a signaling diagram of an example of using two or more transmitting nodes to generate and transmit vertical check blocks in multicast, groupcast or broadcast transmission. In this example, there are two transmitting nodes (denoted as a first transmitting node Tx-1 12-1 and a second transmitting node Tx-2 12-2, collectively referred to as Tx 12). For simplicity, Fig. 12A Each Rx 14 is not shown individually, but it should be understood that each Tx 12 is transmitting to multiple Rx 14 . Fig. 12C Shown according to Fig. 12A, where there are three Rx 14. One or two Tx 12s may send a configuration signal or control signal to Rx 14 (e.g., before an initial transmission, before a retransmission, with a retransmission, in a retransmission, or immediately after a retransmission) to provide information about parameters for generating a vertical check block, but this is not shown in the figure. Such information may be necessary for Rx 14 to use the vertical check block to assist in decoding.

[0210] exist Fig. 12A In the example of, Tx-1 12-1 and Tx-2 12-2 can communicate with each other through a communication link. The communication link between Tx-1 12-1 and Tx-2 12-2 can be a backhaul link (for example, when Tx-1 12-1 and Tx-2 12-2 are both BS170) or any other wired or wireless communication link (for example, when Tx-1 12-1 and Tx-2 12-2 are both ED 110 sidelink). In other examples, Tx-1 12-1 and Tx-2 12-2 can communicate with each other through an inter-source link (for example, when Tx-1 12-1 and Tx-2 12-2 are different transmitting devices of the same source). In other examples, Tx-1 12-1 and Tx-2 12-2 may not communicate through a direct communication link, but Tx-2 12-2 can access or be configured with information CB or one or more vertical check blocks. For example, there may be another network entity that manages and configures both Tx-1 12-1 and Tx-2 12-2 (e.g., if both Tx-1 12-1 and Tx-2 12-2 are ED 110, then both Tx-1 12-1 and Tx-2 12-2 may be managed by BS 170), and the network entity may send information CB to Tx-1 and Tx-2, and the network entity enables Tx-2 12-2 to obtain CB or one or more vertical check blocks. For another example, Tx-2 12-2 may be a collaborative ED that provides collaboration to help Rx 14 receive information CB. Although Tx-1 12-1 sends information CB to multiple Rx 14 in the transmission at 1202, Tx-1 12-1 may also send information CB to Tx-2 12-2 through the same transmission 1202 or through another link.

[0211] At 1202, Tx-1 12-1 sends information CB in an initial transmission to Rx 14. In some examples, the initial transmission may optionally include one or more vertical check blocks.

[0212] Optionally, at 1204, Tx-1 12-1 may receive feedback from Rx 14. For example, in a feedback-based retransmission scheme, each Rx 14 may feedback an ACK or NACK depending on whether Rx 14 successfully decoded the initial transmission. In some examples, if Rx 14 successfully decoded the initial transmission, then Rx 14 may only provide optional ACK feedback, and otherwise provide no feedback. In some examples (e.g., in a blind retransmission scheme), there may not be any ACK or NACK feedback at all. Fig. 12C In the example shown, only Rx-1 14-1 successfully decodes all CBs and therefore sends back an ACK at 1204. Both Rx-2 14-2 and Rx-3 14-3 fail to successfully decode different CBs and therefore do not send any feedback at 1204.

[0213] If Tx-1 12-1 obtains feedback from Rx 14, Tx-1 12-1 may determine that at least one Rx 14 failed to successfully decode the initial transmission. Tx-1 12-1 may indicate to Tx-2 12-2 (e.g., via a communication link) that a retransmission is required. Tx-1 12-1 may also provide information CB to Tx-2 12-2 to generate one or more vertical check blocks, or may provide one or more vertical check blocks generated by Tx-1 12-1 to Tx-2 12-2. Tx-2 12-2 sends one or more vertical check blocks (e.g., Fig. 12C The transmission at 1206 may be for all Rx 14, or only for Rx 14 that failed to successfully decode the initial transmission (e.g., indicated by NACK feedback, or these Rx 14 did not send ACK feedback). Fig. 12C In the example of , the transmission at 1206 is sent to all Rx 14.

[0214] In other examples, Tx-2 12-2 may generate and send one or more vertical check blocks independently of Tx-1 12-1. For example, both Tx-1 12-1 and Tx-2 12-2 may be used to perform a predetermined number of transmissions / retransmissions. In addition, the transmissions of Tx-1 12-1 and Tx-2 12-2 at 1202 and 1206 may occur simultaneously or overlap in time.

[0215] Tx-1 12-1 can also perform one or more retransmissions, but not in Fig. 12A and Fig. 12C The one or more vertical check blocks respectively transmitted by Tx-1 12-1 and Tx-2 12-2 may be generated using different interleavers.

[0216] Optionally, at 1210, Tx-1 12-1 may receive feedback from Rx 14 indicating that the CB has been decoded successfully. Fig. 12C In the example of , all Rx 14 feed back ACK to Tx-1 12-1. The retransmission may end. In other examples, there may not be any feedback, and Tx-1 12-1 and / or Tx-2 12-2 may independently perform a predetermined number of retransmissions.

[0217] Fig. 12B is based on Fig. 12A Flowchart of an exemplary method 1250 of signaling example that may be performed by the second transmitting node Tx-2 12-2.

[0218] Optionally, at 1252, Tx-2 12-2 may receive configuration information indicating one or more parameters for generating one or more vertical check blocks (e.g., from Tx-1 12-1 or other network entity managing Tx-2 12-2). The configuration information may be received in a configuration signal or a control signal (e.g., an RRC signal, a PC5-RRC signal, a DCI transmission, or an SCI transmission), or received via a direct communication link. The signal may be used to indicate an NDI, a HARQ process ID, a number of repetitions, a number of one or more vertical check blocks sent, and parameters for generating one or more vertical check blocks, such as code block partitioning, interleaver selection, RV or RV sequence, coding rate, an index of a CB for generating one or more vertical check blocks, and / or other information related to generating one or more vertical check blocks, as described above.

[0219] In some examples, Tx-2 12-2 may already be configured with the configuration information, or the configuration information may be predetermined (eg, defined in a standard), and thus step 1252 may be omitted.

[0220] Optionally, at 1254, Tx-2 12-2 may obtain the CB (sent by Tx-1 12-1 in the initial transmission, e.g., Fig. 12A As described above, the CB may be obtained by Tx-2 12-2 in various ways, such as through a direct communication link between Tx-1 12-1 and Tx-2 12-2 or through another network entity (e.g., through DL, UL, or SL transmission). In some examples, the configuration information and the CB may be obtained simultaneously or together in the same transmission.

[0221] In some examples, Tx-2 12-2 may receive configuration information and CB from Tx-1 12-1 only after Tx-1 12-1 determines that at least one Rx 14 failed to successfully decode the initial transmission and needs to retransmit. In other examples, Tx-2 12-2 may generate one or more vertical check blocks and perform retransmissions independently of Tx-1 12-1.

[0222] At 1256, one or more vertical check blocks are generated (e.g., using one or more parameters indicated at optional step 1252). The one or more vertical check blocks are generated based on information bits selected from the two or two CBs sent by Tx-1 12-1 in the initial transmission. In some examples, Tx-2 12-2 can be configured with one or more vertical check blocks (e.g., transmitted via DL, UL, or SL), so step 1256 can be omitted.

[0223] At 1258, one or more vertical check blocks are sent to at least one Rx 14. In some examples, the one or more vertical check blocks may be sent in a broadcast, multicast, or groupcast to all Rx 14s, regardless of whether a given Rx 14 successfully decoded the initial transmission (e.g., in a blind retransmission scheme).

[0224] The present application describes some examples in conjunction with flow charts. It should be understood that the steps described can be performed in a different order than shown and can be applicable to any example disclosed herein.

[0225] The present application relates to vertical check blocks. It should be understood that, depending on the implementation, the vertical check block may also be referred to as a cross-packet check block, a cross-TB check block, or a cross-code block check block, etc. In addition, the check block may be equivalently referred to as a parity check block or a redundant block, etc. The use of the vertical check block may also be referred to as a network coding based on a product code.

[0226] The present application can be applicable to systematic codes (eg, LPDC codes or Turbo codes) and non-systematic codes (eg, polar codes, linear block codes or convolutional codes). That is, the vertical check blocks discussed herein can be generated based on CBs encoded using systematic codes or non-systematic codes.

[0227] This application describes HARQ retransmission using vertical check blocks in broadcast, multicast and groupcast scenarios. These examples can be applicable to feedback-based retransmission schemes as well as ACK / NACK-less or rate-less retransmission schemes.

[0228] One or more vertical check blocks may be generated for each retransmission. One or more vertical check blocks may be generated using bits selected from all CBs. In some cases, one or more vertical check blocks may be generated using bits selected from CBs belonging to different data packets.

[0229] The disclosed examples may be implemented in V2X applications or IoT applications, etc. Although some examples are discussed in the context of V2X, it should be understood that the examples described herein may be applicable to other applications.

[0230] A method is provided in Example 1 of the present application. The method comprises: sending two or more information CBs to multiple target receiving nodes; generating one or more cross-CB check blocks, wherein each cross-CB check block is generated according to a set of cross-CB bits, and the set of cross-CB bits includes at least one bit selected from each information CB in at least two of the information CBs; and sending at least one check block of the one or more cross-CB check blocks to at least one target receiving node among the multiple target receiving nodes.

[0231] Example 2 of the present application provides the method described in Example 1, wherein the two or more information CBs can be sent to the multiple target receiving nodes in a broadcast, multicast or groupcast transmission, and the at least one cross-CB check block can be sent to two or more target receiving nodes among the multiple target receiving nodes in a broadcast, multicast or groupcast transmission.

[0232] Example 3 of the present application provides the method described in Example 1 or Example 2, which also includes: receiving feedback from the multiple target receiving nodes indicating whether the corresponding target receiving nodes successfully decode the two or more information CBs; after determining, based on the feedback, that at least one of the multiple target receiving nodes failed to successfully decode the two or more information CBs, sending the at least one cross-CB check block.

[0233] Example 4 of the present application provides the method described in Example 3, wherein a negative acknowledgement NACK feedback is received to indicate that the corresponding target receiving node has failed to successfully decode the two or more information CB.

[0234] Example 5 of the present application provides the method described in Example 3, wherein the corresponding target receiving node has no positive acknowledgement ACK feedback indicating that the corresponding target receiving node has failed to successfully decode the two or more information CB.

[0235] Example 6 of the present application provides the method described in Example 3, wherein the at least one cross-CB check block is only sent to at least one target receiving node among the multiple target receiving nodes that failed to successfully decode the two or more information CBs.

[0236] In Example 7 of the present application, the method described in Example 1 or Example 2 is provided, wherein the at least one cross-CB check block is sent to all of the multiple target receiving nodes.

[0237] Example 8 of the present application provides the method described in Example 7, wherein the at least one cross-CB check block is sent without any feedback from the multiple target receiving nodes.

[0238] Example 9 of the present application provides the method described in Example 8, wherein the corresponding one or more cross-CB check blocks are sent in the corresponding retransmission for a predetermined number of retransmissions without requiring any feedback from any of the multiple target receiving nodes regarding the initial transmission.

[0239] Example 10 of the present application provides the method described in Example 1 or Example 2, wherein the two or more information CBs are sent to the multiple target receiving nodes in at least two separately sent data packets, and the one or more cross-CB check blocks are generated based on bits selected from the CB of each of the at least two data packets.

[0240] Example 11 of the present application provides the method described in Example 10, which also includes: receiving feedback indicating whether at least one target receiving node has failed to successfully decode at least one data packet; generating the one or more cross-CB check blocks based on bits selected only from the at least one data packet that failed to be successfully decoded.

[0241] Example 12 of the present application provides the method described in Example 11, wherein at least one check block among the one or more cross-CB check blocks is only sent to at least one target receiving node that failed to successfully decode the at least one data packet.

[0242] Example 13 of the present application provides the method described in Example 10, wherein at least one of the one or more cross-CB check blocks is sent without any feedback from the multiple target receiving nodes.

[0243] Example 14 of the present application provides the method described in Example 1 or Example 2, wherein the at least one cross-CB check block is sent together with the two or more information CBs in a single transmission.

[0244] Example 15 of the present application provides the method described in Example 14, which also includes: determining the number of cross-CB check blocks sent in the single transmission together with the two or more information CBs based on channel feedback received from the multiple target receiving nodes.

[0245] Example 16 of the present application provides a method described in any one of Examples 1 to 14, which further includes: sending a configuration signal or a control signal to the multiple target receiving nodes, wherein the configuration signal includes information about one or more parameters used to generate the one or more cross-CB check blocks.

[0246] Example 17 of the present application provides the method described in Example 16, wherein the configuration signal or control signal includes information about one or more of the following: an indication of a new transmission or retransmission; a HARQ process identifier; the number of retransmission repetitions; the number of cross-CB check blocks sent; an index of the two or more information CBs used to generate the one or more cross-CB check blocks; an interleaver used to generate the one or more cross-CB check blocks; or an indication of how to generate a redundant version RV or RV sequence of one or more cross-CB check blocks.

[0247] Example 18 of the present application provides a method described in any one of Examples 1 to 17, the method further comprising: receiving a configuration signal or a control signal, wherein the configuration signal or the control signal includes information about one or more parameters used to generate the one or more cross-CB check blocks.

[0248] Example 19 of the present application provides a method described in any one of Examples 1 to 18, which is used to generate a set of cross-CB bits for the one or more cross-CB check blocks selected according to a predefined interleaver.

[0249] Example 20 of the present application provides the method described in Example 19, which also includes: generating one or more other cross-CB check blocks based on another set of cross-CB bits, wherein the other set of cross-CB bits is selected based on another predefined interleaver.

[0250] Example 21 of the present application provides a method described in any one of Examples 1 to 20, which also includes: receiving a scheduling resource allocation for sending the two or more information CBs from a base station; receiving feedback indicating whether at least one target receiving node has failed to successfully decode at least one of the two or more information CBs; sending a negative acknowledgement (NACK) report to the base station; and receiving other scheduling resource allocations from the base station for sending the at least one cross-CB check block.

[0251] Example 22 of the present application provides a method described in any one of Examples 1 to 20, which also includes: receiving from a base station a scheduling resource allocation for sending the two or more information CBs and for a predetermined number of cross-CB check block transmissions.

[0252] Example 23 of the present application provides a method described in any one of Examples 1 to 20, which further includes: selecting resources from a resource pool for sending the two or more information CBs.

[0253] Example 24 of the present application provides a method described in any one of Examples 1 to 20, which further includes: selecting resources from a resource pool for sending the two or more information CBs and for a predetermined number of cross-CB check block transmissions.

[0254] A method is provided in Example 25 of the present application, the method comprising: receiving information for generating one or more cross-code block CB check blocks, wherein each cross-CB check block is generated based on a set of cross-CB bits, and the set of cross-CB bits includes at least one bit selected from each information CB in at least two information CBs; and sending at least one check block of the one or more cross-CB check blocks to multiple target receiving nodes.

[0255] Example 26 of the present application provides the method described in Example 25, wherein the at least one cross-CB check block is sent to the multiple target receiving nodes in a broadcast, multicast or groupcast transmission.

[0256] Example 27 of the present application provides the method described in Example 25 or Example 26, wherein the received information includes the at least two pieces of information CB.

[0257] Example 28 of the present application provides a method described in any one of Examples 25 to 27, wherein the received information includes information about one or more parameters used to generate the one or more cross-CB check blocks.

[0258] Example 29 of the present application provides the method described in Example 28, wherein the received information includes information about one or more of the following: an indication of a new transmission or retransmission; a HARQ process identifier; the number of retransmission repetitions; the number of cross-CB check blocks sent; an index of the two or more information CBs used to generate the one or more cross-CB check blocks; an interleaver used to generate the one or more cross-CB check blocks; or an indication of how to generate a redundant version RV or RV sequence of one or more cross-CB check blocks.

[0259] Example 30 of the present application provides a method described in any one of Examples 1 to 29, which is performed in a connected vehicle.

[0260] Example 31 of the present application provides a method described in any one of Examples 1 to 29, which is performed in a user device.

[0261] Example 32 of the present application provides a method described in any one of Examples 1 to 20 or Examples 25 to 29, which is performed in a base station.

[0262] Example 33 of the present application provides a method described in any one of Examples 1 to 32, wherein the CB is encoded using a system code.

[0263] Example 34 of the present application provides the method described in Example 33, wherein the CB is encoded using a low density parity check (LDPC) code or a Turbo code.

[0264] Example 35 of the present application provides a method described in any one of Examples 1 to 32, wherein the CB is encoded using a non-systematic code.

[0265] The method described in Example 35 is provided in Example 36 of the present application, wherein the CB is encoded using a polar code, a linear block code or a convolutional code.

[0266] In Example 37 of the present application, a device is provided including a processing unit, wherein the processing unit is used to execute machine-readable instructions so that the device performs any method described in Examples 1 to 36.

[0267] Example 38 of the present application provides a computer-readable medium storing machine-executable instructions. When a processing unit in a device executes the instructions, the instructions cause the device to execute any one of the methods described in Examples 1 to 36.

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

[0269] Although the present application is at least partially described in terms of methods, it will be understood by those of ordinary skill in the art that the present application is also directed to various components for performing at least some aspects and features of the method, whether by hardware components, software, or any combination thereof. Accordingly, the technical solution of the present application can be embodied in the form of a software product. Suitable software products can be stored in pre-recorded storage devices or other similar non-volatile or non-transient computer-readable media, including DVDs, CD-ROMs, USB flash drives, removable hard disks, or other storage media. The software product includes instructions tangibly stored thereon, which enable a processing device (e.g., a personal computer, a server, or a network device) to perform examples of the methods disclosed herein. Machine executable instructions can be in the form of code sequences, configuration information, or other data, which, when executed, cause a machine (e.g., a processor or other processing device) to perform steps in the method according to the examples of the present application.

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

[0271] All values ​​and subranges within the disclosed ranges are also disclosed. In addition, although the systems, devices, and processes disclosed and shown herein may include a specific number of elements / components, the systems, devices, and components may be modified to include more or less elements / components in such elements / components. For example, although any disclosed element / component may be cited as a single quantity, the embodiments disclosed herein may be modified to include a plurality of such elements / components. The subject matter described herein is intended to cover and encompass all appropriate technical changes.

Claims

1. An information transmission method, characterized in that: The method comprises: Sending two or more information code blocks CB to a plurality of target receiving nodes, wherein each of the two or more information code blocks CB comprises an information block and a block specific check block generated according to the information block; generating one or more cross-CB check blocks, wherein each cross-CB check block is generated based on a set of cross-CB bits, wherein the set of cross-CB bits includes a portion of bits of each of the at least two information CBs selected from vertical columns of the at least two information CBs, wherein before the selecting, at least one of the at least two information CBs is bit-shuffled; At least one cross-CB check block of the one or more cross-CB check blocks is sent to at least one target receiving node of the plurality of target receiving nodes.

2. The method according to claim 1, characterized in that The two or more information CBs are sent to the multiple target receiving nodes in broadcast, multicast or groupcast transmission, and the at least one cross-CB check block is sent to two or more target receiving nodes among the multiple target receiving nodes in broadcast, multicast or groupcast transmission.

3. The method according to claim 1 or 2, characterized in that: The feedback of the plurality of target receiving nodes indicates whether the corresponding target receiving nodes successfully decode the two or more information CBs; The method further comprises: After determining that at least one of the plurality of target receiving nodes fails to successfully decode the two or more information CBs according to receiving negative acknowledgement (NACK) feedback or not receiving positive acknowledgement (ACK) feedback, the at least one cross-CB check block is sent.

4. The method according to claim 3, characterized in that A NACK feedback is received to indicate that the corresponding target receiving node fails to successfully decode the two or more information CBs.

5. The method according to claim 3, characterized in that: The failure to receive the positive acknowledgement ACK fed back by the corresponding target receiving node indicates that the corresponding target receiving node fails to successfully decode the two or more information CB.

6. The method according to claim 3, characterized in that The at least one cross-CB check block is sent only to at least one target receiving node among the multiple target receiving nodes that fails to successfully decode the two or more information CBs.

7. The method according to claim 1 or 2, characterized in that: The at least one cross-CB check block is sent to all the multiple target receiving nodes, and the at least one cross-CB check block is sent when none of the multiple target receiving nodes provides any feedback.

8. The method according to claim 1 or 2, characterized in that: The corresponding one or more cross-CB check blocks are sent in corresponding retransmissions for a predetermined number of retransmissions without requiring any feedback from any of the plurality of target receiving nodes for the initial transmission.

9. The method according to claim 1 or 2, characterized in that: The method further comprises: After the initial transmission or a given retransmission, receiving an ACK feedback from at least one target receiving node, Wherein, any retransmission after the initial transmission or the given retransmission is not sent to at least one target receiving node that receives the ACK feedback.

10. The method according to claim 1 or 2, characterized in that: In the absence of negative acknowledgment NACK feedback, repeatedly sending at least one check block of the one or more cross-CB check blocks to the multiple target receiving nodes, Until positive acknowledgement ACK feedbacks from all the multiple target receiving nodes are received.

11. The method according to claim 1 or 2, characterized in that: The two or more information CBs are sent to the multiple target receiving nodes in at least two separately sent data packets, and the one or more cross-CB check blocks are generated based on bits selected from the CB of each of the at least two data packets.

12. The method according to claim 11, characterized in that The method further comprises: receiving feedback indicating whether at least one intended receiving node failed to successfully decode at least one data packet; The one or more cross-CB check blocks are generated based on bits selected only from the at least one data packet that failed to be successfully decoded.

13. The method according to claim 12, characterized in that At least one check block among the one or more cross-CB check blocks is only sent to at least one target receiving node that failed to successfully decode the at least one data packet.

14. The method according to claim 11, characterized in that At least one check block among the one or more cross-CB check blocks is sent without any feedback from the multiple target receiving nodes.

15. The method according to claim 1 or 2, characterized in that: The at least one cross-CB check block is sent together with the two or more information CBs in a single transmission.

16. The method according to claim 15, characterized in that The method further comprises: The number of cross-CB check blocks sent together with the two or more information CBs in the single transmission is determined according to channel feedback received from the plurality of target receiving nodes.

17. The method according to claim 1 or 2, characterized in that: The method further comprises: sending a control signal to the plurality of target receiving nodes, wherein the control signal indicates information about one or more parameters for generating the one or more cross-CB check blocks, The control signal indicates information about one or more of the following: indication of new transmission or retransmission; HARQ process identifier; The number of retransmissions; The number of cross-CB check blocks sent; An index of the two or more information CBs for generating the one or more cross-CB check blocks; an interleaver for generating the one or more cross-CB check blocks; or Indicates how to generate the redundancy version RV or RV sequence of one or more cross-CB check blocks.

18. The method according to claim 1 or 2, characterized in that: The method further comprises: receiving a resource allocation for sending the two or more information CBs from a base station, The resources used to send the at least one cross-CB check block are also allocated by the base station.

19. The method according to claim 18, characterized in that The method further comprises: receiving feedback indicating whether at least one target receiving node failed to successfully decode at least one of the two or more information CBs; Sending a negative acknowledgement (NACK) report to the base station; Other resource allocations for sending the at least one cross-CB check block are received from the base station.

20. The method according to claim 18, characterized in that Resources for a predetermined number of cross-CB check block transmissions are also allocated in the resource allocation of the base station.

21. The method according to claim 1 or 2, characterized in that: The method further comprises: selecting resources from a resource pool for sending the two or more messages CB, The resources used to send the at least one cross-CB check block are also selected from the resource pool.

22. The method according to claim 1 or 2, characterized in that The method is performed in a networked vehicle.

23. The method according to claim 1 or 2, characterized in that The method is executed in a user equipment.

24. The method according to claim 1 or 2, characterized in that The method is executed in a base station.

25. An information transmission method, characterized in that: The method comprises: Receiving information for generating one or more cross-code block CB check blocks, wherein each cross-CB check block is generated according to a set of cross-CB bits, wherein the set of cross-CB bits comprises a portion of bits of each of the at least two information CBs selected from vertical columns of the at least two information CBs, wherein before the selection, at least one of the at least two information CBs is bit-shuffled; Each of the at least two information CBs includes an information block and a block-specific check block generated according to the information block; At least one cross-CB check block of the one or more cross-CB check blocks is sent to multiple target receiving nodes.

26. The method according to claim 25, characterized in that The at least one cross-CB check block is sent to the multiple target receiving nodes in a broadcast, multicast or groupcast transmission.

27. The method according to claim 25 or 26, characterized in that Said received information comprises said at least two pieces of information CB.

28. The method according to claim 25 or 26, characterized in that The received information includes information about one or more parameters used to generate the one or more cross-CB check blocks, wherein the received information includes information about one or more of the following: indication of new transmission or retransmission; HARQ process identifier; The number of retransmissions; The number of cross-CB check blocks sent; An index of the two or more information CBs for generating the one or more cross-CB check blocks; an interleaver for generating the one or more cross-CB check blocks; or Indicates how to generate the redundancy version RV or RV sequence of one or more cross-CB check blocks.

29. The method according to claim 25 or 26, characterized in that The method is performed in a networked vehicle.

30. The method according to claim 25 or 26, characterized in that The method is executed in a user equipment.

31. The method according to claim 25 or 26, characterized in that The method is executed in a base station.

32. A device comprising a processing unit, characterized in that The processing unit is configured to execute machine-readable instructions so that the apparatus performs the method according to any one of claims 1 to 31.

33. A computer readable medium storing machine executable instructions, characterized in that: When a processing unit in a device executes the instructions, the instructions cause the device to perform the method according to any one of claims 1 to 31.

34. A software product comprising instructions, characterized in that When the instructions are executed on a processor, the method according to any one of claims 1 to 31 is executed.

Images