Method and apparatus for broadcast, multicast, or group-cast transmission using vertical check block

Abstract

To describe a two-dimensional (2D) coding method and system, regarding broadcast, multicast, or group-cast applications.SOLUTION: Two or more information code blocks (CBs) are transmitted to a plurality of intended receiving nodes. One or more cross CB check blocks are generated, each cross CB check block is generated based on a set of cross CB bits, the set of cross CB bits includes at least one bit selected from each of at least two of the information CBs. At least one cross CB check block is transmitted to at least one of the intended receiving nodes.SELECTED DRAWING: Figure 8D

Description

[Technical Field]

[0001] [Related Applications] This disclosure claims priority to U.S. Provisional Patent Application No. 63 / 053,337, filed July 17, 2020, entitled "METHODS AND APPARATUSES FOR BROADCAST MULTICAST OR GROUPCAST ​​TRANSMISSION USING VERTICAL CHECK BLOCKS," and U.S. Patent Application No. 17 / 368,500, filed July 6, 2021, entitled "METHODS AND APPRATUSES FOR BROADCAST MULTICAST OR GROUPCAST ​​TRANSMISSION USING VERTICAL CHECK BLOCKS," the entire contents of which are incorporated herein by reference.

[0002] [Technical field] The present disclosure relates to wireless communications, including the use of product coding in broadcast, multicast, or groupcast wireless communications. [Background technology]

[0003] In general cellular communications, unicast transmission is a common scenario. "Unicast" means that a single transmitting node transmits to a single receiving node. Broadcast and multicast transmission are increasingly used in cellular systems, such as Multimedia Broadcast Multicast Services (MBMS). "Broadcast" means that one transmitting node transmits to all nodes connected to the transmitting node. "Multicast" means that one transmitting node transmits to multiple intended receiving nodes. Applications for broadcast and multicast communications continue to develop, especially for multimedia services and vehicle-to-everything (V2X) communications.

[0004] V2X refers to a category of communication scenarios involving vehicles (acting as user equipment (UE)), including vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), vehicle-to-pedestrian (V2P), and many other scenarios. Long-term evolution-vehicle (LTE-V) is a standard for supporting V2X communications using Long-term evolution (LTE) cellular technology. LTE-V primarily focuses on broadcasting messages, such as safety messages. However, there is interest in other applications. For example, New Radio (NR)-V2X is based on NR cellular technology and supports broadcast, groupcast (a form of multicast between UEs), and unicast. Groupcast and unicast applications may support retransmission based on feedback, while broadcast may only support blind retransmission (i.e., retransmission / repetition without feedback). In a broadcast, multicast, or groupcast scenario, errors in received data may vary from one receiving node to another, and existing retransmission schemes may not be suitable or efficient for broadcast, multicast, or groupcast scenarios. Summary of the Invention

[0005] In various examples, this disclosure describes methods and apparatus for physical (PHY) layer network coding based on two-dimensional (2D) joint coding. The disclosed examples may be applicable to broadcast, multicast, and groupcast transmissions, among other applications.

[0006] Retransmission schemes used in conventional broadcast, multicast, and groupcast transmission approaches suffer from inefficiencies, delays, and overhead. These conventional retransmission schemes typically rely on retransmitting entire transport blocks or code block groups in a highly redundant manner. Furthermore, retransmission in broadcast, multicast, and groupcast scenarios complicates the problem because different receivers may have different undecoded code blocks, necessitating the retransmission of entire transport blocks or multiple code block groups. Retransmissions based on non-erasure codes, when used in non-erasure channels, can suffer from performance penalties because undecoded code blocks are discarded and soft information for joint decoding is not preserved.

[0007] Embodiments of the present disclosure that utilize PHY-layer network coding based on 2D joint coding address or ameliorate some or all of these drawbacks. Thus, the disclosed methods and apparatus can avoid the costly and inefficient retransmissions of conventional approaches. Furthermore, the ability to utilize soft information from failed decoding attempts provides improved performance over retransmission schemes based on non-erasure codes. In the examples described herein, a single vertical check block can be multicast or broadcast to different receivers and used for decoding by the different receivers, even if the different receivers have different erroneous code blocks in the initial transmission.

[0008] In an exemplary aspect, the present disclosure provides a method, comprising: transmitting two or more information code blocks (CB) to a plurality of intended receiving nodes; generating one or more cross CB check blocks, each cross CB check block being generated based on a set of cross CB bits, the set of cross CB bits including at least one bit selected from each of at least two information CBs; transmitting at least one of the one or more cross CB check blocks to at least one of the intended receiving nodes; A method is described that includes:

[0009] In the aforementioned aspects of the method, the two or more information CBs may be transmitted to the plurality of intended receiving nodes in a broadcast, multicast, or groupcast transmission, and the at least one cross CB check block may be transmitted to two or more intended receiving nodes in a broadcast, multicast, or groupcast transmission.

[0010] In any of the aforementioned aspects of the method, the feedback from the intended receiving nodes may indicate whether each intended receiving node successfully decoded two or more of the information CBs. The method may further include transmitting the at least one cross CB check block after determining from received negative acknowledgement (NACK) feedback or a lack of acknowledgement (ACK) feedback that at least one of the intended receiving nodes did not successfully decode the two or more of the information CBs.

[0011] In any of the aforementioned aspects of the method, each set of one or more cross CB check blocks may be transmitted in each retransmission for a predetermined number of retransmissions without requiring feedback from any of the intended receiving nodes for the initial transmission.

[0012] In any of the aforementioned aspects of the method, the method may further include receiving, after the initial transmission or after a given retransmission, an acknowledgement (ACK) feedback from at least one intended receiving node, wherein retransmissions after the initial transmission or the given retransmission may not be sent to the at least one intended receiving node that received the ACK feedback.

[0013] In any of the aforementioned aspects of the method, if negative acknowledgement (NACK) feedback is absent, transmission of at least one of the one or more cross CB check blocks to the plurality of intended receiving nodes may be repeated until acknowledgement (ACK) feedback is received from each of the plurality of intended receiving nodes.

[0014] In any of the aforementioned aspects of the method, the two or more information CBs may be transmitted to the plurality of intended receiving nodes in at least two separately transmitted packets, and one or more cross CB check blocks may be generated based on selected bits from the CBs of each of the at least two packets.

[0015] In any of the foregoing aspects of the method, the method may further include transmitting a configuration or control signal to the intended receiving node, the configuration or control signal including information regarding one or more parameters used to generate the one or more cross CB check blocks. Instructions for new transmission or retransmission, HARQ process identifier, The number of retransmission iterations, Number of cross CB check blocks sent, Indices 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 a redundancy version (RV) or RV sequence indicating how the one or more cross CB check blocks were generated; The information may include information about one or more of the following:

[0016] In any of the aforementioned aspects of the method, the method may further include receiving, from a base station, a scheduled resource allocation for transmitting the two or more information CBs. Resources for transmitting the at least one cross CB check block may be allocated by the base station.

[0017] In the foregoing aspects of the method, the method further comprises: receiving feedback from at least one intended receiving node indicating whether at least one of said two or more pieces of information CB was not successfully decoded; sending a negative acknowledgement (NACK) report to the base station; receiving, from the base station, an additional scaled resource allocation for transmitting the at least one cross CB check block; It may further include:

[0018] In any of the foregoing aspects of the method, the resource allocation from the base station may also allocate resources for transmission of a predetermined number of cross CB check blocks.

[0019] In any of the aforementioned aspects of the method, the method may further include selecting resources from a resource pool for transmitting the two or more information CBs. Resources for transmitting the at least one cross CB check block may be selected from the resource pool.

[0020] In an exemplary aspect, the present disclosure describes an apparatus including a processing unit configured to execute machine-readable instructions that cause the apparatus to: transmitting two or more information code blocks (CB) to a plurality of intended receiving nodes; generating one or more cross CB check blocks, each cross CB check block being generated based on a set of cross CB bits, the set of cross CB bits including at least one bit selected from each of at least two information CBs; causing at least one of the one or more cross CB check blocks to be transmitted to at least one of the intended receiving nodes;

[0021] In the above-described aspects of the device, the two or more information CBs may be transmitted to the plurality of intended receiving nodes in a broadcast, multicast, or groupcast transmission, and the at least one cross CB check block may be transmitted to the two or more intended receiving nodes in a broadcast, multicast, or groupcast transmission.

[0022] In any of the aforementioned aspects of the device, the feedback from the intended receiving nodes may indicate whether each intended receiving node successfully decoded two or more of the information CBs. The processing unit may be further configured to execute the instructions to cause the device to transmit the at least one cross CB check block after determining from received negative acknowledgement (NACK) feedback or a lack of acknowledgement (ACK) feedback that at least one of the intended receiving nodes did not successfully decode the two or more of the information CBs.

[0023] In any of the aforementioned aspects of the device, each set of one or more cross CB check blocks may be transmitted in each retransmission for a predetermined number of retransmissions without requiring feedback from any of the intended receiving nodes for the initial transmission.

[0024] In any of the aforementioned aspects of the device, the processing unit may be configured to execute the instructions to cause the device to send configuration or control signals to the intended receiving node, the configuration or control signals including information regarding one or more parameters used to generate the one or more cross CB check blocks. Instructions for new transmission or retransmission, HARQ process identifier, The number of retransmissions, Number of cross CB check blocks sent, Indices 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 a redundancy version (RV) or RV sequence indicating how the one or more cross CB check blocks were generated; The information may include information about one or more of the following:

[0025] In any of the aforementioned aspects of the device, the processing unit may be further configured to execute the instructions to cause the device to receive from a base station a scheduled resource allocation for transmitting the two or more information CBs, and the resources for transmitting the at least one cross CB check block may be allocated by the base station.

[0026] In any of the aforementioned aspects of the device, the processing unit may be further configured to execute the instructions to cause the device to select resources from a resource pool for transmitting the two or more information CBs, and the resources for transmitting the at least one cross CB check block may be selected from the resource pool.

[0027] In any of the aforementioned aspects of the device, the processing unit may be further configured to execute the instructions to cause the device to perform any of the aforementioned method aspects.

[0028] In an exemplary aspect, the present disclosure describes a computer-readable medium having machine-readable instructions stored thereon that, when executed by a processing unit of a device, cause the device to: transmitting two or more information code blocks (CB) to a plurality of intended receiving nodes; generating one or more cross CB check blocks, each cross CB check block being generated based on a set of cross CB bits, the set of cross CB bits including at least one bit selected from each of at least two information CBs; causing at least one of the one or more cross CB check blocks to be transmitted to at least one of the intended receiving nodes;

[0029] In any aspect of the computer readable medium, the instructions, when executed by a processing unit of a device, may cause the device to perform any of the method aspects described above. [Brief explanation of the drawings]

[0030] By way of example, reference is made to the following accompanying drawings which illustrate exemplary embodiments of the present application:

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

[0032] [Figure 2] FIG. 1 is a block diagram illustrating an example of a base station (BS) suitable for implementing the examples described herein. [Figure 3] FIG. 1 is a block diagram illustrating an example of an electronic device (ED) suitable for implementing the examples described herein.

[0033] [Figure 4A] 1 shows an example of a coding structure for a single transport block (TB) containing a horizontal check block and a vertical check block. [Figure 4B]1 shows an example of a coding structure for a single transport block (TB) containing a horizontal check block and a vertical check block.

[0034] [Figure 5A] 10 illustrates an example of using different interleavers to generate different sets of vertical check blocks. [Figure 5B] 10 illustrates an example of using different interleavers to generate different sets of vertical check blocks.

[0035] [Figure 6] 1 shows an example of a code structure for a single TB based on a non-systematic code containing vertical check blocks.

[0036] [Figure 7] 1 shows an example of a code structure for generating vertical check blocks from multiple TBs.

[0037] [Figure 8A] FIG. 10 is a signaling diagram illustrating an example of using vertical check blocks in a broadcast, multicast, or groupcast transmission. [Figure 8B] FIG. 10 is a signaling diagram illustrating an example of using vertical check blocks in a broadcast, multicast, or groupcast transmission.

[0038] [Figure 8C] 8C is a flowchart illustrating an example of a method that may be performed by a transmitting node in accordance with FIGS. 8A and 8B.

[0039] [Figure 8D] 8A and 8B show examples of code blocks that are transmitted. [Figure 8E] 8A and 8B show examples of code blocks that are transmitted.

[0040] [Figure 9A]1 is a flowchart illustrating an example of a method that may be performed by a transmitting node to obtain resources for transmission and retransmission in a groupcast scenario. [Figure 9B] 1 is a flowchart illustrating an example of a method that may be performed by a transmitting node to obtain resources for transmission and retransmission in a groupcast scenario.

[0041] [Figure 10A] FIG. 10 is a signaling diagram illustrating an example of using a cross-packet vertical check block for broadcast, multicast, or groupcast transmissions. [Figure 10B] FIG. 10 is a signaling diagram illustrating an example of using a cross-packet vertical check block for broadcast, multicast, or groupcast transmissions.

[0042] [Figure 10C] 10A and 10B is a flowchart illustrating an example of a method that may be performed by a transmitting node.

[0043] [Figure 10D] 10A and 10B show examples of code blocks that are transmitted. [Figure 10E] 10A and 10B show examples of code blocks that are transmitted.

[0044] [Figure 11A] 10 is a flowchart illustrating an example of a method that may be performed by a transmitting node to include a vertical check block in an initial transmission.

[0045] [Figure 11B] The example of FIG. 11A shows an example of a code block that is transmitted.

[0046] [Figure 12A]FIG. 1 is a signaling diagram illustrating an example in which multiple transmitting nodes are involved in a broadcast, multicast, or groupcast transmission.

[0047] [Figure 12B] 12B is a flowchart illustrating an example of a method that may be performed by a transmitting node according to FIG. 12A.

[0048] [Figure 12C] The example of FIG. 12A shows an example of a code block that is transmitted.

[0049] Similar reference numbers may be used in different figures to indicate similar components. DETAILED DESCRIPTION OF THE INVENTION

[0050] Various examples described herein describe methods and devices for implementing retransmission or network coding based on HARQ. The examples described herein help address the challenges of retransmission of broadcast, multicast, or groupcast transmissions. For example, in broadcast, multicast, or groupcast transmissions, each receiving node may have reception errors in different code blocks, and the transmission channel is typically not an erasure channel.

[0051] To aid in understanding the present disclosure, some existing approaches for retransmission are described.

[0052] Hybrid Automatic Repeat Request (H-ARQ or HARQ) is a common feature of wireless physical layer retransmission. A typical HARQ implementation involves the use of incremental redundancy (IR)-based retransmissions, which transmit additional bits of an unsent mother code when an initial transmission fails. That is, the mother code is stored in a circular buffer, and after an initial code block containing bits from the mother code is transmitted, the transmitter transmits new IR bits from the circular buffer as part of the HARQ process. The new IR bits, along with the previously transmitted data, form a new code block. This is repeated until either the maximum number of retransmissions is reached or the code block is successfully decoded.

[0053] HARQ retransmission schemes include feedback-based retransmission schemes and blind retransmission schemes. In feedback-based retransmission, the receiving node often sends an acknowledgement (ACK) or negative acknowledgement (NACK) back to the transmitting node. Upon receiving a NACK, a retransmission is sent. In blind retransmission, an ACK / NACK response from the receiving node is optional. Instead, the transmitting node sends a predetermined number of retransmissions. In groupcast SL transmission, there may be different options for the receiving node to send an ACK / NACK. In one option, the receiving node sends only a NACK (no ACK is sent for successful reception). All receiving nodes share the same physical sidelink feedback channel (PSFCH) resource, and as a result, the transmitting node may not know which receiving node sent which NACK. In another option, each receiving node has its own PSFCH resource dedicated for sending ACK / NACK feedback.

[0054] Various retransmission schemes based on forward error correction (FEC) have been considered for broadcast or multicast transmissions. Some of these existing approaches are described below.

[0055] Fountain codes are a type of rateless code. They are suitable for broadcast or multicast transmissions without feedback. Conventional Multimedia Broadcast Multimedia Services (MBMS) systems use raptor codes, an implementation of fountain codes, for HARQ retransmissions and application-layer FEC without HARQ feedback. However, fountain codes are designed for higher-layer feedback rather than lower-level feedback (e.g., the transport block or code block level of the physical (PHY) layer). Compared to solutions using PHY-layer retransmissions, fountain codes have long retransmission delays and are not suitable for low-latency applications. Furthermore, because fountain codes are erasure codes, they degrade the performance of transmissions in non-erased channels.

[0056] Another existing approach is erasure outer code. In outer erasure code, a parity code block is generated based on multiple code blocks for HARQ retransmissions. The parity code block can be used to correct different erasure information code blocks. However, transmission over a non-erasure channel results in poor performance because undecoded code blocks are completely discarded. This means that each parity code block can only correct for one undecoded code block.

[0057] To facilitate understanding of the present disclosure, an example wireless communication system will first be described.

[0058] FIG. 1 illustrates an example of a wireless communication system 100 (also referred to as wireless system 100) in which embodiments of the present disclosure can be implemented. Generally, wireless system 100 enables multiple wireless or wired elements to communicate data and other content. Wireless system 100 enables content (e.g., voice, data, video, text, etc.) to be communicated between entities of system 100 (e.g., via 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 later generation wireless technologies. In some examples, wireless system 100 may also support some legacy wireless technologies (e.g., 3G or 4G wireless technologies).

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

[0060] The EDs 110 are configured to operate, communicate, or both in the wireless system 100. For example, the EDs 110 may be configured to transmit, receive, or both over wireless or wired communication channels. Each ED 110 represents any end-user device suitable for wireless operation and may include (or may be referred to as) a user equipment (UE), a wireless transmit / receive unit (WTRU), a mobile station, a mobile relay station, a fixed or mobile subscriber unit, a cell phone, a station (STA), a machine type communication (MTC) device, a personal digital assistant (PDA), a smartphone, a laptop, a computer, a tablet, a wireless sensor, an Internet of Things (IoT) device, a network-enabled vehicle, or a consumer electronics device, among others. Future generations of EDs 110 may be referred to using other terminology.

[0061] In Figure 1, the RANs 120 include base stations (BSs) 170. While Figure 1 shows each RAN 120 including a single respective BS 170, it should be understood that any given RAN 120 can include multiple BSs 170, and that any given RAN 120 can also include base station controllers (BSCs), radio network controllers (RNCs), relay nodes, elements, and / or devices. Each BS 170 is configured to interface wirelessly with one or more EDs 110 to enable access to other BSs 170, the core network 130, the PSTN 140, the Internet 150, and / or other networks 160. For example, the BS 170 may also be referred to as a base transceiver station (BTS), a radio base station, a 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, among other possibilities. Future generation BSs 170 may be referred to using other terminology. Any ED 110 may alternatively or additionally be configured to interface with, access, or communicate with other BSs 170, the Internet 150, the core network 130, the PSTN 140, other networks 160, or any combination of the above. In some examples, the BS 170 may access the core network 130 via the Internet 150.

[0062] The ED 110 and the BS 170 are examples of communication equipment that can be used to implement some or all of the functionality and / or embodiments described herein. Any BS 170 may be a single element as shown, or multiple elements distributed across a corresponding RAN 120, or otherwise. Each BS 170 transmits and / or receives radio signals within a particular geographic region or area, sometimes referred to as a "cell" or "coverage area." Cells are further divided into cell sectors; for example, a BS 170 may serve multiple sectors using multiple transceivers. In some embodiments, pico- or femto-cells may be established where the radio access technology supports them. A macro-cell may include one or more smaller cells. In some embodiments, multiple transceivers may be used for each cell, for example, using multiple-input multiple-output (MIMO) technology. The number of RANs 120 shown is for illustrative purposes only. Any number of RANs may be considered when designing the wireless system 100.

[0063] The BS 170 communicates with one or more EDs 110 via one or more uplink (UL) / downlink (DL) air interfaces 190 (e.g., via radio frequency (RF), microwave, infrared (IR), etc.). The UL / DL interface 190 may also be referred to as, for example, a UL / DL connection, an ED-BS link / connection / interface, or an ED network link / connection / interface. The EDs 110 may also communicate directly with each other (i.e., without going through the BS 170) via one or more sidelink (SL) air interfaces 195. The SL interface 195 may also be referred to as, for example, an SL connection, a UE-to-UE link / connection / interface, a Vehicle-to-Vehicle (V2V) link / connection / interface, a Vehicle-to-Everything (V2X) link / connection / interface, a Vehicle-to-Infrastructure (V2I) link / connection / interface, a Vehicle-to-Pedestrian (V2P) link / connection / interface, an ED-ED link / connection / interface, a Device-to-Device (D2D) link / connection / interface, or simply SL. The radio interfaces 190, 195 may utilize any suitable radio 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.

[0064] The RAN 120 communicates with the core network 130 to provide various services, such as voice, data, and other services, to the EDs 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 which may or may not employ the same radio access technology. The core network 130 also serves as a gateway access between (i) the RAN 120 or the EDs 110, or both, and (ii) other networks, such as the PSTN 140, the Internet 150, and other networks 160. Additionally, some or all of the EDs 110 may include the capability to communicate with different wireless networks over different wireless links using different wireless technologies and / or protocols. Instead of (or in addition to) wireless communication, the EDs 110 may communicate with a service provider or switch (not shown) and the Internet 150 via wired communication channels. The PSTN 140 may include a circuit-switched telephone network for providing plain old telephone service (POTS). The Internet 150 may include a network of computers and / or subnets (intranets) and may incorporate protocols such as the Internet Protocol (IP), Transmission Control Protocol (TCP), and User Datagram Protocol (UDP). The ED 110 may be a multi-mode device capable of operating according to multiple radio access technologies, incorporating multiple transceivers necessary to support such technologies.

[0065] 2 and 3 illustrate examples of devices that can implement the methods and teachings according to the present disclosure. Figures 2 and 3 illustrate different possible embodiments for the ED 110 and BS 170 and are not intended to be limiting.

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

[0067] The device (e.g., the ED 110 or the BS 170) includes at least one communication interface 202 for wired and / or wireless communication. Each communication interface 202 includes any suitable structure for generating signals for wireless or wired transmission and / or processing wirelessly or wired received signals. The device in this example includes at least one antenna 204 (although in other examples, the antenna 204 may be omitted). Each antenna 204 includes any suitable structure for transmitting and receiving wireless 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 an antenna array 204 that can be used to perform beamforming and beamsteering operations. Although shown as a single functional unit, the device may also be implemented using at least one transmitter interface and at least one separate receiver interface.

[0068] An appliance (e.g., ED 110 or BS 170) further includes one or more input / output devices 206 or interfaces (e.g., a wired interface to the Internet 150). The input / output devices 206 enable interaction with a user or other devices in the network. Each input / output device 206 includes any structure suitable for providing information to or receiving information from a user, such as a speaker, microphone, keypad, keyboard, display, touchscreen, etc., including network interface communications.

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

[0070] As shown in FIG. 3 , another example device (e.g., another exemplary embodiment of the ED 110 or the 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 coding, data processing, power control, input / output processing, or any other function. The processing unit 250 may also be configured to implement some or all of the functions and / or embodiments described herein. Each processing unit 250 includes any suitable processing or computing device configured to perform one or more operations. Each processing unit 250 may include, for example, a microprocessor, a microcontroller, a digital signal processor, a field-programmable gate array, or an application-specific integrated circuit.

[0071] Each antenna 252 includes any suitable structure for generating wireless or wired transmissions. Each antenna 254 includes any suitable structure for processing wireless or wired received signals. Although shown as separate components, at least one transmitter 252 and at least one receiver 254 may be combined into a transceiver. Each antenna 256 includes any suitable structure for transmitting and receiving wireless or wired signals. While a common antenna 256 is shown here as being coupled to both the transmitter 252 and the receiver 254, one or more antennas 256 may be coupled to the transmitter 252 and one or more separate antennas 256 may be coupled to the receiver 254. In some examples, one or more antennas 256 may be an antenna array that can be used for beamforming and beamsteering operations. Each memory 258 includes any suitable volatile and / or non-volatile storage and retrieval device, such as those described above with respect to FIG. 2. The memory 258 stores instructions and data used, generated, or collected by the device. For example, memory 258 may store software instructions or modules configured to implement some or all of the functions and / or embodiments described herein and performed by processing unit 250.

[0072] Each input / output device / interface 266 allows for interaction with a user or other devices in the network, and includes any structure suitable for providing information to or receiving / providing information from a user.

[0073] Techniques for jointly encoding multiple code blocks (CBs) within a single transport block (TB), including generating vertical check blocks, are described in U.S. Patent Application No. 16 / 665,121, entitled "SYSTEM AND METHOD FOR HYBRID-ARQ," filed October 28, 2019, the entire contents of which are incorporated herein by reference.

[0074] FIG. 4A shows an example of a code structure for a single TB, including horizontal and vertical check blocks. The TB 402 includes multiple information blocks 404 formed from encoder input bits (four information blocks 404 are shown in this example for simplicity and are not intended to be limiting). The encoder input bits are sometimes referred to as information bits. The bits in this example are arranged in L rows and K columns. The code structure also includes horizontal check blocks 406 (one horizontal check block 406 per information block 404 in this example) and vertical check blocks 1-4 408-1 through 408-4 (commonly referred to as vertical check blocks 408). Four vertical check blocks 408 are shown in this example for simplicity and are not intended to be limiting. The number of vertical check blocks 408 used may be based on the configuration at the transmitter (e.g., BS 170 for downlink (DL) transmissions, ED 110 for uplink (UL) or SL transmissions) and / or may be defined by the standard. Furthermore, the number of vertical check blocks 408 may or may not be equal to the number of horizontal check blocks 406. Each row of the code contains n bits, including k encoder input bits (or information bits) (in one information block 404), and each horizontal check block 406 contains n-k check bits. In this disclosure, check bits may also be referred to as redundant bits, or in some instances (e.g., in the case of systematic codes), as parity bits.

[0075] Each information block 404 and corresponding horizontal check block 406 can be viewed as an n1-bit information CB 410, and TB 402 has multiple information CBs 410. In the example of Figure 4A, the information CBs 410 are systematic CBs in that they each contain systematic bits (in the information block 404) and check bits (in the horizontal check block 406) that are determined from the systematic bits. In other examples (discussed further below), the information CBs 410 may be non-systematic bits.

[0076] Each vertical check block 408 is generated from k2 encoder input bits (or information bits) selected across multiple information blocks 404 (also called cross information block bits, cross CB bits, or simply cross block bits). The k2 cross block bits include M encoder input bits from each of L information CBs 410, where M≧1, such that k2=M×L. That is, the k2 cross block bits include bits from one of K columns, each column being M bits wide. In some examples, the k2 cross block bits can include a different number of information bits taken from each information CB 410. Expressed mathematically, this is expressed as k2=M1+...+M L Here, M i is the number of information bits extracted from each of the L information CBs 410, and M i >0 and p≠q, then M p =M q There is no requirement for

[0077] This disclosure refers to "horizontal" (as in horizontal check block 406) and "vertical" (as in vertical check block 408). These terms are used for convenience in understanding the layout of some figures and to distinguish two types of check blocks from each other. However, these terms do not imply any physical structure. More generally, the descriptors "horizontal" and "vertical" may be equivalently replaced with "first" and "second," respectively. For example, horizontal and vertical check blocks 406, 408 may simply be referred to as first and second check blocks. In particular, each second (or vertical) check block is generated from information bits selected from two or more information CBs 410. Horizontal CBs may also be referred to as information CBs. For ease of understanding, this disclosure uses the terms "horizontal" and "vertical" instead of "first" and "second," but this is not intended to be limiting.

[0078] FIG. 4B shows another example of a code structure for a single TB, including horizontal and vertical check blocks. The example shown in FIG. 4B is similar to the example of FIG. 4A, and similar features to the example of FIG. 4A need not be further detailed. In the example of FIG. 4B, the code structure includes vertical check blocks 5-7 408-5 to 408-7 in addition to the previously described vertical check blocks 1-4 408-1 to 408-4 (vertical check blocks 1-7 408-1 to 408-7 are sometimes generically referred to as vertical check blocks 408). Vertical check blocks 5-7 408-5 to 408-7 are similar to vertical check blocks 1-4 408-1 to 408-4, except that vertical check blocks 5-7 408-5 to 408-7 are generated using bits selected from multiple horizontal check blocks 406 (rather than bits selected from multiple information blocks 404). As such, the bits of vertical check blocks 5-7 408-5 through 408-7 are sometimes referred to as "check-on-check" bits.

[0079] 4A and 4B are described above and show bits arranged in rows and columns; for example, vertical check block 408 is shown as having a rectangular / two-dimensional structure. However, this is for illustrative purposes only and is not intended to limit how bits may be arranged logically or in transmission. Additionally, the code structure shown in FIGS. 4A and 4B can be divided for transmission (as described further below). Typically, all bits of one vertical check block 408 are transmitted in the same transmission.

[0080] The check bits included in the horizontal check block 406 and the vertical check block 408 are useful for assisting decoding at a receiver. For example, after each decoding attempt at a decoder for which check bits are present, an error check can be performed to determine whether the information bits in the information CB 410 were successfully decoded. Because the vertical check block 408 contains check bits determined across multiple information CBs 410, it provides information useful for decoding multiple information CBs 410. A decoder can use the check bits in the vertical check block 408 to assist in decoding the information CBs 410.

[0081] In a transmission, the information CB 410 (transmitted including the corresponding horizontal check block 406) may be transmitted in the initial transmission. As described below, the vertical check block 408 may be transmitted along with the information CB 410 in the initial transmission, or may be transmitted in a separate transmission (sometimes called a retransmission). A retransmission may include only the non-systematic coded bits from the vertical check block 408, but a retransmission may also include some systematic bits (i.e., information bits) associated with the vertical check block 408.

[0082] In examples where the information CB 410 is systematic (e.g., low density parity check (LDPC) codes or turbo codes), an iterative decoding process may be used in the decoder (at the receiver) to decode the received CB. During decoding of the information CB, the decoder calculates the log-likelihood ratio (LLR) of the bit values, which are considered the decoder's "soft" outputs. In this disclosure, soft output may refer to a decoder output that is not yet determined (e.g., a bit value that has not yet been definitively determined to be a 1 or 0 value), but may still provide useful information (e.g., in subsequent decoding iterations). Such soft output may be probabilistic in nature (e.g., LLR). Incorrectly decoded information CB 410 (e.g., failing a check using the corresponding horizontal check block 406) may benefit from processing in the vertical check block 408. Because each vertical check block 408 is generated from information bits selected from two or more (or all) of the information CBs 410, soft outputs from attempts to decode the vertical check blocks 408 (e.g., LLRs) may help improve the decoding of the information CBs 410 (and vice versa). In at least this way, the vertical check blocks 408 help improve the decoding.

[0083] 5A and 5B. As mentioned above, the vertical check block 408 is determined from cross block bits selected from the entire information CB 410. For a given vertical check block 408, the cross block bits may include information bits taken from different columns of different information CBs 410. For example, the cross block bits may include input bits from column x of the first information CB 410, input bits from column y of the second information CB 410, and input bits from column z of the third information CB 410, where x, y, and z are different. Alternatively, the cross block bits for generating the vertical check block 408 may be selected by arbitrarily shuffling the bits in an information row (also called row-wise shuffling) and then taking the vertical columns of bits. This row-wise shuffling of information bits is also called interleaving or row-wise interleaving. A predetermined shuffling scheme or a predetermined interleaver may be used to perform this shuffling. This disclosure describes the use of an interleaver for such row-wise permutation of information bits to generate different vertical check blocks 408. An interleaver is a predetermined algorithm or a predetermined matrix that is applied to rows of bits to obtain permuted rows of bits (among other possibilities). It should be understood that other techniques (not necessarily limited to interleaving) may also be used.

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

[0085] In contrast, consider the example of FIG. 5B. In this example, the information bits have been shuffled in at least one row (represented in FIG. 5B as shuffled indices of the subblocks). Notice that the order of the subblocks remains unchanged in the first row, but the order has changed in the second, third, and fourth rows. In particular, the specific subblocks belonging to each information CB 410 remain unchanged; only the order of the subblocks within each information CB 410 changes. This means that the shuffling does not affect the horizontal check blocks 406 of each information CB 410. However, the vertical check blocks 408 in FIG. 5B are different from the vertical check blocks 408 in FIG. 5A. The vertical check blocks 408 in FIG. 5A can be considered a first set of vertical check blocks 408, and the vertical check blocks 408 in FIG. 5B can be considered a second set of vertical check blocks 408.

[0086] Whether shuffling is used and how the encoder input bits are shuffled within each row can be configured by the transmitter (e.g., BS 170 or ED 110) and / or defined by the standard. It will be appreciated that using different interleavers to shuffle the information bits will result in different sets of vertical check blocks 408 (e.g., different first and second sets of vertical check blocks 408 in FIGS. 5A and 5B above). In some instances, different sets of vertical check blocks 408 may be generated from the same TB 402, which may be useful for providing additional information for decoding purposes. For example, different sets of vertical check blocks 408 may be generated for different retransmission attempts.

[0087] 4A, 4B, 5A, and 5B illustrate code structures based on systematic codes, but this is for illustrative purposes only. The present disclosure is not limited to systematic codes and may be applied to and implemented with non-systematic codes as well. Furthermore, while the present disclosure describes examples of using vertical check block 408 in the context of multicast, groupcast, and broadcast transmissions / retransmissions, it should be understood that the code structures illustrated in FIGS. 4A, 4B, 5A, and 5B may also be suitable for unicast transmissions / retransmissions, among others.

[0088] Figure 6 shows an example of a single-TB code structure based on a non-systematic code (e.g., a polar code, a block code, or a conventional code). Each non-systematic codeword is determined based on a set of encoder input bits, but information bits do not appear in the codeword as systematic bits. Unlike systematic codes, horizontal check bits cannot be simply added to the end of each row.

[0089] The TB 602 includes multiple non-systematic codewords 604. Each non-systematic codeword 604 can be viewed as an information CB 610. Unlike the examples of Figures 4A, 4B, 5A, and 5B, the information CB 610 does not include an explicit horizontal check block. Each vertical check block 608 is generated by one or more bit strings taken across multiple information CBs 610, similar to those described in Figures 4A and 4B.

[0090] Those skilled in the art will understand that the detailed discussion below does not depend on whether the vertical check blocks are generated from systematic or non-systematic CBs. For simplicity, the following will refer to and use reference numerals with reference to the example of Figures 4A and 4B based on systematic CBs. It should be understood that this is not intended to be limiting.

[0091] In this disclosure, vertical check blocks are sometimes referred to as cross-block check blocks because the bits for generating each vertical check block are taken across multiple information blocks. Similarly, the generation of horizontal check blocks is sometimes referred to as block-wise (or block-specific) coding because the bits for generating each horizontal check block are taken from all the bits of a single information block. The generation of vertical check blocks is sometimes referred to as two-dimensional (2D) coding, where 2D refers to the generation of vertical check blocks (in addition to horizontal check blocks in the case of systematic codes). The terms "parity blocks" or "redundancy blocks" are sometimes used instead of "check blocks." For ease of understanding, the following description refers to vertical and horizontal check blocks, but it should be understood that the terms "vertical" and "horizontal" do not imply or limit any physical structure.

[0092] The previous description describes vertical check blocks generated from the cross block bits of a single TB. Vertical check blocks may also be generated from the cross block bits of two or more TBs (e.g., TBs transmitted as separate packets from a single source). To aid in understanding this further application, a discussion of network coding is provided.

[0093] Network coding is a network technique that encodes and decodes transmitted data to help improve network throughput, reduce latency, and / or improve the robustness of wireless networks. Instead of treating two packets as different, separate units of information (as in traditional network routing), network coding combines the two packets (using a specific, defined algebraic algorithm, such as a bitwise X-OR operation) and delivers the resulting message to a destination, where the resulting message is decoded (using the same defined algorithm). Two packets combined in this manner may be from two different transmitting nodes, or from two different sources, either the same or different (e.g., two different antennas, two different transmitters, or two different communication interfaces). The two packets may be intended for the same destination or two different destinations (e.g., two different receiving nodes). If the two packets are intended for two different destinations, additional information may be used at each destination to decode and retrieve only the packet intended for that destination.

[0094] When vertical check blocks are used in network coding, a given vertical check block is generated from bits taken from two or more CBs or two or more packets (which may come from a single TB or multiple TBs).

[0095] FIG. 7 shows an example of a code structure similar to FIGS. 4A and 4B. However, unlike FIGS. 4A and 4B, the structure of FIG. 7 includes multiple TBs, in this example TB-1 402-1 and TB-2 402-2 (commonly referred to as TB 402). Note that TB 402 is not necessarily transmitted in the same transmission. In this example, two TBs 402 are shown for simplicity and are not intended to be limiting. TB-1 402-1 arranges the encoder input bits in rows that form information block 404-1 (two information blocks 404-1 are shown in this example for simplicity and are not intended to be limiting), and TB-2 402-2 arranges the encoder input bits in rows that form information block 404-2 (two information blocks 404-2 are shown in this example for simplicity and are not intended to be limiting). Information blocks 404-1, 404-2 may be generally referred to as information blocks 404. Note that the number of information blocks 404 in each TB 402 is not necessarily equal. 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 distinct from the information blocks 404.

[0096] Vertical check blocks 1-4 408-1 through 408-4 (commonly referred to as vertical check blocks 408) are each generated using one or more bit strings taken across all information blocks 404 (and therefore across all TBs 402). That is, each vertical check block 408 is generated from a set of bits that includes at least one bit from each information block 404 in 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 used may be based on the configuration at the transmitter (e.g., BS170 for DL ​​transmission, ED110 for UL or SL transmission) and / or may be defined by the standard. Furthermore, the number of vertical check blocks 408 may or may not be equal to the number of horizontal check blocks 406.

[0097] 5A, 5B, and 6, the vertical check blocks 408 generated across multiple TBs 402 may be generated based on the information bits in their natural order, or based on shuffled (or interleaved) bits. Multiple sets of vertical check blocks 408 may be generated for the same set of TBs 402 using different interleavers (e.g., for different retransmissions). Vertical check blocks 408 may be generated for systematic or non-systematic codes.

[0098] The information CB410 may originate from a source that may be a network node (e.g., BS170 or ED110) or a transmitting device of a network node (e.g., a transmitting antenna or a transmitting chain). In general, the term network node in this disclosure 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 ED110) as well as a node that is uplink (e.g., BS170 or a relay). Those skilled in the art will understand that other variations are possible within the scope of this disclosure.

[0099] Each TB may have a respective number of information CBs. In this disclosure, the information CBs may be simply referred to as CBs. In some examples, a vertical check block may be generated using bits selected from all CBs of a TB (e.g., using an interleaver). In other examples, a vertical check block may be generated using bits selected from fewer than all but at least two CBs of a TB. For example, a given interleaver may indicate the selection of bits from fewer than all CBs (e.g., the selection of bits only from CBs that were not successfully decoded by the receiving node) to generate a vertical check block.

[0100] This disclosure describes methods and devices for performing multicast, broadcast, or groupcast transmissions using 2D coding. In particular, one or more vertical check blocks of multiple CBs are retransmitted instead of retransmitting each CB individually. Compared to existing retransmission schemes, the disclosed examples provide improved performance, such as reduced delay, reduced overhead, or more efficient decoding.

[0101] In this disclosure, the initial transmission of a TB or packet, referred to as an initial transmission, includes communication of information CB (including horizontal check blocks in the case of a systematic code) from the transmitting node to the receiving node. Subsequent communications relating to the same TB or packet, referred to as retransmissions of the TB or packet, include transmission of one or more vertical check blocks from the transmitting node to the receiving node. It should be noted that in some examples described herein, the initial transmission may include one or more vertical check blocks.

[0102] Because vertical check blocks are generated using bits from multiple CBs, retransmission of a single vertical check block can provide information useful for decoding multiple CBs. At the receiving node, soft information from failed decoding attempts can be retained and combined with information from the vertical check block to aid in decoding multiple CBs. The ability to utilize soft information from unsuccessful decoding attempts provides a significant performance improvement over non-erasure codes and fountain codes. This 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.

[0103] This disclosure describes examples that may help reduce redundancy and feedback required for retransmissions in broadcast or multicast compared to traditional TB or CB group-based HARQ. The examples disclosed herein can be implemented with feedback-based schemes as well as rateless codes.

[0104] An example of the use of vertical check blocks in a broadcast, multicast, or groupcast transmission application is described. The following example is described and shown with a particular number of participating entities (e.g., source, transmitter, destination, relay, terminal device, UE, etc.). The particular numbers shown are not intended to be limiting. For example, there may be any number of entities (e.g., two or more) indicated in the plural. Although not described in detail, different interleavers can be used to generate different vertical check blocks for HARQ retransmissions.

[0105] In the examples disclosed herein, retransmissions performed by a transmitter (or transmitting node) (Tx) may be according to predetermined parameters. The parameters for performing retransmissions include the number of retransmissions to be performed (which may be determined in advance), the interleaver used to generate each vertical check block, the number of vertical check blocks to include in each retransmission, etc. The retransmission parameters may be predefined (e.g., defined in a standard) or semi-statically configured (e.g., configured by higher layer signaling such as radio resource control (RRC) signaling). In an example where the Tx is the ED 110, the retransmission parameters may be semi-statically (e.g., configured grants) or dynamically (e.g., dynamic scheduling) indicated by configuration signaling from the BS 170. The semi-static configuration may be signaled using higher layer signaling such as radio resource control (RRC) signaling. The dynamic indication may be signaled using physical layer (or Layer 1) signaling such as downlink control information (DCI) transmission.

[0106] In order for the receiving node to properly utilize the vertical (and horizontal) check blocks for decoding, the receiver (or receiving node) (Rx) also needs information about how the vertical check blocks were generated. Information about the parameters used to generate the vertical check blocks (also called vertical check block parameters) may be signaled to each Rx before, during, together with, or immediately after a retransmission. If the Tx is the BS 170, information about the parameters used to generate the vertical check blocks may be signaled, for example, in DCI or RRC as described above. If the Tx is an ED 110, information about the vertical check block parameters may be signaled to other receiving EDs 110 using sidelink RRC or PC5-RRC (for semi-statically configured parameters) or using sidelink control information (SCI) over the sidelink control channel (for dynamically indicated parameters). If the Tx is an ED 110 and transmissions from the Tx to the Rx (which may be another ED 110) are scheduled by the network (or BS 170), information about the vertical check block parameters may also be signaled to the Tx from the 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 that information does not need to be communicated / scheduled to the Tx ED by the network / BS 170.

[0107] Possible signaled information includes: a New Data Indicator (NDI) indicating whether the transmission is a new (initial) transmission or a retransmission; an HARQ process ID identifying a set of transmissions / retransmissions belonging to the same HARQ process; the predetermined number of iterations / blind retransmissions (if applicable); and parameters for generating vertical check blocks. Examples of vertical check block parameters that may be signaled include: the number of vertical check blocks transmitted per retransmission; the CB index and the number of CBs used to generate the vertical check blocks (optional if all CBs are used to generate the vertical check blocks); the interleaver used to generate the vertical check blocks; and which bits / sub-blocks of each CB are used to generate the vertical check blocks. In some examples, the parameters for generating the vertical check blocks for a given retransmission may be predefined according to the redundancy version (RV) of the retransmission, in which case the signaling may indicate the RV of the retransmission. The RV index or the RV sequence corresponding to multiple transmissions / retransmissions of the TB may also be signaled. Information about the interleaver used to generate the vertical check block may be transmitted in the form of seeds (or indices) of one or more interleavers within a pre-configured and known (e.g., standard-defined) set of available interleavers.

[0108] Any of the above information may be pre-configured in the standard and / or pre-configured in the network system / device, and therefore known to both the transmitting and receiving nodes. In some instances, different option or parameter values ​​may be defined by the standard, and signaling (e.g., RRC, PC5-RRC, DCI, SCI) may be used to indicate the particular option or parameter value to be used (e.g., by referencing an index value). Different types of signaling (e.g., RRC, PC5-RRC, DCI, SCI) may be used to indicate short-term changes (e.g., selection of a particular interleaver to use) or long-term changes (e.g., change in the number of predetermined retransmissions).

[0109] The disclosure may, in some instances, refer to TBs or packets, and it should be understood that discussions in the context of TBs may be equally applicable to packets (and vice versa).

[0110] FIG. 8A is a signaling diagram illustrating an example of using vertical check blocks in a feedback-based retransmission scheme. Note that while FIG. 8A (and other examples disclosed herein) are described in the context of transmissions to multiple receiving nodes (e.g., multicast, broadcast, or groupcast transmissions), the signaling (including configuration or control signaling) described herein may also be applicable to unicast transmissions (i.e., transmissions to a single receiving node). In FIG. 8A, a transmitting node 12 (denoted Tx 12) is transmitting to multiple receiving nodes (denoted Rx-1 14-1, Rx-2 14-2, and Rx-3 14-3, commonly referred to as Rx 14). The transmission from Tx 12 may be a multicast, broadcast, or groupcast transmission. Tx 12 may be a BS 170 (e.g., in the case of a broadcast or multicast DL transmission to ED 110) or an ED 110 (e.g., in the case of a groupcast SL transmission to other EDs 110). In some examples, when Tx 12 is an ED 110, one of Rx 14 may be a BS 170 (e.g., UL transmission), and the other of Rx 14 may be another ED 110. Although not shown in the figure, Tx 12 may send configuration or control signals to Rx 14 (e.g., before the initial transmission, before a retransmission, during a retransmission, together with a retransmission, or immediately after a retransmission) to provide information about the parameters used to generate the vertical check block. Such information may be necessary for Rx 14 to utilize the vertical check block to aid in decoding. For example, Tx 12 may send control information including the parameters of the vertical check block in sidelink control information (SCI). The SCI may be transmitted on a physical sidelink control channel (PSCCH) associated with a data transmission on the physical sidelink shared channel (PSSCH) or may be transmitted on the PSSCH along with the data transmission.The Rx 14 may first decode the SCI to obtain control information including vertical check block parameters and use the obtained control information to further decode the data. Information included in the configuration or control signal may include, for example, an NDI indicating whether the transmission is a new (initial) transmission or a retransmission, an HARQ process ID identifying a set of transmissions / retransmissions belonging to the same HARQ process, a predetermined number of iterations / blind retransmissions (if applicable), and parameters for generating vertical check blocks. Examples of vertical check block parameters that may be signaled include: the number of vertical check blocks transmitted per retransmission, the index of the CB and the number of CBs used to generate the vertical check blocks (optional if all CBs are used to generate the vertical check blocks), the interleaver used to generate the vertical check blocks, and which bits / sub-blocks of each CB are used to generate the vertical check blocks. In some examples, the parameters for generating the vertical check blocks for a given retransmission may be predefined according to the RV of the retransmission, in which case the signaling may indicate the RV of the retransmission. RV indices or RV sequences corresponding to multiple transmissions / retransmissions of a TB may also be signaled. Information about the interleaver used to generate the vertical check block may be transmitted in the form of seeds (or indices) of one or more interleavers within a pre-defined and known (e.g., standard-defined) set of available interleavers.

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

[0112] Each Rx 14 returns an ACK / NACK feedback depending on whether the TB or packet was successfully decoded. In this example, Rx-1 14-1 successfully decodes the packet or TB and returns an ACK at 804. Rx-2 14-2 and Rx-3 14-3 fail to decode the packet or TB and return NACKs at 806 and 808, respectively. In particular, Rx-2 14-2 and Rx-3 14-3 may fail to decode different CBs in the packet or TB. For example, as shown in FIG. 8D, if the packet or TB transmitted by Tx 12 at 802 includes CBs 1-9, Rx-2 14-2 may fail to decode CBs 2 and 8 (indicated by CBs 2 and 8 marked with an "X"), while Rx-3 14-3 may fail to decode CBs 1, 2, and 6 (indicated by CBs 1, 2, and 6 marked with an "X").

[0113] Returning to FIG. 8A, if at least one of the Rxes 14 indicates that the TB or packet was not successfully decoded (e.g., one of the feedbacks indicates a NACK), Tx 12 retransmits one or more vertical code blocks at 810. The vertical code blocks (at 802) are generated from the TB or packet transmitted in the initial transmission and may be generated according to predetermined parameters (e.g., an interleaver). In some examples, Tx 12 may adjust the retransmissions at 810 to exclude the Rx 14 that feedbacks an ACK (in this example, Rx-1 14-1), such as in the case of a multicast or groupcast retransmission. In other examples, Tx 12 may send the retransmission at 810 to all Rxes 14. For example, as shown in FIG. 8D, the first vertical check block (VCB1) is retransmitted at 810 to all Rxes 14 (although, as noted above, multiple vertical check blocks may be retransmitted at 810). In particular, the same vertical code block is transmitted at 810 to Rx-2 14-2 and Rx-3 14-3 even though Rx-2 14-2 and Rx-3 14-3 have different undecoded CBs.

[0114] Each Rx that failed to decode the initial transmission (in this example, Rx-2 14-2 and Rx-3 14-3) will retry decoding the undecoded CB using the vertical check block received with the initially received TB and soft information from the previous decoding attempt, combining them. An Rx that has already successfully decoded the TB (in this example, Rx-1 14-1) may ignore the retransmission.

[0115] In this example, the vertical check block allows both Rx-2 14-2 and Rx-3 14-3 to successfully decode the TB. In particular, Rx-2 14-2 and Rx-3 14-3 can use the same vertical check block even if they each fail to decode different CBs. The same vertical check block can help decode erroneous CBs, even if they are different erroneous CBs in different Rxs 14. Furthermore, a single vertical check block can be transmitted. Because soft information from previous decoding attempts of multiple erroneous CBs is retained and can be used in subsequent decoding attempts, one single vertical check block may help successfully decode multiple erroneous CBs. Note that the number of 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 multiple.

[0116] Returning to Figure 8A, Rx-2 14-2 and Rx-3 14-3 return ACKs at 814 and 816, respectively. Optionally, Rx-1 14-1 may return an ACK again at 812 to confirm successful decoding. After Tx 12 receives ACK feedback from all Rx 14, the retransmission may end.

[0117] The example of FIG. 8A illustrates some advantages of the retransmission scheme of the present disclosure compared to existing retransmission schemes.

[0118] For example, when using HARQ based on conventional TBs, the entire TB must be retransmitted in a retransmission, which means that there may be significant redundancy. For example, if only one CB fails to decode, only one CB in the retransmission provides useful information, while the other CBs are redundant, wasting transmission resources (e.g., time-frequency resources).

[0119] Another existing retransmission scheme is called code block group (CBG)-based HARQ. CBG-based HARQ retransmission is similar to TB-based HARQ, except that instead of retransmitting the entire TB, it divides the TB into multiple groups of CBs (called CBGs) and retransmits only the CBGs containing undecoded CBs. However, this method incurs significant feedback overhead because each receiving node must notify the transmitting node of which CBs it needs to retransmit in order for the transmitting node to identify which CBGs to retransmit. Furthermore, if there are undecoded CBs belonging to different CBGs, multiple CBGs must be retransmitted, which also increases redundancy. In addition, in the case of broadcast / multicast / groupcast, there are multiple receiving nodes, so different receiving nodes may experience errors in different CBGs. In this case, all CBGs that showed errors from any receiving node must be retransmitted. For example, in the example shown in FIG. 8D, if CBG-based HARQ is used, CB1, CB2, and CB3 may be grouped into one CBG (e.g., CBG1), CB4, CB5, and CB6 may be grouped into another CBG (e.g., CBG2), and CB7, CB8, and CB9 may be grouped into a third CBG (e.g., CBG3). Then, after the first feedback, Tx 12 needs to retransmit CBG1 and CBG3 to Rx-2 14-2 (because Rx-2 14-2 failed to decode CB2, which belongs to CBG1, and failed to decode CB8, which belongs to CBG3), and CB1 and CB2 to Rx-3 14-3 (because Rx-3 14-3 failed to decode CB1 and CB2, which belong to CBG1, and failed to decode CB6, which belongs to CBG2). This means that Tx12 will have to retransmit all three CBGs, which means the full TB will have to be retransmitted even with the increased feedback overhead. In such instances, which may not be unlikely for broadcast / multicast / groupcast transmissions, CBG-based HARQ cannot provide any efficiency.

[0120] Another existing retransmission scheme is erasure outer codes. However, as previously explained, this approach does not utilize soft information from previous decoding attempts to assist the current decoding attempt, and therefore performance is not as good as the example disclosed herein. Furthermore, erasure outer codes are designed for transmission over erasure channels, and performance over non-erasure channels is impaired. Furthermore, if the receiving node loses or fails to successfully decode K CBs in the initial transmission (where K is a positive integer), the Tx must transmit at least K parity code blocks generated using the erasure outer code in the receiving node's retransmission to recover the K lost CBs. This can be avoided if vertical check blocks are used in the retransmission instead, as disclosed herein. In the example of FIG. 8D, Rx-3 14-3 failed to decode three CBs (CB1, CB2, and CB6) in the initial transmission. Therefore, when using erasure outer codes, at least three parity CBs must be retransmitted to recover the three information CBs. However, using vertical check block based retransmission as described herein, only one vertical check block can be retransmitted and Rx-3 14-3 can recover all CBs after one retransmission.

[0121] FIG. 8A is a signaling diagram illustrating another example of using vertical check blocks in an ACK / NACK-less retransmission scheme. In ACK / NACK-less retransmission, feedback from the receiving node is optional or omitted. The ACK / NACK-less retransmission scheme may be used for rateless codes. Broadcast transmissions may benefit from an ACK / NACK-less retransmission scheme because a transmitting node may broadcast to a large number of unknown receiving nodes. FIG. 8B is similar to FIG. 8A and includes 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, commonly referred to as Rx 14). The transmission from Tx 12 may be a multicast, broadcast, or groupcast transmission. Tx 12 may be a BS 170 (e.g., for a broadcast or multicast DL transmission to ED 110) or an ED 110 (e.g., for a groupcast SL transmission to other EDs 110). In some examples, when Tx 12 is an ED 110, one of Rx 14 may be a BS 170 (e.g., UL transmission) and another of Rx 14 may be another ED 110. Although not shown in the figure, Tx 12 may send configuration or control signals to Rx 14 (e.g., before the initial transmission, before a retransmission, during a retransmission, along with a retransmission, or immediately after a retransmission) to provide information about the parameters used to generate the vertical check block. Such information may be necessary for Rx 14 to utilize the vertical check block to aid in decoding.

[0122] At 852, the Tx 12 transmits a packet or TB containing multiple encoded CBs to all intended Rx 14. The transmission at 852 may be a broadcast, multicast, or groupcast transmission. Each Rx 14 attempts to decode the received packet or TB.

[0123] Similar to rateless codes, there may be no PHY layer ACK / NACK feedback from Rx 14 after each transmission. An optional upper layer ACK can be sent from Rx 14 if the TB is successfully decoded. In this example, Rx-1 14-1 successfully decodes the TB and optionally sends back an ACK at 854. Rx-2 14-2 and Rx-3 14-3 fail to decode the TB and do not send feedback. In particular, Rx-2 14-2 and Rx-3 14-3 may fail to decode different CBs in the TB. For example, as shown in FIG. 8E, if the TB transmitted by Tx 12 at 852 includes CBs 1-9, Rx-2 14-2 may fail to decode CBs 2 and 8 (indicated by CBs 2 and 8 crossed out), while Rx-3 14-3 may fail to decode CBs 1, 2, and 6 (indicated by CBs 1, 2, and 6 crossed out).

[0124] Tx 12 can be configured to send a predetermined number of retransmissions. Tx 12 can be further configured to use predetermined parameters to generate the vertical code block for each retransmission. Tx 12 can send a predetermined number of retransmissions until it receives an optional upper layer ACK from each Rx 14. Alternatively, Tx 12 may send a predetermined number of retransmissions regardless of feedback (or whether feedback is present). Tx 12 may send retransmissions only to Rx 14s that did not send an upper layer ACK (e.g., for multicast or groupcast retransmissions). Sending a predetermined number of retransmissions that are not triggered by feedback (or receiving no feedback between transmissions / retransmissions) may be referred to as repetition or blind retransmission.

[0125] As shown in both Figures 8B and 8E, in this example, Tx 12 receives an upper layer ACK from Rx-1 14-1 but does not receive feedback from Rx-2 14-2 and Rx-3 14-3. At 856, Tx 12 retransmits one or more vertical code blocks (denoted as VCB1 in Figure 8E) only to Rx-2 14-2 and Rx-3 14-3. The vertical code blocks (at 852) may be generated from the TBs or packets transmitted in the initial transmission and may be generated according to predetermined parameters (e.g., an interleaver). The retransmission at 856 sends the same vertical check blocks to Rx-2 14-2 and Rx-3 14-3.

[0126] Each Rx (in this example, Rx-2 14-2 and Rx-3 14-3) that failed to decode the initial transmission retries to decode the undecoded CB using the vertical check block received with the initially received TB and soft information from the previous decoding attempt. In this example, Rx-2 14-2 successfully decodes the TB using the vertical check block and soft information from the previous decoding attempt and optionally sends back an ACK at 858. Rx-3 14-3 still has not successfully decoded the TB and does not send any feedback.

[0127] Tx 12 continues to send a predetermined number of retransmissions at 860 and 862. A different set of vertical check blocks is sent in each retransmission 860, 862 (shown as VCB2 and VCB3, respectively, in FIG. 8E). For example, each set of vertical check blocks may be generated using different parameters (e.g., a different interleaver). In some examples, the retransmissions end after a predetermined number of retransmissions (in this example, three retransmissions) are completed, even though an ACK has not been received from Rx-3 14-3. In other examples, the number of retransmissions is not predetermined, and Tx 12 continues to send additional vertical check blocks until Tx 12 receives ACKs from all Rx 14. For example, when optional ACKs are sent in FIGS. 8B and 8E, Tx 12 may continue to send one (or more) vertical check blocks at a time. After the third retransmission (e.g., after sending the third vertical check block VCB3), Tx 12 receives an ACK from Rx-3 14-3. Combined with the ACKs that Tx 12 received earlier (at 854 and 858) from Rx-1 14-1 and Rx-2 14-2, Tx 12 determines that ACKs have been received from all intended Rxs 14, and Tx 12 stops sending any more Vertical Check Blocks. In some examples, Tx 12 may be scheduled to send a predetermined maximum number of retransmissions or Vertical Check Blocks, and will stop sending any more Vertical Check Blocks once the maximum number of retransmissions or Vertical Check Blocks has been reached, or once ACKs have been received from all intended Rxs 14.

[0128] FIG. 8C is a flowchart illustrating an example method 870 that may be performed by a transmitting node in accordance with the example signaling of FIGS. 8A and 8B.

[0129] At 874, Tx 12 sends an initial transmission to multiple intended Rxs 14 (e.g., in signal 802 of FIGS. 8A and 8B). The initial transmission may be a broadcast, groupcast, or multicast transmission. The initial transmission includes multiple pieces of information CB.

[0130] Optionally, feedback may be received at 876 from one or more Rx 14. For example, in a feedback-based retransmission scheme, each Rx 14 may be required to send ACK / NACK feedback back to Tx 12 (e.g., in signals 804, 806, 808 of FIG. 8A). In an ACK / NACK-less retransmission scheme, ACK feedback (e.g., in signal 854 of FIG. 8B) is optional, and there may be no NACK feedback.

[0131] Optionally, at 878, Tx 12 determines whether reception by at least one Rx 14 failed. A reception failure by an Rx 14 means that the Rx 14 failed to successfully decode at least one piece of information CB. In the case of a feedback-based retransmission scheme, Tx 12 can determine that at least one Rx 14 failed to successfully decode the CB if at least one NACK is received in step 876. In the case of an ACK / NACK-less retransmission scheme, Tx 12 can determine that at least one Rx 14 failed to successfully decode the CB if Tx 12 does not receive ACKs from all intended Rx 14s. In response to the feedback received in step 876, Tx 12 can also identify which Rx 14 experienced the reception failure.

[0132] In some instances, such as in a broadcast scenario, Tx 12 may not receive feedback from any of Rx 14, and instead perform a predetermined number of retransmissions (also known as a blind retransmission scheme). In such cases, steps 876 and 878 may be omitted.

[0133] At 880, Tx 12 generates one or more vertical check blocks. The vertical check blocks are generated using selected bits from at least two of the CBs transmitted in the initial transmission of step 874. It should be noted that the vertical check blocks may be generated at any time during method 870 prior to transmission of the vertical check blocks. For example, the vertical check blocks may be generated prior to the initial transmission or following optional steps 876 and 878.

[0134] Optionally, at 881, a configuration or control signal (e.g., an RRC signal, a PC5-RRC signal, a DCI transmission, or an SCI transmission) can be transmitted by Tx 12 to provide Rx 14 with information regarding parameters for generating vertical check blocks. The information regarding how vertical check blocks are generated allows each Rx 14 to use the vertical check blocks (transmitted in retransmissions) to help decode information CBs in the initial transmission. This signal can be used to indicate parameters for generating vertical check blocks, such as NDI, HARQ process ID, iteration count, number of transmitted vertical check blocks, and code block partition, interleaver selection, RV or RV sequence selection, coding rate, index of CBs used to generate vertical check blocks, and / or other information related to generating vertical check blocks, as described above. The configuration or control signal can be received before or at the start of method 870, or at any time during method 870, including during, with, or after transmission of vertical check blocks to Rx 14. For example, step 881 can occur during step 882.

[0135] In some instances, no configuration or control signals need to be sent, and step 881 may be omitted. For example, the parameters for generating vertical check blocks may be predetermined (e.g., defined in a standard) and do not need to be communicated from Tx 12 to each Rx 14.

[0136] At 882, at least one vertical check block is transmitted to at least one Rx 14. The vertical check block may be transmitted to multiple Rxs 14 (e.g., broadcast, multicast, or groupcast, similar to the initial transmission). In some examples, the vertical check block may be transmitted to all Rxs 14 (e.g., signal 810 of FIG. 8A) via broadcast, multicast, or groupcast, regardless of whether a given Rx 14 successfully or unsuccessfully decoded the initial transmission. In other examples, the vertical check block may be transmitted (e.g., signal 856 of FIG. 8B) via multicast or groupcast only to Rxs 14 that were determined (in optional step 878) to have unsuccessfully decoded the initial transmission.

[0137] An optional further step of receiving feedback and sending subsequent retransmissions can be performed as needed (eg, up to a predetermined number of retransmissions).

[0138] The examples disclosed herein may also be applicable to multicast or groupcast transmissions in V2X communications. It should be noted that while this description is provided in the context of V2X communications, the examples may also be applicable to other applications. The NR-V2X standard defines specific resource allocation modes and options for V2X groupcast. Two modes are defined for resource allocation for the transmitting node (which in V2X is a vehicle). In Mode 1, the BS 170 schedules resources for the transmitting node to use for the initial transmission and subsequent retransmissions. The transmitting node can report (e.g., with an acknowledgement (ACK) or negative acknowledgement (NACK)) to the BS 170 to schedule additional resources for retransmissions. In Mode 2, the transmitting node selects resources to use for transmission and subsequent retransmissions from a preconfigured resource pool.

[0139] 9A is a flowchart illustrating an example of a method 900 that a transmitting node may perform for multicast or groupcast communication using Mode 1 defined in NR-V2X. The transmitting node may be a network-enabled vehicle, or may be more generally denoted as Tx. The multicast or groupcast communication is to multiple receiving nodes (generally denoted as Rx), which may include other EDs 110 (e.g., other vehicles, UEs, IoT devices, surrounding sensors, etc.) and / or the BS 170.

[0140] Optionally, at 902, the Tx requests resource allocation (e.g., time-frequency resources) from the BS 170 (e.g., gNB). The request resource allocation step can be accomplished, for example, by sending a scheduling request (SR) to the BS. At 904, scheduled resources are allocated at the BS 170 and signaled to the Tx. Optionally (at 906 below), if the scheduled transmission performed by the Tx includes a retransmission, the schedule signaling can also provide the Tx (e.g., in a configuration signal or control signal, such as an RRC signal or a DCI transmission) with information regarding parameters for generating vertical check blocks. This signal can be used to indicate parameters for generating vertical check blocks, such as the NDI, HARQ process ID, number of repetitions, number of transmitted vertical check blocks, and code block partition, interleaver selection, RV or RV sequence selection, coding rate, index of the CB used to generate the vertical check blocks, and / or other information related to generating the vertical check blocks, as described above.

[0141] Optionally, at 905, if the scheduled transmission includes the transmission of a vertical check block, the Tx may provide information to the Rx (e.g., in a configuration or control signal, such as a PC5-RRC signal or an SCI transmission) regarding the parameters for generating the vertical check block. The information regarding how the vertical check block is generated allows each Rx 14 to use the vertical check block to help decode the information CB. The configuration indicated to the Rx may be a configuration previously indicated to the Tx by the BS 170. The configuration or control signal may be transmitted during, together with, or after the transmission of the vertical check block to the Rx. For example, step 905 may occur during step 906.

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

[0143] At 908, Tx determines whether any Rx's received the transmission unsuccessfully.

[0144] For example, the Tx can determine whether any Rx failed to receive the transmission based on ACK / NACK feedback from the Rx. In some examples, the Rxs may not all be fully known to the Tx, and each Rx can send a NACK only if it failed to receive the transmission. At 910, if the Tx receives a NACK from any Rx, the Tx reports NACK feedback to the BS 170. Otherwise, if the Tx does not receive NACK feedback, the Tx reports an ACK.

[0145] In another example, all Rxs may be known to the Txs. For example, each Rx may have a dedicated PSFCH resource, and each Rx may transmit ACK / NACK feedback via its dedicated PSFCH resource. In this case, at 910, the Tx reports an ACK to the BS 170 if it receives ACK feedback from all Rxs, and reports a NACK to the BS 170 if it receives at least one NACK from an Rx.

[0146] If Tx has performed a predetermined number of retransmissions (in addition to the initial transmission) at 906, then Tx determines at 908 whether there is still at least one Rx that has failed reception (e.g., still receives at least one NACK feedback) after the predetermined number of retransmissions, and reports feedback to BS170 accordingly at 910.

[0147] If reception is successful at all Rx's (eg, no NACK is received from any Rx's or ACK's are received from all Rx's), then at 910, the Tx reports an ACK to the BS 170 and the method 900 ends.

[0148] If the Tx reports a NACK to the BS 170 at 910, the NACK report may be interpreted by the BS 170 as a request for further resource allocation. After the BS 170 receives the NACK report from the Tx, the BS 170 schedules and signals further resource allocation at 912 to allow the Tx to perform a predetermined number of retransmissions. The Tx is scheduled to perform one or more retransmissions, each of which may independently be the transmission of one or more vertical check blocks. Optionally, the schedule signaling may also provide the Tx with information regarding parameters for generating the vertical check blocks (e.g., in a configuration signal or control signal, such as an RRC signal or DCI transmission). This signaling may be used to indicate parameters for generating the vertical check blocks, such as the NDI, HARQ process ID, number of iterations, number of transmitted vertical check blocks, and code block partition, interleaver selection, RV or RV sequence selection, coding rate, index of the CB used to generate the vertical check blocks, and / or other information related to the generation of the vertical check blocks, as described above.

[0149] Optionally, at 913, the Tx can provide the Rx (e.g., in a configuration or control signal, such as a PC5-RRC signal or an SCI transmission) with information regarding the parameters for generating the vertical check block. The information regarding how the vertical check block is generated allows each Rx 14 to use the vertical check block to help decode the information CB. The configuration indicated to the Rx can be the configuration optionally indicated to the Tx by the BS 170 at 912. The configuration or control signal can be sent during, together with, or after the transmission of the vertical check block to the Rx. For example, step 913 can occur during step 914.

[0150] At 914, Tx performs one or more retransmissions (up to a predetermined number of retransmissions allowed by the allocated resources), which can be sent to all Rxs (e.g., if all Rxs are completely unknown to Tx), or only to Rxs that failed to receive (e.g., if all Rxs are known to Tx).

[0151] 9B is a flowchart illustrating an example of a method 950 that a transmitting node may perform for multicast or groupcast communication using Mode 2 defined in NR-V2X. The transmitting node may be a network-enabled vehicle or may be more generally denoted as Tx. The multicast or groupcast communication is to multiple receiving nodes (generally denoted as Rx), which may include other EDs 110 (e.g., other vehicles, UEs, IoT devices, surrounding sensors, etc.) and / or the BS 170.

[0152] At 952, the Tx selects the required resources (e.g., time-frequency resources) from a resource pool. The resource pool may be pre-configured or pre-configured by the network. The BS 170 is not involved in allocating ED-specific resources to the Tx for each transmission. The Tx selects resources according to a predetermined number of transmissions / retransmissions.

[0153] Optionally, at 953, if the transmission includes the transmission of vertical check blocks, the Tx can provide the Rx (e.g., in a configuration or control signal, such as a PC5-RRC signal or an SCI transmission) with information regarding parameters for generating the vertical check blocks. The information regarding how the vertical check blocks are generated allows each Rx 14 to use the vertical check blocks and aid in decoding the information CBs. This signal can be used to indicate parameters for generating the vertical check blocks, such as the NDI, HARQ process ID, number of iterations, number of transmitted vertical check blocks, and code block partition, interleaver selection, RV or RV sequence selection, coding rate, index of the CB used to generate the vertical check blocks, and / or other information related to the generation of the vertical check blocks, as described above. The configuration or control signal can be transmitted during, together with, or after the transmission of the vertical check blocks to the Rx. For example, step 905 can occur during step 906.

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

[0155] At 956, Tx determines whether any Rx's received the transmission unsuccessfully.

[0156] For example, a Tx can determine whether any Rx failed to receive the transmission based on ACK / NACK feedback from the Rx. In some cases, the Rx may not all be fully known to the Tx, and each Rx can send a NACK only if it failed to receive the transmission. If the Tx receives a NACK from any Rx, it determines that it failed to receive. Otherwise, it determines that all Rxes successfully received the transmission.

[0157] In another example, the Rx may be known to the Tx, e.g., each Rx has a dedicated PSFCH resource and each Rx transmits ACK / NACK feedback via its dedicated PSFCH resource, in which case the Tx determines reception failure if it receives any NACK from any Rx, or determines transmission success if it receives ACK feedback from all Rx.

[0158] If Tx has performed a predetermined number of retransmissions (in addition to the initial transmission) at 954, then Tx determines at 956 whether there is still at least one Rx that has failed reception (e.g., still receives at least one NACK feedback) after the predetermined number of retransmissions.

[0159] If reception is successful at all Rxs (e.g., no NACKs are received from any Rx or ACKs are received from all Rxs), then at 956, the Tx determines that reception has failed at any Rx and method 950 ends.

[0160] If at least one Rx has failed reception as determined at 956, the Tx selects further resources from the resource pool to perform one or more retransmissions at 958. The number of retransmissions to perform and the number of vertical check blocks to transmit in each retransmission can be pre-configured at the Tx.

[0161] Optionally, at 959, the Tx can provide the Rx (e.g., in a configuration or control signal, such as a PC5-RRC signal or SCI transmission) with information regarding parameters for generating vertical check blocks. The information regarding how the vertical check blocks are generated allows each Rx 14 to use the vertical check blocks and aid in decoding the information CB. This signal can be used to indicate parameters for generating the vertical check blocks, such as the NDI, HARQ process ID, number of iterations, number of transmitted vertical check blocks, and code block partition, interleaver selection, RV or RV sequence selection, coding rate, index of the CB used to generate the vertical check blocks, and / or other information related to the generation of the vertical check blocks, as described above. The configuration or control signal can be transmitted during, together with, or after the transmission of the vertical check blocks to the Rx. For example, step 959 can occur during step 960.

[0162] At 960, Tx performs one or more retransmissions (up to a predetermined number of retransmissions allowed by the selected resource). Retransmissions can be sent to all Rxs (e.g., if all Rxs are completely unknown to Tx), or only to Rxs that failed to receive (e.g., if all Rxs are known to Tx).

[0163] Note that for broadcast transmissions, in some instances, only blind retransmissions (i.e., ACK / NACK-less retransmissions) may be supported. In blind retransmissions, the Tx sends an initial transmission and a predetermined number of retransmissions (each retransmission is a respective set of one or more vertical check blocks). In blind retransmissions, the Tx may be assigned resources by the BS 170 (in the case of Mode 1) or may select sufficient resources from a resource pool for the initial transmission and the predetermined number of retransmissions (in the case of Mode 2).

[0164] This disclosure also describes examples in which vertical check blocks are generated from multiple TBs or packets. It should be understood that the following discussion, which refers to packets in some examples, may also apply to TBs. Such vertical check blocks are sometimes referred to as cross-packet check blocks.

[0165] 10A is a signaling diagram illustrating an example of the use of cross-packet vertical check blocks in a multicast, groupcast, or broadcast transmission. The transmitting node 12 (denoted as Tx 12) and receiving nodes (denoted as Rx-1 14-1, Rx-2 14-2, and Rx-3 14-3, and commonly referred to as Rx 14) may be similar to those in FIGS. 8A and 8B. Although not shown, Tx 12 may send configuration or control signals to Rx 14 (e.g., before the initial transmission, before a retransmission, during a retransmission, along with a retransmission, or immediately after a retransmission) to provide information regarding the parameters used to generate the vertical check blocks. Such information may be necessary for Rx 14 to utilize vertical check blocks to aid in decoding.

[0166] As shown in Figure 10A, Tx 12 transmits multiple TBs to Rx 14. Each TB is transmitted in a respective packet (in this example, Packet 1, Packet 2, and Packet 3 are transmitted in 1002, 1004, and 1006, respectively). Each TB includes one or more CBs, and each TB may have a different number of CBs. Each transmission in 1002, 1004, and 1006 may be referred to as the initial transmission of the respective packet (i.e., the initial transmission of Packet 1 in 1002, the initial transmission of Packet 2 in 1004, and the initial transmission of Packet 3 in 1006).

[0167] 8A-8E, the retransmission scheme may be feedback-based (requiring ACK / NACK feedback from each Rx 14) or ACK / NACK-less (ACK / NACK feedback is optional or omitted). If feedback is transmitted, each Rx 14 may provide feedback after attempting to decode each packet (i.e., after each transmission at 1002, 1004, 1006) or after attempting to decode all packets (i.e., after the last transmission at 1006). The Tx may inform the Rx 14 in a configuration or control signal of the expected number of packets and / or the expected number of transmissions before providing feedback.

[0168] In the example of FIG. 10A, after the last packet is transmitted at 1006, Tx 12 does not receive feedback. Tx 12 determines that at least one Rx 14 failed to decode at least one of three packets. For example, as shown in FIG. 10D, Tx 12 transmits CB1 and CB2 in packet 1 at 1002, CB3 and CB4 in packet 2 at 1004, and CB5 and CB6 in packet 3 at 1006. Rx-1 14-1 fails to decode CB5 (indicated by CB5 marked with an "X"), Rx-2 14-2 fails to decode CB2 and CB5 (indicated by CB2 and CB5 marked with an "X"), and Rx-3 14-3 fails to decode CB1, CB2, and CB5 (indicated by CB1, CB2, and CB5 marked with an "X"). Notably, each Rx 14 may fail to decode a different packet. Tx 12 uses CBs from multiple packets to generate one or more vertical check blocks. For example, a vertical check block may be generated by taking the cross block bits from all CBs across all packets 1-3, as shown by arrow 1018 in Figure 10D.

[0169] As shown in FIGS. 10A and 10D, Tx 12 transmits a vertical check block to Rx 14 at 1008. Tx 12 can continue generating and transmitting cross-packet vertical check blocks until it receives ACKs from all Rx 14. In this example, only Rx-1 14-1 successfully decodes all three packets following the first retransmission at 1008, causing it to transmit an ACK to Tx 12 at 1010. Because Rx-2 14-2 and Rx-3 14-3 did not transmit ACKs, Tx 12 performs a second retransmission. In some examples, Tx 12 may generate an additional vertical check block using CBs from all packets for the second retransmission. In other examples, the vertical check blocks used for the first and second retransmissions may be generated together but transmitted in separate retransmissions. A second retransmission using the additional vertical check block is performed at 1012 (optionally, Rx-1 14-1 can be excluded from the second retransmission). The vertical check block transmitted at 1012 may be generated by taking the cross block bits from all CBs across all packets 1 through 3. In this example, both Rx-2 14-2 and Rx-3 14-3 successfully decode all three packets following the second retransmission and send ACKs back to Tx 12 at 1014 and 1016, respectively. Tx 12 then stops retransmitting. In some examples, Tx 12 performs retransmissions up to a predetermined maximum number of times.

[0170] Figure 10B is a signaling diagram illustrating another example use of cross-packet vertical check blocks in multicast, groupcast, or broadcast transmissions. Figure 10E shows packets transmitted from Tx 12 to each of Rx-1 14-1, Rx-2 14-2, and Rx-3 14-3 (commonly referred to as Rx 14) for the example of Figure 10B. Although not shown in the diagram, Tx 12 may send configuration or control signals to Rx 14 (e.g., before the initial transmission, before a retransmission, during a retransmission, along with a retransmission, or immediately after a retransmission) to provide information regarding the parameters used to generate the vertical check blocks. Such information may be necessary for Rx 14 to utilize vertical check blocks to aid in decoding.

[0171] In Figures 10B and 10E, the Rxs 14 may provide feedback following each transmission of a packet. For example, following the transmission of packet 1 at 1052, at least one Rx 14 may send at least one NACK to Tx 12 at 1054 to indicate failure to decode packet 1. For example, in Figure 10E, Rx-2 14-2 and Rx-3 14-3 fail to decode all CBs of packet 1 and send back NACKs, while Rx-1 14-1 successfully decodes packet 1 and sends back an ACK. Alternatively, instead of sending a NACK, the Rx 14 that failed to decode packet 1 could fail to send an ACK. Tx 12 uses this feedback (receiving a NACK from at least one Rx or not receiving an ACK from any Rx) to determine that there is at least one Rx 14 that failed to decode packet 1.

[0172] Tx 12 may wait to retransmit until after all three intended packets have been sent initially. At 1056, Tx 12 transmits packet 2 to all Rx 14. In this case, Rx 14 receives an ACK from all Rx 14 at 1058, indicating that all Rx 14 have successfully received and decoded packet 2.

[0173] At 1060, Tx 12 transmits packet 3 to all Rx 14. At least one Rx 14 may send at least one NACK to Tx 12, at 1062, to indicate that it failed to decode packet 1. For example, in FIG. 10E, all Rx 14 fail to decode all CBs for packet 3 and send back NACKs (each Rx 14 may fail to decode a different CB for packet 3). Alternatively, instead of sending a NACK, the Rx 14 that failed to decode packet 3 may fail to send an ACK. Tx 12 uses this feedback (receiving NACKs from at least three Rxs or no ACKs from any Rx) to determine that there is at least one Rx 14 that failed to decode packet 1.

[0174] Tx 12 generates one or more cross-packet vertical check blocks only from the CBs belonging to packets not successfully decoded by all Rx 14s. In this example, Tx 12 generates vertical check blocks from the CBs of packets 1 and 3, but not from packet 2 (which was successfully decoded by all Rx 14s) (as indicated by arrow 1063 in FIG. 10E). The vertical check blocks are transmitted in retransmissions at 1064. Configuration or control signaling sent from Tx 12 to Rx 14 may indicate to Tx 12 that the vertical check block transmitted at 1064 is generated using the CBs of packets 1 and 3, so that Rx 14 can use this information to correctly use the received vertical check blocks to help decode the CBs of packets 1 and 3. In this case, Tx 12 receives ACKs from all Rx 14s at 1066, indicating that all Rx 14s successfully decoded all three packets. Tx 12 then stops retransmitting. In some examples, Tx 12 performs retransmissions up to a predetermined maximum number of times.

[0175] In the examples of Figures 10A and 10B, vertical check blocks are generated from CBs belonging to multiple TBs (rather than from one TB). This may help to further improve the efficiency of retransmissions. Information from one retransmission can be useful for decoding CBs from different TBs. In some examples (e.g., in the example of Figure 10B), the CBs used to generate the series of vertical check blocks may be selected only from TBs that were not successfully decoded (based on feedback from multiple Rxs), which may help to further improve efficiency.

[0176] FIG. 10C is a flowchart illustrating an example method 1070 that may be performed by a transmitting node in accordance with the example signaling of FIGS. 10A and 10B.

[0177] At 1074, Tx 12 sends multiple initial transmissions of respective packets (each initial transmission being a communication of a different packet) to multiple intended Rxs 14 (e.g., signals 1002-1006 in FIG. 10A or signals 1052, 1056, 1060 in FIG. 10B). Each initial transmission may be a broadcast, groupcast, or multicast transmission. Each packet communicated in each initial transmission includes one or more pieces of information CB.

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

[0179] Optionally, at 1078, the Tx 12 determines whether reception of at least one packet by at least one Rx 14 failed. A reception failure at an Rx 14 means that the Rx 14 failed to successfully decode information CB for at least one packet. In the case of a feedback-based retransmission scheme, if at least one NACK is received in step 1076, the Tx 12 can determine that at least one Rx 14 failed to successfully decode at least one packet. In the case of an ACK / NACK-less retransmission scheme, if the Tx 12 does not receive ACKs from all intended Rx 14s, the Tx 12 can determine that at least one Rx 14 failed to successfully decode a packet. In some examples, if feedback is received after each packet transmission, the Tx 12 can also determine which packets were not successfully decoded by at least one Rx 14 (note that different Rx 14s may fail to decode different packets). In response to the feedback received in step 1076, the Tx 12 can also identify which Rx 14 experienced the reception failure.

[0180] In some instances, such as broadcast scenarios, Tx 12 may not receive feedback from any of Rx 14, and instead Tx 12 may perform an initial transmission and a predetermined number of retransmissions (also known as a blind retransmission scheme). In such cases, step 1076 may be omitted.

[0181] At 1080, Tx 12 generates one or more vertical check blocks. The vertical check blocks are generated using selected bits from at least two CBs of the packets transmitted in the initial transmission of step 1074. To generate the vertical check blocks, information bits belonging to at least one CB from each of the at least two packets are selected. In instances where Tx 12 receives feedback (in optional step 1076) indicating particular packets that were not successfully decoded, the vertical check blocks can be generated using only the bits of those particular packets. Generation of the vertical check blocks may occur at any time during method 1070 prior to transmission of the vertical check blocks. For example, the vertical check blocks could be generated prior to the initial transmission or following optional steps 1076 and 1078.

[0182] 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) can be transmitted by Tx 12 to provide Rx 14 with parameters for generating the vertical check blocks. Information about how the vertical check blocks are generated allows each Rx 14 to use the vertical check blocks (transmitted in retransmissions) to help decode the information CB. The configuration signal or control signal can be used to indicate parameters for generating the vertical check blocks, such as the NDI, HARQ process ID, number of iterations, number of transmitted vertical check blocks, and code block partition, interleaver selection, RV or RV sequence selection, coding rate, index of the CB used to generate the vertical check blocks, and / or other information related to the generation of the vertical check blocks, as described above. The configuration information can also indicate the packets used to generate the vertical check blocks. The configuration information can be received before or at the start of method 1070, or at any time during method 1070, including during, with, or after the transmission of the vertical check blocks to Rx 14. For example, step 1081 may occur during step 1082.

[0183] In some instances, no configuration or control signals need to be sent, and step 1081 may be omitted. For example, the parameters for generating vertical check blocks may be predetermined (e.g., defined in a standard) and do not need to be communicated from Tx 12 to each Rx 14.

[0184] At 1082, at least one vertical check block is transmitted to at least one Rx 14. The vertical check block may be transmitted to multiple Rxs 14 (e.g., broadcast, multicast, or groupcast, similar to the initial transmission). In some examples, the vertical check block may be transmitted to all Rxs 14 via broadcast, multicast, or groupcast, regardless of whether a given Rx 14 successfully or unsuccessfully decoded the initial transmission. In other examples, the vertical check block may be transmitted via multicast or groupcast only to Rxs 14 that were determined (in optional step 1078) to have unsuccessfully decoded the initial transmission.

[0185] An optional further step of receiving feedback and sending subsequent retransmissions can be performed as needed (eg, up to a predetermined number of retransmissions).

[0186] In the above example, the transmitting node transmits information CB in the initial transmission and transmits vertical check blocks in subsequent retransmissions. However, it should be understood that in the examples described herein, at least one vertical check block may also be transmitted with information CB in the initial transmission.

[0187] The signaling performed is similar to that described above in Figures 8A, 8B, 10A, and 10B, except that the initial transmission includes at least one vertical check block along with the information CB. The transmitting node generates the vertical check block from the CB before the initial transmission and includes the vertical check block in the initial transmission. The transmitting node may send a configuration or control signal before the initial transmission indicating to the receiving node that a vertical check block is included in the initial transmission. Subsequent retransmissions of additional vertical check blocks may be performed as needed (e.g., according to a predetermined number of retransmissions or based on feedback from the receiving node), similar to that described above.

[0188] In this example, since at least one vertical check block is transmitted in the initial transmission, the generation and transmission of the vertical check blocks is performed by the transmitting node without feedback from any receiving node. Thus, in some examples, the generation of the vertical check blocks may be performed according to predetermined parameters (e.g., the number of vertical check blocks to generate, the selection of bits to generate the vertical check blocks, etc.).

[0189] In some examples, the number of vertical check blocks to include in the information CB in the initial transmission may be determined by the transmitting node based on channel characteristics. The transmitting node may characterize the transmission channels of all intended receiving nodes (e.g., using channel feedback from the receiving nodes) to determine the code rate of the vertical check blocks in the initial transmission. The code rate may be determined based on a trade-off between increased overhead (due to the addition of vertical check blocks in the initial transmission) and the likelihood that any receiver can completely decode the information CB (due to poor channel quality). For example, the code rate in the initial transmission may be determined based on channel state information feedback (e.g., the SNR of each receiving node). For example, if the SNR of a receiving node with the worst channel quality is below a certain threshold, a given number of vertical check blocks may be transmitted in the initial transmission. The threshold and the corresponding number of vertical check blocks may be determined based, for example, on achieving a minimum probability that all receiving nodes will successfully decode the packet after the initial transmission. For example, there may be multiple predetermined SNR thresholds, and a corresponding number of vertical check blocks may be predefined for each SNR threshold. This information may be predefined, for example, in a standard. In some instances, instead of using the receiving node with the worst channel quality as the basis for determining the code rate, the average channel quality of all receiving nodes, the channel quality based on a certain percentage of receiving nodes, or some other statistic of the channel quality of the receiving nodes may be used. For example, if one or more receiving nodes are known to have poor channel quality (and therefore likely need redundant information to aid in CB decoding), it may be more efficient to include a vertical check block in the initial transmission rather than waiting for a NACK from those receiving nodes.

[0190] The initial transmission, which includes the CB as well as the vertical check blocks, can be multicast, groupcast, or broadcast to the intended receiving nodes (eg, similar to the Fountain Code in MBMS).

[0191] If additional vertical check blocks are required after the initial transmission, they may be generated using a different interleaver or RV than that used for the vertical check blocks included in the initial transmission.

[0192] Figure 11A is a flow chart illustrating an example of a method 1100 that may be performed by a transmitting node whose initial transmission includes a vertical check block. Figure 11B illustrates an example of a transmission by Tx 12 to Rx-1 14-1, Rx-2 14-2, and Rx-3 14-3 (commonly referred to as Rx 14).

[0193] Optionally, at 1102, the transmitting node receives channel feedback from the intended receiving node. Using this channel feedback information, the transmitting node may determine the code rate and therefore the number of vertical check blocks to include in the initial transmission. In some cases, the code rate and / or the number of vertical check blocks to include in the initial transmission may be predetermined (e.g., according to a standard or pre-configured), and step 1102 may be omitted. Note that in step 1102, the number of vertical check blocks to include in the initial transmission may be determined to be zero.

[0194] At 1104, Tx 12 generates one or more vertical check blocks. The vertical check blocks are generated using selected bits from at least two of the information CB to be transmitted in the initial transmission.

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

[0196] In some instances, no configuration or control signals need to be sent, and step 1106 may be omitted. For example, the parameters for generating and transmitting vertical check blocks may be predetermined (e.g., defined in a standard) and do not need to be communicated from Tx 12 to each Rx 14.

[0197] At 1108, Tx 12 sends an initial transmission to multiple intended Rxs 14. The initial transmission includes information CB and at least one vertical check block. The initial transmission may be a broadcast, groupcast, or multicast transmission. In the example of FIG. 11B, at 1152, the initial transmission includes CBs 1-9 and two vertical check blocks (VCB1 and VCB2).

[0198] Optionally, at 1110, feedback may be received from one or more Rxs 14. For example, in a feedback-based retransmission scheme, each Rx 14 may be required to send ACK / NACK feedback back to Tx 12. In an ACK / NACK-less retransmission scheme, ACK feedback is optional and there may be no NACK feedback. In the example of FIG. 11B, Rx-2 14-2 and Rx-3 14-3 each fail to decode at least one information CB (Rx-2 14-2 and Rx-3 14-3 may fail to decode different CBs) and return a NACK at 1154, while Rx-1 14-1 successfully decodes all CBs and returns an ACK at 1154.

[0199] Optionally, at 1112, Tx 12 determines whether reception by at least one Rx 14 failed. A reception failure by an Rx 14 means that the Rx 14 was unable to successfully decode the information CB. In the case of a feedback-based retransmission scheme, Tx 12 can determine that at least one Rx 14 was unable to successfully decode the CB if at least one NACK was received in step 1110. In the case of an ACK / NACK-less retransmission scheme, Tx 12 can determine that at least one Rx 14 was unable to successfully decode the CB if Tx 12 did not receive ACKs from all intended Rx 14s. In response to the feedback received in step 1110, Tx 12 can also identify which Rx 14 experienced the reception failure.

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

[0201] Optionally, at 1114, Tx 12 generates one or more additional vertical check blocks. Step 1114 may be performed if optional step 1112 determines that reception by at least one Rx 14 was unsuccessful. Alternatively, step 1114 may be performed in a blind retransmission manner as part of a predetermined number of retransmissions. The additional vertical check blocks may be generated using a different interleaver than the one used to generate the vertical check blocks in step 1106. Additional configuration or control signals may be sent to Rx 14 to indicate the parameters used to generate the additional vertical check blocks.

[0202] Optionally, at 1115, a configuration or control signal (e.g., an RRC signal, a PC5-RRC signal, a DCI transmission, or an SCI transmission) can be transmitted by Tx 12 to provide parameters to Rx 14 for generating additional vertical check blocks, similar to step 1106 described above. For example, step 1115 can occur during step 1116.

[0203] In some instances, there may be no need to send configuration or control signals for the additional vertical check blocks, and step 1115 may be omitted. For example, the parameters for generating the vertical check blocks may be predetermined (e.g., defined in a standard) and do not need to be communicated from Tx 12 to each Rx 14, or the parameters for generating the additional vertical check blocks may have already been signaled in step 1106.

[0204] Optionally, at 1116, at least one additional vertical check block is transmitted to at least one Rx 14. The additional vertical check block may be transmitted to multiple Rxs 14 (e.g., via broadcast, multicast, or groupcast, similar to the initial transmission). In some examples, the additional vertical check block may be transmitted via broadcast, multicast, or groupcast to all Rxs 14, regardless of whether a given Rx 14 successfully or unsuccessfully decoded the initial transmission. In other examples, the additional vertical check block may be transmitted via multicast or groupcast only to Rxs 14 that were determined (in optional step 1112) to have unsuccessfully decoded the initial transmission. In the example of FIG. 11B, one additional vertical check block (VCB3) is transmitted at 1156.

[0205] In some examples, the additional vertical check blocks transmitted in optional step 1116 may be from the vertical check blocks generated in step 1106 (in which case step 1114 may be omitted). For example, a subset of the generated vertical check blocks may be included in the initial transmission, and the remaining vertical check blocks may be transmitted in step 1116.

[0206] An optional further step of receiving feedback and sending subsequent retransmissions can be performed as needed (e.g., up to a predetermined number of retransmissions). In the example of Figure 11B, ACKs are received from all Rx's 14 at 1158.

[0207] In the above example, the transmitting node that transmitted the information CB in the initial transmission is also responsible for transmitting the vertical check blocks in the retransmission. However, in the example described here, at least one vertical check block may be transmitted by another assisting transmitting node. The vertical check blocks may be generated by different transmitting nodes independently and without coordination. Thus, multiple transmitting nodes can cooperate to implement a retransmission scheme together. This may be suitable for blind retransmission schemes (e.g., in the case of rateless codes) where the assisting transmitting nodes do not require feedback from the receiving nodes.

[0208] FIG. 12A is a signaling diagram illustrating an example of using two or more transmitting nodes to generate and transmit vertical check blocks in a multicast, groupcast, or broadcast transmission. In this example, there are two transmitting nodes (designated a first transmitting node Tx-1 12-1 and a second transmitting node Tx-2 12-2, and generally referred to as Tx 12). For simplicity, FIG. 12A does not show each Rx 14 individually, but it should be understood that each Tx 12 transmits to multiple Rx 14s. FIG. 12C illustrates a transmission according to the example of FIG. 12A, with three Rx 14s. Although not shown in the diagram, one or both Tx 12s may send configuration or control signals to Rx 14 (e.g., before the initial transmission, before a retransmission, along with a retransmission, during a retransmission, or immediately after a retransmission) to provide information regarding the parameters used to generate the vertical check blocks. Such information may be necessary for Rx 14 to utilize the vertical check blocks to aid in decoding.

[0209] In the example of Figure 12A, Tx-1 12-1 and Tx-2 12-2 may communicate with each other via a communication link. The communication link between Tx-1 12-1 and Tx-2 12-2 may be a backhaul link (e.g., when Tx-1 12-1 and Tx-2 12-2 are both BS 170) or other wired or wireless communication link (e.g., a sidelink when Tx-1 12-1 and Tx-2 12-2 are both ED 110). In other examples, Tx-1 12-1 and Tx-2 12-2 may communicate with each other via a source-to-source link (e.g., when Tx-1 12-1 and Tx-2 12-2 are different transmitting devices of the same source). In another example, there may be no communication between Tx-1 12-1 and Tx-2 12-2 via a direct communication link, but Tx-2 12-2 may have access to or be provided with the information CB or vertical check block. 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 Tx-1 12-1 and Tx-2 12-2 are both EDs 110, then both Tx-1 12-1 and Tx-2 12-2 may be managed by BS 170), and the network entity may send the information CB to both Tx-1 and Tx-2, allowing Tx-2 12-2 to obtain the CB or vertical check block. In another example, Tx-2 12-2 may be a cooperative ED that provides cooperation to assist Rx 14 in receiving the information CB. While Tx-1 12-1 transmits information CB to multiple Rxs 14 in transmission 1202, Tx-1 12-1 may also be transmitting information CB to Tx-2 12-2 via the same transmission 1202 or via another link.

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

[0211] 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 that Rx 14 successfully decodes the initial transmission. In some examples, RX 14 may provide optional ACK feedback only if Rx 14 successfully decodes the initial transmission and there is no other feedback. In some examples (e.g., in a blind retransmission scheme), there may be no ACK or NACK feedback at all. In the example shown in FIG. 12C, only Rx-1 14-1 successfully decodes all CBs and sends back an ACK at 1204. Rx-2 14-2 and Rx-3 14-3 each fail to decode a different CB and do not send feedback at 1204.

[0212] When Tx-1 12-1 obtains feedback from the Rxs 14, Tx-1 12-1 may determine that at least one Rx 14 did not 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 further provide information CB to Tx-2 12-2 to generate one or more vertical check blocks, or may provide the vertical check block generated by Tx-1 12-1 to Tx-2 12-2. Tx-2 12-2 transmits a vertical check block at 1206 (shown as VCB1 in FIG. 12C). The transmission at 1206 may be for all Rxs 14 or only for those Rxs 14 that did not successfully decode the initial transmission (e.g., indicated by NACK feedback or lack of ACK feedback from those Rxs 14). In the example of FIG. 12C, the transmission at 1206 is sent to all Rx.

[0213] In other examples, Tx-2 12-2 may generate and transmit one or more vertical check blocks independently of Tx-1 12-1. For example, Tx-1 12-1 and Tx-2 12-2 may each be configured to perform a predetermined number of transmissions / retransmissions. Furthermore, transmissions at 1202 and 1206 by Tx-1 12-1 and Tx-2 12-2 may occur simultaneously or overlap in time.

[0214] Although not shown in Figures 12A and 12C, Tx-1 12-1 may perform one or more retransmissions. Each vertical check block transmitted by each of Tx-1 12-1 and Tx-2 12-2 may be generated using a different interleaver.

[0215] Optionally, at 1210, Tx-1 12-1 may receive feedback from Rx 14 indicating successful decoding of the CB. In the example of FIG. 12C, all Rx 14 feedback an ACK to Tx-1 12-1. The retransmission may then terminate. In other examples, there may be no feedback, and Tx-1 12-1 and / or Tx-2 12-2 may independently perform a predetermined number of retransmissions.

[0216] FIG. 12B is a flowchart illustrating an example method 1250 that may be performed by the second transmitting node Tx-2 12-2 in accordance with the signaling example of FIG. 12A.

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

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

[0219] Optionally, Tx-2 12-2 may acquire the CB at 1254 (which may be sent by Tx-1 12-1 in an initial transmission, e.g., signal 1102A in FIG. 12A). As previously mentioned, Tx-2 12-2 may acquire the CB in a variety of ways, such as directly over the communications link between Tx-1 12-1 and Tx-2 12-2, or from another network entity (e.g., from a DL, UL, or SL transmission). In some examples, the configuration information and the CB may be acquired simultaneously or together in the same communication.

[0220] In some instances, 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 decode the initial transmission and that a retransmission is necessary. In other instances, Tx-2 12-2 may generate vertical check blocks and perform retransmissions independently of Tx-1 12-1.

[0221] At 1256, one or more vertical check blocks are generated (e.g., using the parameters indicated in optional step 1252). The vertical check blocks are generated from information bits selected from two or more CBs transmitted in the initial transmission by Tx-1 12-1. In some examples, Tx-2 12-2 may be provided with a vertical check block (e.g., from a DL, UL, or SL transmission), and step 1256 may be omitted.

[0222] At 1258, the vertical check block is transmitted to at least one Rx 14. In some examples (e.g., in a blind retransmission scheme), the vertical check block may be broadcast, multicast, or groupcast to all Rx 14 regardless of whether a given Rx 14 successfully decoded the initial transmission or not.

[0223] This disclosure describes some examples with reference to flowcharts, and it should be understood that the steps described may be performed in a different order than that shown and may be adapted to any of the examples disclosed herein.

[0224] This disclosure refers to vertical check blocks. It should be understood that vertical check blocks may also be referred to as cross packet check blocks, cross TB check blocks, or cross code block check blocks, among other possibilities, depending on the implementation. Furthermore, check blocks may equivalently be referred to as parity blocks or redundancy blocks, among other possibilities. The use of vertical check blocks is sometimes referred to as product code-based network coding.

[0225] This disclosure is applicable to systematic codes (e.g., LPDC codes or Turbo codes) as well as non-systematic codes (e.g., Polar codes, linear block codes, convolutional codes). That is, as described herein, vertical check blocks may be generated from the encoded CB using systematic or non-systematic codes.

[0226] This disclosure describes the use of vertical check blocks for HARQ retransmissions in broadcast, multicast, and groupcast scenarios. Examples may be suitable for feedback-based retransmission schemes, as well as ACK / NACK-less or rateless retransmission schemes.

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

[0228] The disclosed examples may be implemented in particular V2X applications or IoT applications, and while some example descriptions are provided in the context of V2X, it should be understood that the examples described herein may also be applicable to other applications.

[0229] In Example 1, the present disclosure provides a method, comprising: transmitting two or more information code blocks (CB) to a plurality of intended receiving nodes; generating one or more cross CB check blocks, each cross CB check block being generated based on a set of cross CB bits, the set of cross CB bits including at least one bit selected from each of at least two information CBs; transmitting at least one of the one or more cross CB check blocks to at least one of the intended receiving nodes; The present invention provides a method comprising:

[0230] Example 2 of the present disclosure provides a method according to Example 1, wherein the two or more information CBs are transmitted to the plurality of intended receiving nodes in a broadcast, multicast, or groupcast transmission, and the at least one cross CB check block is transmitted to two or more intended receiving nodes in a broadcast, multicast, or groupcast transmission.

[0231] In Example 3 of the present disclosure, the method comprises: receiving feedback indicating whether each intended receiving node successfully decoded the two or more pieces of information CB; transmitting said at least one cross CB check block after determining from said feedback that at least one of said intended receiving nodes did not successfully decode said two or more information CBs; The method of Example 1 or 2 further comprises:

[0232] In Example 4 of the present disclosure, a method as described in Example 3 is provided, wherein negative acknowledgement (NACK) feedback is received to indicate that each intended receiving node did not successfully decode the two or more pieces of information CB.

[0233] Example 5 of the present disclosure provides a method as described in Example 3, wherein the absence of acknowledgement (ACK) feedback from each of the intended receiving nodes indicates that each of the intended receiving nodes did not successfully decode the two or more pieces of information CB.

[0234] Example 6 of the present disclosure provides a method as described in Example 3, wherein the at least one cross CB check block is transmitted only to at least one of the intended receiving nodes that did not successfully decode the two or more information CBs.

[0235] In Example 7 of the present disclosure, the method of Example 1 or 2 is provided, wherein the at least one cross CB check block is transmitted to all of the plurality of intended receiving nodes.

[0236] Example 8 of the present disclosure provides the method of Example 7, wherein the at least one cross CB check block is transmitted in the absence of feedback from any of the intended receiving nodes.

[0237] Example 9 of the present disclosure provides a method as described in Example 8, in which each set of one or more cross CB check blocks is transmitted in each retransmission for a predetermined number of retransmissions without receiving feedback from any of the intended receiving nodes for the initial transmission.

[0238] Example 10 of the present disclosure provides a method according to Example 1 or 2, wherein the two or more information CBs are transmitted to the plurality of intended receiving nodes in at least two separately transmitted packets, and one or more cross CB check blocks are generated based on selected bits from the CBs of each of the at least two packets.

[0239] In Example 11 of the present disclosure, a method includes receiving feedback from at least one intended receiving node indicating whether the at least one packet was not successfully decoded; generating the one or more cross CB check blocks based on selected bits only from the at least one packet that was not successfully decoded; The method of Example 10 is provided, further comprising:

[0240] Example 12 of the present disclosure provides a method as described in Example 11, wherein at least one of the one or more cross CB check blocks is transmitted only to the at least one intended receiving node that did not successfully decode the two or more packets.

[0241] Example 13 of the present disclosure provides a method as described in Example 10, wherein at least one of the one or more cross CB check blocks is transmitted in the absence of feedback from any of the intended receiving nodes.

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

[0243] Example 15 of the present disclosure provides a method according to Example 14, further comprising determining, from channel feedback received from the intended receiving node, the number of cross CB check blocks to be transmitted together with the two or more information CBs in the single transmission.

[0244] Example 16 of the present disclosure provides a method according to any one of Examples 1 to 14, further comprising transmitting a configuration or control signal to the intended receiving node, the configuration signal including information regarding one or more parameters used to generate the one or more cross CB check blocks.

[0245] In Example 17 of the present disclosure, the configuration or control signal is: Instructions for new transmission or retransmission, HARQ process identifier, The number of retransmission iterations, Number of cross CB check blocks sent, Indices 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 a redundancy version (RV) or RV sequence indicating how the one or more cross CB check blocks were generated; The method of Example 16 is provided, which includes information regarding one or more of:

[0246] Example 18 of the present disclosure provides a method according to any one of Examples 1 to 17, further comprising receiving a configuration or control signal, the configuration or control signal including information regarding one or more parameters used to generate the one or more cross CB check blocks.

[0247] Example 19 of the present disclosure provides the method of any one of Examples 1 to 18, wherein the set of cross CB bits for generating the one or more cross CB check blocks is selected according to a predetermined interleaver.

[0248] Example 20 of the present disclosure provides a method according to Example 19, further comprising the step of generating one or more additional cross CB check blocks based on another set of cross CB bits, wherein the another set of cross CB bits is selected according to another predetermined interleaver.

[0249] In Example 21 of the present disclosure, receiving, from a base station, scheduled resource allocations for transmitting the two or more pieces of information CB; receiving feedback from at least one intended receiving node indicating whether at least one of said two or more pieces of information CB was not successfully decoded; sending a negative acknowledgement (NACK) report to the base station; receiving, from the base station, an additional scaled resource allocation for transmitting the at least one cross CB check block; There is provided a method according to any one of Examples 1 to 20, further comprising:

[0250] In Example 22 of the present disclosure, The method of any one of Examples 1 to 20 is provided, further comprising receiving, from a base station, scheduled resource allocations for transmitting the two or more information CBs and for transmitting a predetermined number of cross CB check blocks.

[0251] In Example 23 of the present disclosure, The method according to any one of Examples 1 to 20 is provided, further comprising selecting resources from a resource pool for transmitting the two or more pieces of information CB.

[0252] In Example 24 of the present disclosure, The method of any one of Examples 1 to 20 is provided, further comprising selecting resources from a resource pool for transmitting the two or more information CBs and for transmitting a predetermined number of cross CB check blocks.

[0253] In Example 25 of the present disclosure, there is provided a method, comprising: receiving information for generating one or more cross code block (CB) check blocks, each cross CB check block being generated based on a set of cross CB bits, the set of cross CB bits including at least one bit selected from each of at least two information CBs; transmitting at least one of the one or more cross CB check blocks to a plurality of intended receiving nodes; A method is provided that includes:

[0254] In Example 26 of the present disclosure, the method of Example 25 is provided, wherein the at least one cross CB check block is transmitted to the intended receiving node in a broadcast, multicast, or groupcast transmission.

[0255] Example 27 of the present disclosure provides the method of Example 25 or 26, wherein the received information includes the at least two pieces of information CB.

[0256] Example 28 of the present disclosure provides a method according to any one of Examples 25 to 27, wherein the received information includes information regarding one or more parameters used to generate the one or more cross CB check blocks.

[0257] In Example 29 of the present disclosure, the received information is: Instructions for new transmission or retransmission, HARQ process identifier, The number of retransmission iterations, Number of cross CB check blocks sent, Indices 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 a redundancy version (RV) or RV sequence indicating how the one or more cross CB check blocks were generated; The method of Example 28 is provided, which includes information regarding one or more of:

[0258] In Example 30 of the present disclosure, there is provided the method of any one of Examples 1-29, wherein the method is performed in a network-enabled vehicle.

[0259] Example 31 of the present disclosure provides the method of any one of Examples 1 to 29, wherein the method is performed on a user equipment device.

[0260] In Example 32 of the present disclosure, there is provided the method of any one of Examples 1-20 or 25-29, wherein the method is performed at a base station.

[0261] Example 33 of the present disclosure provides the method of any one of Examples 1-32, wherein the CB is encoded using a systematic code.

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

[0263] Example 35 of the present disclosure provides the method of any one of Examples 1-32, wherein the CB is encoded using a non-systematic code.

[0264] Example 36 of the present disclosure provides the method of Example 35, wherein the CB is encoded using a polar code, a linear block code, or a convolutional code.

[0265] In Example 37 of the present disclosure, an apparatus is provided that includes a processing unit, the processing unit configured to execute machine-readable instructions to cause the apparatus to perform a method described in any one of Examples 1 to 36.

[0266] In Example 38 of the present disclosure, a computer-readable medium is provided having machine-executable instructions stored thereon, the instructions, when executed by a processing unit of a device, causing the device to perform the method of any one of Examples 1 to 36.

[0267] Although this disclosure describes methods and processes having steps in a particular order, one or more steps of the methods and processes can be omitted or modified as desired. One or more steps can be performed in an order other than the order described as desired.

[0268] Although the present disclosure has been described, at least in part, with respect to methods, those skilled in the art will understand that the present disclosure also covers various components for performing at least some aspects and features of the described methods, whether through hardware components, software, or any combination of the two. Accordingly, the technical solutions of the present disclosure may be embodied in the form of a software product. Suitable software products may be stored on pre-recorded storage devices or other similar non-volatile or non-transitory computer-readable media, such as DVDs, CD-ROMs, USB flash disks, removable hard disks, or other storage media. The software product tangibly stores instructions that enable a processing device (e.g., a personal computer, a server, or a network device) to execute the method examples disclosed herein. The machine-executable instructions may be in the form of code sequences, configuration information, or other data that, when executed, cause a machine (e.g., a processor or other processing device) to perform the method steps according to the example methods of the present disclosure.

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

[0270] All values ​​and subranges within the disclosed ranges are also disclosed. Also, while the systems, devices, and processes disclosed and illustrated herein may include a particular number of elements / components, the systems, devices, and assemblies can be modified to include additional or fewer such elements / components. For example, while any of the disclosed elements / components may be referred to in the singular, the embodiments disclosed herein can be modified to include a plurality of such elements / components. The subject matter described herein covers and encompasses all appropriate technical modifications.

Claims

1. 1. A method comprising: transmitting two or more information code blocks (CBs) to a plurality of intended receiving nodes, each of the two or more information CBs including a respective set of information bits and a respective CB-specific check block encoded from the respective set of information bits; generating one or more cross CB check blocks, each cross CB check block being generated by combining at least two subsets of one or more bits, each of the at least two subsets being a respective subset of bits of a respective one of the at least two pieces of information CB; transmitting at least one of the one or more cross CB check blocks to at least one of the intended receiving nodes; Including, A method wherein each set of one or more cross CB check blocks is transmitted in each retransmission for a predetermined number of retransmissions in the absence of feedback from any of the intended receiving nodes for an initial transmission.

2. 2. The method of claim 1, wherein the two or more information CBs are transmitted in a broadcast, multicast, or groupcast transmission to the plurality of intended receiving nodes, and at least one cross CB check block is transmitted in a broadcast, multicast, or groupcast transmission to two or more of the intended receiving nodes.

3. receiving an acknowledgement (ACK) feedback from at least one intended receiving node after the initial transmission or after a given retransmission; 2. The method of claim 1, wherein further retransmissions of the predetermined number of retransmissions after the initial transmission or the given retransmission are not sent to the at least one intended receiving node that received the ACK feedback.

4. The method of claim 1 , wherein the predetermined number of retransmissions is performed until an acknowledgement (ACK) feedback is received from each of the plurality of intended receiving nodes.

5. 2. The method of claim 1, wherein the two or more information CBs are transmitted to the plurality of intended receiving nodes in at least two separately transmitted packets, and one or more cross CB check blocks are generated by combining selected bits from the CBs of each of the at least two packets.

6. transmitting a control signal to the intended receiving node, the control signal indicating information regarding one or more parameters used in generating the one or more cross CB check blocks; The control signal may be: Indication of new transmission or retransmission, HARQ process identifier, The number of retransmission iterations, Number of cross CB check blocks sent, Indices 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 a redundancy version (RV) or RV sequence indicating how the one or more cross CB check blocks were generated; The method of claim 1 , wherein the method indicates information regarding one or more of:

7. receiving, from a base station, a resource allocation for transmitting the two or more pieces of information CB; The method of claim 1 , wherein resources for transmitting at least one cross CB check block are also allocated by the base station.

8. receiving feedback from at least one intended receiving node indicating whether at least one of the two or more pieces of information CB was not successfully decoded; sending a negative acknowledgement (NACK) report to the base station; receiving, from the base station, an additional resource allocation for transmitting the at least one cross CB check block; The method of claim 7 further comprising:

9. The method of claim 7 , wherein the resource allocation from the base station also allocates resources for transmission of a predetermined number of cross CB check blocks.

10. selecting resources from a resource pool for transmitting the two or more pieces of information CB; The method of claim 1 , wherein resources for transmitting at least one cross CB check block are also selected from the resource pool.

11. An apparatus including a processing unit, said processing unit configured to execute machine-readable instructions to cause said apparatus to perform a method according to any one of claims 1 to 10.

12. 11. A computer readable storage medium having machine executable instructions stored thereon, said instructions, when executed by a processing unit of a device, causing said device to perform the method of any one of claims 1 to 10.

Images