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

Abstract

A two-dimensional (2D) coding method and system is described for broadcast, multicast, or groupcast applications. Two or more information code blocks (CBs) are transmitted to multiple intended receiving nodes. One or more cross CB check blocks are generated, 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 of the information CBs. At least one cross CB check block is transmitted to at least one of the intended receiving nodes.

Description

Technical Field

[0001] [Related Applications] This disclosure claims priority to U.S. Provisional Patent Application No. 63 / 053,337, filed July 17, 2020, "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, "METHODS AND APPRATUSES FOR BROADCAST MULTICAST OR GROUPCAST TRANSMISSION USING VERTICAL CHECK BLOCKS", the entire disclosures of which are incorporated herein by reference.

[0002] [Technical Field] This disclosure relates to wireless communications and includes the use of product coding in broadcast, multicast or groupcast wireless communications.

Background Art

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

[0004] V2X represents a category of communication scenarios involving vehicles (acting as user equipment (UEs)), 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 communication using Long-term evolution (LTE) cellular technology. LTE-V primarily focuses on broadcasting messages such as safety messages. However, there is also 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 broadcast, multicast, or groupcast scenarios, errors in received data may vary from one receiving node to another. Existing retransmission schemes may not be suitable or efficient for broadcast, multicast, or groupcast scenarios. [Overview of the project]

[0005] In various examples, this disclosure describes methods and equipment for physical (PHY) layer network coding based on two-dimensional (2D) co-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 inefficiency, delay, and overhead. These conventional retransmission schemes typically rely on retransmitting entire transport blocks or groups of code blocks in a highly redundant manner. Furthermore, retransmission in broadcast, multicast, and groupcast scenarios complicates matters because different receivers may have different undecoded code blocks, requiring the retransmission of entire transport blocks or multiple groups of code blocks in these scenarios. Retransmission based on un-erased code, when used on non-erased channels, can suffer performance disadvantages because undecoded code blocks are discarded and soft information for co-decoding is not preserved.

[0007] Embodiments of this disclosure that utilize PHY layer network coding based on 2D co-coding resolve or improve upon some or all of these shortcomings. Thus, the methods and apparatus of this disclosure can avoid the expensive and inefficient retransmission of conventional approaches. Furthermore, the ability to utilize soft information from failed decoding attempts provides improved performance compared to retransmission schemes based on code outside the erase. In the example described herein, even if different receivers have different erroneous code blocks in the initial transmission, a single vertical check block can be multicast or broadcast to different receivers and used for decoding by the different receivers.

[0008] In exemplary embodiments, this disclosure describes a method, The steps include sending two or more information code blocks (CBs) to multiple intended receiving nodes, A step of generating one or more crossCB check blocks, each crossCB check block being generated based on a set of crossCB bits, the set of crossCB bits including at least one bit selected from each of at least two information CBs, The steps include sending at least one of the one or more cross-CB check blocks to at least one of the intended receiving nodes, Describe the method that includes it.

[0009] In the aforementioned embodiment of the method, the two or more information CBs may be transmitted to the multiple intended receiving nodes by 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 by broadcast, multicast, or groupcast transmission.

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

[0011] In any of the aforementioned embodiments 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 any feedback from any of the receiving nodes intended for the initial transmission.

[0012] In any of the aforementioned embodiments of the method, the method may further include the step of receiving acknowledgment (ACK) feedback from at least one intended receiving node after the initial transmission or after a given retransmission. The retransmission after the initial transmission or the given retransmission may not be transmitted to the at least one intended receiving node that received the ACK feedback.

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

[0014] In any of the aforementioned embodiments 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 bits selected from each of the CBs of the at least two packets.

[0015] In any of the aforementioned embodiments of the method, the method may further include the step of transmitting a configuration or control signal to the intended receiving node, wherein the configuration or control signal includes information about one or more parameters used to generate the one or more cross-CB check blocks. The configuration or control signal is as follows: Instructions for new transmission or retransmission, HARQ process identifier, Number of retransmission iterations, Number of cross-CB check blocks sent, The 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 aforementioned one or more cross-CB check blocks, or A redundant version (RV) or RV sequence showing a method for generating one or more cross-CB check blocks, It may include information about one or more of the following.

[0016] In any of the foregoing 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 aspect of the method, the method includes receiving feedback indicating whether at least one intended receiving node has failed to successfully decode at least one of the two or more information CBs; transmitting a negative acknowledgment (NACK) report to the base station; and 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 transmitting a predetermined number of cross-CB check blocks.

[0019] In any of the foregoing aspects of the method, the method may further include selecting, from a resource pool, resources 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. The processing unit is configured to execute machine-readable instructions that cause the apparatus to transmit two or more information code blocks (CBs) to a plurality of intended receiving nodes, Generate 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, Cause 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 foregoing aspect of the device, the two or more information CBs may be transmitted by broadcast, multicast, or group-cast transmission to the plurality of intended receiving nodes, and the at least one cross-CB check block may be transmitted by broadcast, multicast, or group-cast transmission to two or more intended receiving nodes.

[0022] In any of the foregoing aspects of the device, the feedback from the intended receiving nodes may indicate whether each intended receiving node has successfully decoded two or more information CBs. The processing unit may further be configured to execute the instructions to cause the device to determine that at least one of the intended receiving nodes has not successfully decoded the two or more information CBs from a received negative acknowledgment (NACK) feedback or the absence of an acknowledgment (ACK) feedback, and then cause the at least one cross-CB check block to be transmitted.

[0023] In any of the foregoing aspects of the device, each set of one or more cross-CB check blocks may be transmitted in each retransmission during 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 embodiments of the device, the processing unit may be configured to execute the instruction causing the device to transmit a configuration or control signal to the intended receiving node, the configuration or control signal including information about one or more parameters used to generate the one or more cross-CB check blocks. The configuration or control signal is as follows: Instructions for new transmission or retransmission, HARQ process identifier, Number of retransmission attempts, Number of cross-CB check blocks sent, The 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 aforementioned one or more cross-CB check blocks, or A redundant version (RV) or RV sequence showing a method for generating one or more cross-CB check blocks, It may include information about one or more of the following.

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

[0026] In any of the aforementioned embodiments of the device, the processing unit may be further configured to execute the instruction causing the device to select a resource from a resource pool for transmitting the two or more information CBs. The resource for transmitting the at least one cross-CB check block may be selected from the resource pool.

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

[0028] In an exemplary embodiment, the present disclosure describes a computer-readable medium having stored machine-readable instructions. When the instructions are executed by a processing unit of the device, the device receives By causing multiple intended receiving nodes to send two or more information code blocks (CBs), One or more crossCB check blocks are generated, each crossCB check block is generated based on a set of crossCB bits, the set of crossCB bits includes at least one bit selected from each of at least two information CBs, The system causes at least one of the one or more cross-CB check blocks to be sent to at least one of the intended receiving nodes.

[0029] In any embodiment of a computer-readable medium, when the instruction is executed by the processing unit of the device, the device may be caused to perform any of the above-described methods. [Brief explanation of the drawing]

[0030] For example, see the following attached drawings illustrating exemplary embodiments of the present application.

[0031] [Figure 1] This is a schematic diagram of an example of a communication system suitable for implementing the examples described in this specification.

[0032] [Figure 2] A block diagram showing an example of a base station (BS) suitable for carrying out the examples described in this specification. [Figure 3] A branch diagram showing an example of an electronic device (ED) suitable for carrying out the examples described in this specification.

[0033] [Figure 4A] An example of a code structure for a single transport block (TB) containing horizontal and vertical check blocks is shown. [Figure 4B]An example of a code structure for a single transport block (TB) containing horizontal and vertical check blocks is shown.

[0034] [Figure 5A] This demonstrates the use of different interleavers to generate different sets of vertical check blocks. [Figure 5B] This demonstrates the use of different interleavers to generate different sets of vertical check blocks.

[0035] [Figure 6] This shows an example of a single TB code structure based on unorganized code including vertical check blocks.

[0036] [Figure 7] This shows an example of a code structure that generates vertical check blocks from multiple TBs.

[0037] [Figure 8A] This signaling diagram shows an example of using vertical check blocks for broadcast, multicast, or groupcast transmissions. [Figure 8B] This signaling diagram shows an example of using vertical check blocks for broadcast, multicast, or groupcast transmissions.

[0038] [Figure 8C] Figures 8A and 8B are flowcharts illustrating examples of methods that may be performed by the transmitting node.

[0039] [Figure 8D] Figures 8A and 8B show examples of code blocks that will be sent. [Figure 8E] Figures 8A and 8B show examples of code blocks that will be sent.

[0040] [Figure 9A]This flowchart illustrates examples of possible methods that a sending node might use to acquire resources for sending and retransmitting in a group cast scenario. [Figure 9B] This flowchart illustrates examples of possible methods that a sending node might use to acquire resources for sending and retransmitting in a group cast scenario.

[0041] [Figure 10A] This signaling diagram illustrates an example of using a cross-packet vertical check block for broadcast, multicast, or groupcast transmission. [Figure 10B] This signaling diagram illustrates an example of using a cross-packet vertical check block for broadcast, multicast, or groupcast transmission.

[0042] [Figure 10C] Figures 10A and 10B are flowcharts illustrating examples of methods that may be performed by the transmitting node.

[0043] [Figure 10D] Examples of code blocks sent are shown in Figures 10A and 10B. [Figure 10E] Examples of code blocks sent are shown in Figures 10A and 10B.

[0044] [Figure 11A] This flowchart illustrates examples of how a send node might perform to include a vertical check block in the initial transmission.

[0045] [Figure 11B] Figure 11A shows an example of a code block that will be sent.

[0046] [Figure 12A]This signaling diagram illustrates an example where multiple transmitting nodes are involved in broadcast, multicast, or groupcast transmissions.

[0047] [Figure 12B] Figure 12A is a flowchart illustrating examples of methods that may be performed by the transmitting node.

[0048] [Figure 12C] Figure 12A shows an example of a code block that will be sent.

[0049] Similar reference numerals may be used in different diagrams to indicate similar components. [Modes for carrying out the invention]

[0050] The various examples described here illustrate methods and equipment for implementing HARQ-based retransmission or network coding. These examples help address the challenges of retransmitting 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 transmitting channel is typically not an erase channel.

[0051] To help you understand this disclosure, we will describe some existing approaches for retransmission.

[0052] Hybrid Automatic Retransmission Request (H-ARQ or HARQ) is a common feature of radio physical layer retransmission. A typical HARQ implementation involves the use of retransmission based on incremental redundancy (IR), where additional bits of the mothercode that were not transmitted are sent when the initial transmission fails. In other words, the mothercode is stored in a circular buffer, and after the initial code block containing bits from the mothercode is transmitted, as part of the HARQ process, the transmitter sends new IR bits from the circular buffer. The new IR bits, along with the previously transmitted data, form a new code block. This is repeated until 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 back an acknowledgment (ACK) or negative acknowledgment (NACK) 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 receiving nodes that send ACKs / NACKs. In one option, the receiving node sends only NACKs (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 dedicated PSFCH resource 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 code is a type of rateless code. Fountain code is suitable for broadcast or multicast transmissions without feedback. Traditional Multimedia Broadcast Multimedia Services (MBMS) systems used Raptor code, an implementation of fountain code, for application layer FECs without HARQ retransmission or HARQ feedback. However, fountain code is designed for feedback at higher layers of the protocol stack, rather than at lower levels (e.g., the transport block or code block level of the physical (PHY) layer). Compared to solutions that use PHY layer retransmission, fountain code has longer retransmission delays and is not suitable for low-latency applications. Furthermore, because fountain code is an erase code, its performance on non-erase channels is reduced.

[0056] Another existing approach is erase outer code. With erase outer code, a parity code block is generated based on multiple code blocks for HARQ retransmission. The parity code block can be used to modify different erase information code blocks. However, performance is degraded when transmitting over a non-erasure channel because undecoded code blocks are completely discarded. This means that each parity code block can only modify one undecoded code block.

[0057] To aid in understanding this disclosure, an example of a wireless communication system will be described first.

[0058] Figure 1 shows an example of a wireless communication system 100 (also referred to as wireless system 100) that can implement embodiments of the present disclosure. 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 generations of wireless technology. In some examples, wireless system 100 may also support some legacy wireless technologies (e.g., 3G or 4G wireless technologies).

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

[0060] An ED110 is configured to operate, communicate, or both in a wireless system 100. For example, an ED110 may be configured to transmit, receive, or both over a wireless or wired communication channel. Each ED110 represents any end-user device suitable for wireless operation, and may include (or may be referred to as) devices such as user equipment (UE), wireless transceiver units (WTRU), mobile stations, mobile relay stations, fixed or mobile subscriber units, mobile phones, stations (STA), machine-type communication (MTC) devices, personal digital assistants (PDAs), smartphones, laptops, computers, tablets, wireless sensors, Internet of Things (IoT) devices, network-enabled vehicles, or home appliances. Future generations of ED110s may be referred to using other terminology.

[0061] In Figure 1, RAN120 includes base stations (BS)170. Although Figure 1 shows each RAN120 containing a single BS170, it should be understood that any given RAN120 may contain multiple BS170s, and any given RAN120 may also contain base station controllers (BSCs), radio network controllers (RNCs), relay nodes, elements, and / or devices. Each BS170 is configured to wirelessly interface with one or more ED110s to enable access to other BS170s, the core network 130, the PSTN 140, the internet 150, and / or other networks 160. For example, a BS170 may also be called, among other possibilities, a base transceiver station (BTS), a radio base station, a node B, an evolved node B (eNodeB or eNB), a home eNodeB, a gNodeB (gNB) (sometimes called a next-generation node B), a transmission point (TP), a transmission / reception point (TRP), a site control unit, an access point (AP), or a radio router. Future generations of BS170s may be referred to using other terms. Any ED110 may be configured alternatively or additionally to interface, access, or communicate with other BS170s, the Internet 150, the core network 130, the PSTN 140, other networks 160, or any combination of the above. In some examples, a BS170 may access the core network 130 via the Internet 150.

[0062] ED110 and BS170 are examples of communication devices that can be used to implement some or all of the functions and / or embodiments described herein. Any BS170 may be a single element as shown, or multiple elements distributed across the corresponding RAN120, or not. Each BS170 transmits and / or receives radio signals within a specific geographical area or area, sometimes called a “cell” or “coverage area.” A cell can be further divided into cell sectors, and a BS170, for example, can serve multiple sectors using multiple transceivers. In some embodiments, pico or femtocells may be established with radio access technology supporting them. A macrocell may contain one or more smaller cells. In some embodiments, multiple transceivers can be used in each cell, for example, using multiple-input multiple-output (MIMO) technology. The number of RAN120 shown is illustrative only. Any number of RANs can be considered when designing the radio system 100.

[0063] The BS170 communicates with one or more ED110s via one or more uplink (UL) / downlink (DL) radio interfaces 190 (e.g., via radio frequency (RF), microwave, infrared (IR), etc.). The UL / DL interfaces 190 are sometimes referred to as UL / DL connections, ED-BS links / connections / interfaces, or ED network links / connections / interfaces. The ED110s can also communicate directly with each other (i.e., without going through the BS170) via one or more sidelink (SL) radio interfaces 195. The SL interface 195 may also be called, for example, SL connection, UE-to-UE link / connection / interface, V2V (Vehicle-to-Vehicle) link / connection / interface, V2X (Vehicle-to-Everything) link / connection / interface, V2I (Vehicle-to-Infrastructure) link / connection / interface, V2P (Vehicle-to-Pedestrian) link / connection / interface, ED-ED link / connection / interface, D2D (Device-to-Device) link / connection / interface, or simply SL. Wireless interfaces 190 and 195 can utilize any suitable wireless access technology. For example, the wireless system 100 can implement one or more channel access methods for wireless communication, 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).

[0064] RAN120 communicates with core network 130 and provides ED110 with various services such as voice, data, and other services. RAN120 and / or core network 130 may communicate directly or indirectly with one or more other RANs (not shown) which may or may not be directly serviced by core network 130 and which may or may not employ the same radio access technology. Core network 130 also functions as a gateway access between (i) RAN120 or ED110 or both, and (ii) other networks (such as PSTN140, the Internet 150, and other networks 160). Furthermore, some or all of ED110 may include the ability to communicate with different radio networks via different radio links using different radio technologies and / or protocols. Instead of radio communication (or in addition), ED110 may communicate with service providers or switches (not shown) and the Internet 150 via wired communication channels. PSTN140 may include a circuit-switched telephone network for providing plain old telephone service (POTS). Internet 150 can include networks of computers and subnets (intranets) or both, and can incorporate protocols such as Internet Protocol (IP), Transmission Control Protocol (TCP), and User Datagram Protocol (UDP). ED110 may be a multimode device capable of operating according to multiple radio access technologies and incorporates multiple transceivers necessary to support such technologies.

[0065] Figures 2 and 3 show examples of equipment that can implement the methods and teachings in accordance with this disclosure. Figures 2 and 3 show different possible embodiments for ED110 and BS170, and are not intended to limit them.

[0066] As shown in Figure 2, an example device (e.g., an exemplary embodiment of ED110 or BS170) includes at least one processing unit 201. The processing unit 201 performs various processing operations of the device. For example, the processing unit 201 can perform signal coding, data processing, power control, input / output processing, or any other function of the device. The processing unit 201 can 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, microcontroller, digital signal processor, field-programmable gate array, or application-specific integrated circuit.

[0067] The device (e.g., ED110 or BS170) 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 signals received wireless or wired. The device in this example includes at least one antenna 204 (antennas 204 may be omitted in other examples). Each antenna 204 includes any suitable structure for sending and receiving wireless or wired signals. The device may use one or more communication interfaces 202. The device may use one or more antennas 204. In some examples, one or more antennas 204 may be an antenna array 204 that can be used to perform beamforming and beam steering 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] The device (e.g., ED110 or BS170) further includes one or more input / output devices 206 or input / output interfaces (such as a wired interface to the Internet 150). The input / output devices 206 enable interaction with users or other devices in the network. Each input / output device 206 includes any configuration suitable for providing information to or receiving information from a user, including network interface communication, such as a speaker, microphone, keypad, keyboard, display, or touchscreen.

[0069] Furthermore, the device (e.g., ED110 or BS170) 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 includes any suitable volatile and / or non-volatile storage and retrieval device. Any suitable type of memory may be used, such as random access memory (RAM), read-only memory (ROM), hard disk, optical disk, subscriber identity module (SIM) card, memory stick, or secure digital (SD) memory card.

[0070] As shown in Figure 3, another example of the device (for example, another exemplary embodiment of the ED110 or BS170) 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 functions. 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, microcontroller, digital signal processor, field-programmable gate array, or 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 signals received wirelessly or wired. Although shown as separate components, at least one transmitter 252 and at least one receiver 254 can be combined to form a transceiver. Each antenna 256 includes any suitable structure for sending and receiving wireless or wired signals. Here, a common antenna 256 is shown as being coupled to both the transmitter 252 and the receiver 254, but one or more antennas 256 can be coupled to the transmitter 252 and one or more separate antennas 256 can 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 beam steering operations. Each memory 258 includes any suitable volatile and / or non-volatile storage and retrieval device as described above with respect to Figure 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 enables interaction with users or other devices in the network. Each input / output device / interface 266 includes any structure suitable for providing information to or receiving / providing information to a user.

[0073] A technique for co-encoding multiple code blocks (CBs) within a single transport block (TB), including the generation of vertical check blocks, is described in U.S. Patent Application No. 16 / 665,121, “SYSTEM AND METHOD FOR HYBRID-ARQ,” filed on 28 October 2019, which is incorporated herein by reference in its entirety.

[0074] Figure 4A shows an example of a single TB code structure including horizontal and vertical check blocks. TB402 includes multiple information blocks 404 formed from encoder input bits (four information blocks 404 are shown in this example for simplification, but this is not intended to be limiting). Encoder input bits are sometimes called information bits. The bits in this example are located in rows L and columns K. The code structure also includes horizontal check blocks 406 (one horizontal check block 406 for each information block 404 in this example) and vertical check blocks 1-4 408-1 to 408-4 (commonly referred to as vertical check blocks 408). Four vertical check blocks 408 are shown in this example for simplification, but this is not intended to be limiting. The number of vertical check blocks 408 used may depend on the transmitter configuration (e.g., BS170 for downlink (DL) transmission, ED110 for uplink (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. Each line of code contains n1 bits, including k1 encoder input bits (or information bits) (within one information block 404), and each horizontal check block 406 contains n1-k1 check bits. In this disclosure, check bits may also be called redundant bits, or in some examples (e.g., in organized code) parity bits.

[0075] Each information block 404 and its corresponding horizontal check block 406 can be viewed as an n1-bit information CB410, and TB402 has multiple information CB410s. In the example in Figure 4A, each information CB410 is an organized CB in that it contains organized bits (within the information block 404) and check bits determined from the organized bits (within the horizontal check block 406). In other examples (further described later), the information CB410 may be unorganized 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). k2 cross block bits contain M encoder input bits from each of L information CBs 410 such that k2 = M x L, where M ≥ 1. In other words, k2 cross block bits contain bits from one of K columns, each column having a bit width of M. In some examples, k2 cross block bits can contain a different number of information bits taken from each information CB 410. Mathematically, this can be expressed as k2 = M1 + ... + M L This is the result. Here, M i M is the number of information bits extracted from each of the L information CB410s. i When >0 and p≠q, M p =M q There are no such requirements.

[0077] In this disclosure, “horizontal” (as in horizontal check block 406) and “vertical” (as in vertical check block 408) refer to each other. These terms are used for convenience in understanding the layout of some figures and to distinguish the two types of check blocks from one another. However, these terms do not imply any physical structure. More generally, the descriptors “horizontal” and “vertical” may be replaced with “first” and “second,” respectively. For example, horizontal and vertical check blocks 406, 408 can simply be called 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 are sometimes called information CBs. For ease of understanding, the terms “horizontal” and “vertical” are used in place of “first” and “second,” but this is not intended to be limiting.

[0078] Figure 4B shows another example of a single TB code structure including horizontal and vertical check blocks. The example in Figure 4B is similar to the example in Figure 4A, and the similar features do not need to be elaborated upon again. In the example in Figure 4B, the code structure includes vertical check blocks 5-7 408-5 to 408-7 in addition to the aforementioned vertical check blocks 1-4 408-1 to 408-4 (vertical check blocks 1-7 480-1 to 408-7 are sometimes commonly referred to as vertical check block 408). Vertical check blocks 5-7 408-5 to 408-7 are similar to vertical check blocks 1-4 408-1 to 408-4, but differ in 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). Thus, the bits 408-5 through 408-7 in vertical check blocks 5-7 are sometimes called "check-on-check" bits.

[0079] Figures 4A and 4B illustrate the arrangement of bits in rows and columns as described above, with a vertical check block 408 shown as having a rectangular / two-dimensional structure. However, this is for illustrative purposes only and is not intended to restrict how bits are arranged logically or in transmission. Furthermore, the code structures shown in Figures 4A and 4B can be split for transmission (as will be discussed later). Typically, all bits of a single vertical check block 408 are transmitted in the same transmission.

[0080] The check bits contained in the horizontal check block 406 and the vertical check block 408 help assist in decoding at the receiver. For example, after each decoding attempt in a decoder where check bits are present, an error check can be performed to determine whether the information bits in the information CB410 were successfully decoded. The vertical check block 408 contains check bits determined across multiple information CB410s, thus providing useful information for decoding multiple information CB410s. The decoder can use the check bits in the vertical check block 408 to assist in decoding the information CB410s.

[0081] In transmission, the information CB410 (which includes the corresponding horizontal check block 406) can be transmitted in the initial transmission. As will be described later, the vertical check block 408 may be transmitted with the information CB410 in the initial transmission, or it may be transmitted in a separate transmission (sometimes called a retransmission). The retransmission may include only the unorganized coded bits from the vertical check block 408, but it may also include some organized bits (i.e., information bits) associated with the vertical check block 408.

[0082] In cases where the information CB410 is organized (such as 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. While decoding the information CB, the decoder calculates the log-likelihood ratio (LLR) of the bit values, which is considered the decoder's "soft" output. In this disclosure, the soft output may refer to a decoder output that has not yet been definitively determined (e.g., a bit value that has not yet been definitively determined to be either 1 or 0), but which may still provide useful information (e.g., in subsequent iterations of decoding). Such soft outputs may be inherently probabilistic (e.g., LLR). An information CB410 that has not been correctly decoded (e.g., fails to check using the corresponding horizontal check block 406) may benefit from processing by the vertical check block 408. Since each vertical check block 408 is generated from information bits selected from two or more (or all) of the information CB 410, a soft output from an attempt to decode a vertical check block 408 (e.g., LLR) may help improve the decoding of the information CB 410 (and vice versa). At least in this way, the vertical check block 408 helps improve decoding.

[0083] Refer to Figures 5A and 5B here. As previously mentioned, the vertical check block 408 is determined from cross-block bits selected from the entire information CB410. For a given vertical check block 408, the cross-block bits can include information bits taken from different columns of different information CB410. For example, the cross-block bits can include input bits from column x of the first information CB410, input bits from column y of the second information CB410, and input bits from column z of the third information CB410, where x, y, and z are different. Alternatively, the cross-block bits for generating the vertical check block 408 can be thought of as being selected by arbitrarily shuffling the bits in the information rows (also called row-direction shuffling) and then taking the vertical columns of bits. This row-direction shuffling of information bits is also called interleaving or row-direction 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-by-row sorting of information bits to generate different vertical check blocks 408. An interleaver is a given algorithm or a given matrix applied to rows of bits to obtain sorted rows of bits (among other possibilities). It should be understood that other techniques (not necessarily limited to interleaving) may be used.

[0084] For example, Figure 5A shows a TB402 with four information CB410, where each information CB410's information block 404 is divided into four subblocks, resulting in a total of 16 subblocks: IB1, IB2, ..., IB 16 This is shown. The consecutive indices of the subblocks shown in Figure 5A represent the natural order of the information bits of each information CB410 (for example, as output by the encoder). In the example in Figure 5A, row-direction shuffling is not performed.

[0085] In contrast, let's consider the example in Figure 5B. In this example, the information bits are shuffled in at least one row (represented in Figure 5B as the shuffled index of the subblocks). We can see that the order of the subblocks remains unchanged in the first row, but changes in the second, third, and fourth rows. In particular, specific subblocks belonging to each information CB410 remain unchanged, and only the order of the subblocks within each information CB410 is altered. This means that the shuffling does not affect the horizontal check block 406 of each information CB410. However, the vertical check block 408 in Figure 5B is different from the vertical check block 408 in Figure 5A. The vertical check block 408 in Figure 5A can be considered the first set of vertical check blocks 408, and the vertical check block 408 in Figure 5B can be considered the second set of vertical check blocks 408.

[0086] Whether shuffling is used and how the encoder input bits are shuffled within each row may be configured in the transmitter (e.g., BS170 or ED110) and / or defined by the standard. It will be understood that shuffling the information bits using different interleavers will result in different sets of vertical check blocks 408 (e.g., different first and second sets of vertical check blocks 408 in Figures 5A and 5B above). In some examples, different sets of vertical check blocks 408 may be generated from the same TB402, 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] Figures 4A, 4B, 5A, and 5B illustrate code structures based on organized code, but these are for illustrative purposes only. This disclosure is not limited to organized code and can be similarly applied to and implemented in non-organized code. Furthermore, while this disclosure describes examples of using vertical check block 408 in the context of multicast, groupcast, and broadcast transmission / retransmission, it should be understood that the code structures shown in Figures 4A, 4B, 5A, and 5B may also be suitable, in particular, for unicast transmission / retransmission.

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

[0089] TB602 contains multiple unorganized codewords 604. Each unorganized codeword 604 can be viewed as an information CB610. Unlike the examples in Figures 4A, 4B, 5A, and 5B, the information CB610 does not contain a clear horizontal check block. Each vertical check block 608 is generated by one or more bit sequences taken across multiple information CB610, similar to those described in Figures 4A and 4B.

[0090] Those skilled in the art will understand that the following detailed discussion does not depend on whether the vertical check block is generated from an organized or unorganized check block. For simplicity, the following reference numerals may be used with reference to the examples in Figures 4A and 4B, which are based on an organized check block. It should be understood that this is not intended to be limiting.

[0091] In this disclosure, vertical check blocks are sometimes called 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 called block-by-block (or block-specific) coding because the bits for generating each horizontal check block are taken from all bits of a single information block. The generation of vertical check blocks is sometimes called two-dimensional (2D) coding, where 2D represents the generation of vertical check blocks (in addition to horizontal check blocks in the case of organizational coding). The terms "parity block" or "redundancy block" may also be used instead of "check block". For ease of understanding, the following descriptions refer to vertical and horizontal check blocks, but it should be understood that the terms "vertical" and "horizontal" do not mean or limit the physical structure.

[0092] The previous explanation described a vertical check block generated from the cross-block bits of a single TB. A vertical check block can also be generated from the cross-block bits of two or more TBs (for example, TBs sent 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 networking technique that encodes and decodes transmitted data to help improve network throughput, reduce latency, and / or enhance the robustness of wireless networks. Instead of treating two packets as different, separate units of information (as in traditional network routing), network coding allows two packets to be combined (using a specific defined algebraic algorithm, such as a bitwise X-OR operation) and the accumulated message to be delivered to the destination. At the destination, the accumulated message is decoded (using the same defined algorithm). Two packets combined in this way may be from two different transmitting nodes, or from two different sources (e.g., two different antennas, two different transmitters, or two different communication interfaces). The two packets may be destined for the same destination, or for two different destinations (e.g., two different receiving nodes). If the two packets are destined for two different destinations, additional information may be used at each destination to decode and retrieve only the packet destined 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 originate from a single TB or multiple TBs).

[0095] Figure 7 shows an example of a code structure similar to those in Figures 4A and 4B. However, unlike Figures 4A and 4B, the structure in Figure 7 contains multiple TBs, which in this example are TB-1 402-1 and TB-2 402-2 (commonly referred to as TB402). Note that TB402 are not necessarily transmitted in the same transmission. In this example, two TB402s are shown for simplification, but this is not intended to be limiting. TB-1 402-1 places encoder input bits in the row that forms information block 404-1 (in this example, two information blocks 404-1 are shown for simplification, but this is not intended to be limiting), and TB-2 402-2 places encoder input bits in the row that forms information block 404-2 (in this example, two information blocks 404-2 are shown for simplification, but this is not intended to be limiting). Information blocks 404-1 and 404-2 are sometimes commonly referred to as information block 404. Note that the number of information blocks 404 in each TB402 is not necessarily equal. In this example, organized code is shown, and a horizontal check block 406 is generated from each information block 404. In an example using unorganized code, there may be no horizontal check blocks 406 that are different 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 sequences taken across all information blocks 404 (and thus across all TB402). 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 of each TB402. In this example, four vertical check blocks 408 are shown for simplification, but this is not intended to be limiting. The number of vertical check blocks 408 used may depend on the transmitter configuration (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] Similar to the above discussion relating to Figures 5A, 5B, and 6, vertical check blocks 408 generated across multiple TB402 may be generated based on their naturally ordered information bits or based on shuffled (or interleaved) bits. Multiple sets of vertical check blocks 408 may be generated for the same set of TB402 using different interleavers (for example, for different retransmissions). Vertical check blocks 408 may be generated for organized or unorganized code.

[0098] 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 transmitting chain). Generally, the term network node in this disclosure may refer to any transmitting and / or receiving node (including relay nodes) in a wireless network, and may include end nodes (e.g., terminal devices such as ED110), and further uplink nodes (e.g., BS170 or relays). Those skilled in the art will understand that other variations are possible within the scope of this disclosure.

[0099] Each TB can have a certain number of information CBs. In this disclosure, information CBs may sometimes be simply referred to as CBs. In some examples, a vertical check block may be generated using bits selected from all CBs of the 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 the TB. For example, a given interleaver may indicate a selection of bits from fewer than all CBs (e.g., a selection of bits only from CBs that were not successfully decoded by the receiving node) in order to generate a vertical check block.

[0100] This disclosure describes a method and apparatus for performing multicast, broadcast, or groupcast transmission using 2D coding. In particular, it describes retransmitting one or more vertical check blocks of multiple CBs instead of retransmitting each CB individually. Compared with existing retransmission schemes, the examples disclosed herein offer improved performance such as reduced latency, reduced overhead, or more efficient decoding.

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

[0102] Since vertical check blocks are generated using bits from multiple CBs, retransmitting one vertical check block can provide information useful for decoding multiple CBs. Receiving nodes can retain soft information from failed decoding attempts and combine it with information from vertical check blocks to aid in decoding multiple CBs. The ability to utilize soft information from unsuccessful decoding attempts provides a significant performance improvement over erase-out codes and fountain codes. This means that even if different receivers have different erroneous CBs in their initial transmission, a single vertical check block can be multicast or broadcast to different receivers and used for decoding by those different receivers.

[0103] This disclosure describes examples that may help reduce the redundancy and feedback required for retransmission in broadcast or multicast compared to conventional TB or CB group-based HARQ. The examples disclosed herein can be implemented not only in rateless code but also in feedback-based schemes.

[0104] This section describes examples of using vertical check blocks in broadcast, multicast, or groupcast transmission applications. The following examples illustrate and illustrate a specific number of participating entities (e.g., source, transmitter, destination, relay, terminal device, UE, etc.). The specific number shown is not intended to be limiting; for example, there may be any number of entities (e.g., two or more) as indicated in the plural. Although not described in detail, different interleavers can be used to generate different vertical check blocks for HARQ retransmission.

[0105] In the examples disclosed herein, retransmissions performed by a transmitter (or transmitting node) (Tx) may follow predetermined parameters. Parameters for performing retransmissions include the number of retransmissions to be performed (which may be predetermined), the interleaver used to generate each vertical check block, and the number of vertical check blocks to include in each retransmission. 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 the example where Tx is ED110, retransmission parameters may be indicated semi-statically (e.g., configured permission) or dynamically (e.g., dynamic scheduling) by configuration signaling from BS170. Semi-static configurations may be signaled using higher-layer signaling such as radio resource control (RRC) signaling. Dynamic indications may be signaled using physical layer (or Layer 1) signaling such as downlink control information (DCI) transmission.

[0106] For a receiving node to properly utilize vertical (and horizontal) checkblocks for decoding, the receiver (or receiving node) (Rx) also needs information about how the vertical checkblocks were generated. Information about the parameters used to generate the vertical checkblocks (also called vertical checkblock parameters) may be signaled to each Rx before, during, together with, or immediately after retransmission. If Tx is BS170, information about the parameters used to generate the vertical checkblocks may be signaled, for example, via DCI or RRC as described above. If Tx is ED110, information about the vertical checkblock parameters may be signaled to other receiving ED110s using sidelink RRC or PC5-RRC (for semi-statically configured parameters) or via sidelink control channel using sidelink control information (SCI) (for dynamically indicated parameters). If Tx is ED110 and transmission from Tx to Rx (which may be another ED110) is scheduled by the network (or BS170), then information regarding vertical checkblock parameters may also be signaled from BS170 to Tx, which can be semi-static (e.g., in RRC) or dynamic (e.g., in DCI). In other examples, TxED may select some or all of the vertical checkblock parameters, in which case that information does not need to be transmitted / scheduled to TxED by the network / BS170.

[0107] Information that may be signaled includes: a New Data Indicator (NDI) indicating whether the transmission is a new (initial) transmission or a retransmission; a 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 sent with each retransmission; the CB index and the number of CBs used to generate the vertical check block (optional if all CBs are used to generate the vertical check block); the interleaver used to generate the vertical check block; and which bits / subblocks of each CB are used to generate the vertical check block. In some examples, the parameters for generating the vertical check block for a given retransmission may be predefined according to a redundant version (RV) of the retransmission, in which case the signaling may indicate the RV of the retransmission. Additionally, RV sequences corresponding to multiple transmissions / retransmissions of an RV index or TB may also be signaled. Information about the interleavers used to generate vertical check blocks may be transmitted in the form of a seed (or index) of one or more interleavers within a pre-configured set of known (e.g., standard-defined) available interleavers.

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

[0109] The disclosure may refer to TB or packets in some examples. It should be understood that discussions in the context of TB may also apply to packets (and vice versa).

[0110] Figure 8A is a signaling diagram illustrating an example of using vertical check blocks in a feedback-based retransmission scheme. While Figure 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 described herein (including configuration or control signaling) may also be applicable to unicast transmissions (i.e., transmissions to a single receiving node). In Figure 8A, transmitting node 12 (denoted as Tx12) transmits to multiple receiving nodes (denoted as Rx-1 14-1, Rx-2 14-2, and Rx-3 14-3, commonly referred to as Rx14). Transmissions from Tx12 may be multicast, broadcast, or groupcast transmissions. Tx12 may be BS170 (e.g., for broadcast or multicast DL transmissions to ED110) or ED110 (e.g., for groupcast SL transmissions to other EDs). In some examples, if Tx12 is ED110, one of Rx14 may be BS170 (e.g., UL transmission) and the other Rx14 may be another ED110. Although not shown in the diagram, Tx12 may send configuration or control signals to Rx14 (e.g., before the initial transmission, before the retransmission, during the retransmission, with the retransmission, or immediately after the retransmission) to provide information about the parameters used to generate the vertical check block. Such information may be necessary for Rx14 to utilize the vertical check block that helps with decoding. For example, Tx12 may send control information containing the parameters of the vertical check block in sidelink control information (SCI). SCI may be sent on the physical sidelink control channel (PSCCH) associated with the data transmission on the physical sidelink shared channel (PSSCH), or it may be sent on the PSSCH together with the data transmission.Rx14 may first decode the SCI to obtain control information, including vertical check block parameters, and then use the obtained control information to further decode the data. Information contained in the configuration signal or control signal may include, for example, the NDI indicating whether the transmission is a new (initial) transmission or a retransmission, the HARQ process ID identifying the set of transmissions / retransmissions belonging to the same HARQ process, a predetermined number of iterations / blind retransmissions (if applicable), and parameters for generating the vertical check block. Examples of vertical check block parameters that may be signaled include: the number of vertical check blocks sent with each retransmission, the CB index and the number of CBs used to generate the vertical check block (optional if all CBs are used to generate the vertical check block), the interleaver used to generate the vertical check block, and which bits / subblocks of each CB are used to generate the vertical check block. In some examples, the parameters for generating the vertical check block for a given retransmission may be predefined according to the retransmission's RV, in which case the signaling may indicate the retransmission's RV. Additionally, RV sequences corresponding to multiple transmissions / retransmissions of an RV index or TB may also be signaled. Information about the interleavers used to generate vertical check blocks may be transmitted in the form of a seed (or index) of one or more interleavers within a pre-configured set of known (e.g., standard-defined) available interleavers.

[0111] In 802, Tx12 transmits a packet or TB containing multiple encoded CBs (including the information bits and horizontal check blocks of each CB in the case of organized codes) to all intended Rx14s. Transmission in 802 may be broadcast, multicast, or groupcast transmission. Each Rx14 attempts to decode the received packet or TB.

[0112] Each Rx14 sends back 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 sends back an ACK at 804. Rx-2 14-2 and Rx-3 14-3 fail to decode the packet or TB and send back NACKs at 806 and 808, respectively. In particular, Rx-2 14-2 and Rx-3 14-3 may fail to decode different CBs of the packet or TB. For example, as shown in Figure 8D, if the packet or TB sent by Tx12 at 802 contains CB1-9, Rx-2 14-2 may fail to decode CB2 and CB8 (indicated by CB2 and CB8 marked with an ×), while Rx-3 14-3 may fail to decode CB1, CB2 and CB6 (indicated by CB1, CB2 and CB6 marked with an ×).

[0113] Returning to Figure 8A, if at least one of the Rx14s indicates that it failed to decode the TB or packet (for example, one of the feedbacks shows a NACK), Tx12 retransmits one or more vertical code blocks at 810. (At 802) Vertical code blocks are generated from the TB or packet sent in the initial transmission and may be generated according to predetermined parameters (e.g., interleavers). In some examples, Tx12 may coordinate the retransmission at 810 to exclude Rx14s that provide ACK feedback (in this example, Rx-1 14-1), such as in the case of multicast or groupcast retransmissions. In other examples, Tx12 may send the retransmission at 810 to all Rx14s. For example, as shown in Figure 8D, the first vertical check block (VCB1) is retransmitted to all Rx14s at 810 (however, as mentioned above, multiple vertical check blocks may be retransmitted at 810). In particular, the same vertical code block is transmitted to Rx-2 14-2 and Rx-3 14-3 at 810, even though Rx-2 14-2 and Rx-3 14-3 have different undecoded CBs.

[0114] Each Rx that failed to decode the initial transmission (in this example, Rx-2 14-2 and Rx-3 14-3) uses the vertical check block received with the first received TB and soft information from the previous decoding attempt to combine them and retry decoding the undecoded CB. Rx that have 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 CB. 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 different erroneous CBs, even if they are on different Rx14s. Furthermore, a single vertical check block can also be transmitted. Because soft information from previous decoding attempts of multiple erroneous CBs is retained and available for subsequent decoding attempts, a single vertical check block can sometimes 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 CBs that were not decoded in the initial transmission, but the number can be multiple.

[0116] Returning to Figure 8A, Rx-2 14-2 and Rx-3 14-3 send back ACKs on 814 and 816, respectively. Optionally, Rx-1 14-1 may also send back another ACK on 812 to confirm successful decoding. Retransmission may end after Tx12 has received ACK feedback from all Rx14s.

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

[0118] For example, when using HARQ based on conventional TB, retransmissions require retransmitting the entire TB. This means that significant redundancy can exist. For instance, if only one CB fails to decode, only one CB in the retransmission will provide useful information, while the other CBs are redundant and waste transmission resources (e.g., time-frequency resources).

[0119] Another existing retransmission scheme is called HARQ based on code block groups (CBGs). CBG-based HARQ retransmission is similar to TB-based HARQ, but instead of retransmitting the entire TB, it divides the TB into groups of multiple CBs (called CBGs) and retransmits only the CBGs containing undecoded CBs. However, this results in significant feedback overhead because each receiving node must inform the sending node which CBs need to be retransmitted in order for the sending node to identify which CBGs to retransmit. Furthermore, if there are undecoded CBs belonging to different CBGs, multiple CBGs need to be retransmitted, which also increases redundancy. Also, in the case of broadcast / multicast / groupcast, there are multiple receiving nodes, so errors may occur in different CBGs at different receiving nodes. In this case, all CBGs indicating errors from any given receiving node need to be retransmitted. For example, in the example shown in Figure 8D, if a 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, Tx12 needs to retransmit CBG1 and CBG3 to Rx-2 14-2 (because Rx-2 14-2 failed to decode CB2 belonging to CBG1 and CB8 belonging to CBG3), and CB1 and CB2 to Rx-3 14-3 (because Rx-3 14-3 failed to decode CB1 and CB2 belonging to CBG1 and CB6 belonging to CBG2). This means that Tx12 needs to retransmit all three CBGs, and therefore the entire TB needs to be retransmitted even though it increases the feedback overhead. In such cases, it is not uncommon for this to happen with broadcast / multicast / groupcast transmissions, but CBG-based HARQ cannot offer efficiency.

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

[0121] Figure 8A is a signaling diagram showing another example of using a vertical check block 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 code. Broadcast transmissions may benefit from the ACK / NACK-less retransmission scheme because a transmitting node may broadcast to a large number of unknown receiving nodes. Figure 8B is similar to Figure 8A and includes a transmitting node 12 (denoted as Tx12) transmitting to multiple receiving nodes (commonly referred to as Rx14, denoted as Rx-1 14-1, Rx-2 14-2, and Rx-3 14-3). Transmissions from Tx12 may be multicast, broadcast, or groupcast transmissions. Tx12 may be BS170 (e.g., for a broadcast or multicast DL transmission to ED110) or ED110 (e.g., for a groupcast SL transmission to another ED). In some examples, if Tx12 is ED110, one of Rx14 may be BS170 (e.g., UL transmission) and the other Rx14 may be another ED110. Although not shown in the diagram, Tx12 may send configuration or control signals to Rx14 (e.g., before the initial transmission, before the retransmission, during the retransmission, with the retransmission, or immediately after the retransmission) to provide information about the parameters used to generate the vertical check block. Such information may be necessary for Rx14 to utilize the vertical check block that helps with decoding.

[0122] In 852, Tx12 transmits a packet or TB containing multiple encoded CBs to all intended Rx14s. Transmission in 852 may be broadcast, multicast, or groupcast transmission. Each Rx14 attempts to decode the received packet or TB.

[0123] Similar to rateless coding, there may be no PHY layer ACK / NACK feedback from Rx14 after each transmission. If the TB is successfully decoded, an optional upper-layer ACK can be sent from Rx14. In this example, Rx-1 14-1 successfully decodes the TB and optionally sends an ACK back 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 of the TB. For example, as shown in Figure 8E, if the TB transmitted by Tx12 at 852 contains CB1-9, Rx-2 14-2 may fail to decode CB2 and CB8 (indicated by CB2 and CB8 marked with an ×), while Rx-3 14-3 may fail to decode CB1, CB2 and CB6 (indicated by CB1, CB2 and CB6 marked with an ×).

[0124] Tx12 can be configured to send a predetermined number of retransmissions. Tx12 can also be configured to use predetermined parameters to generate a vertical code block for each retransmission. Tx12 may send a predetermined number of retransmissions until it receives an arbitrary upper-layer ACK from each Rx14. Alternatively, Tx12 may send a predetermined number of retransmissions regardless of feedback (or whether there is any feedback). Tx12 may send retransmissions only to Rx14 that have not sent an upper-layer ACK (for example, for multicast or groupcast retransmissions). Sending a predetermined number of retransmissions that are not triggered by feedback (or do not receive feedback between send / retransmission) is sometimes called repeated or blind retransmissions.

[0125] As shown in both Figures 8B and 8E, in this example, Tx12 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, Tx12 retransmits one or more vertical code blocks (indicated as VCB1 in Figure 8E) only to Rx-2 14-2 and Rx-3 14-3. (At 852) The vertical code blocks are generated from the TB or packets sent in the initial transmission and may be generated according to predetermined parameters (e.g., interleavers). The retransmission at 856 sends the same vertical check block to Rx-2 14-2 and Rx-3 14-3.

[0126] Each Rx that fails to decode the initial transmission (in this example, Rx-2 14-2 and Rx-3 14-3) retries to decode the undecoded CB using the vertical check block received with the first 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 an ACK with 858. Rx-3 14-3 has still not succeeded in decode the TB and does not send feedback.

[0127] Tx12 continues to send a predetermined number of retransmissions at 860 and 862. Different sets of vertical check blocks are sent at each retransmission 860 and 862 (shown as VCB2 and VCB3, respectively, in Figure 8E). For example, each set of vertical check blocks may be generated using different parameters (e.g., different interleavers). In some examples, retransmissions end after a predetermined number of retransmissions (3 retransmissions in this example) 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 Tx12 continues to send additional vertical check blocks until Tx12 receives an ACK from all Rx14. For example, if an arbitrary ACK is sent in Figures 8B and 8E, Tx12 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), Tx12 receives an ACK from Rx-3 14-3. When Tx12 receives ACKs from Rx-1 14-1 and Rx-2 14-2 (on 854 and 858) in conjunction with the ACKs it has received from all intended Rx14s, Tx12 determines that ACKs have been received from all intended Rx14s and stops transmitting any further vertical check blocks. In some examples, Tx12 may be scheduled to transmit a predetermined maximum number of retransmissions or vertical check blocks, and when this maximum number is reached, or when ACKs have been received from all intended Rx14s, it stops transmitting any further vertical check blocks.

[0128] Figure 8C is a flowchart showing an example of method 870 that may be performed by the transmitting node, following the signaling examples in Figures 8A and 8B.

[0129] At 874, Tx12 sends an initial transmission to multiple intended Rx14s (for example, in signal 802 in Figures 8A and 8B). The initial transmission may be a broadcast, groupcast, or multicast transmission. The initial transmission includes multiple informational CBs.

[0130] If necessary, 876 can receive feedback from one or more Rx14s. For example, in a feedback-based retransmission scheme, each Rx14 may need to send ACK / NACK feedback back to Tx12 (e.g., in signals 804, 806, and 808 in Figure 8A). In an ACK / NACK-less retransmission scheme, ACK feedback is optional (e.g., in signal 854 in Figure 8B), and NACK feedback may not be present.

[0131] Optionally, in step 878, Tx12 determines whether reception by at least one Rx14 has failed. Reception failure on any Rx14 means that Rx14 was unable to successfully decode at least one informational CB. In the case of a feedback-based retransmission scheme, if Tx12 receives at least one NACK in step 876, Tx12 can determine that at least one Rx14 was unable to decode the CB. In the case of an ACK / NACK-less retransmission scheme, if Tx12 does not receive ACKs from all intended Rx14s, Tx12 can determine that at least one Rx14 was unable to decode the CB. Depending on the feedback received in step 876, Tx12 may also identify which Rx14 experienced reception failure.

[0132] In some examples, such as broadcast scenarios, Tx12 may not receive feedback from any Rx14, and instead Tx12 may perform a predetermined number of retransmissions (also known as a blind retransmission scheme). In such cases, steps 876 and 878 can be omitted.

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

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

[0135] In some cases, it may not be necessary to send configuration or control signals, and step 881 may be omitted. For example, the parameters for generating the vertical check block may be predetermined (e.g., defined in a standard), and it may not be necessary to communicate from Tx12 to each Rx14.

[0136] In 882, at least one vertical check block is sent to at least one Rx14. The vertical check block may be sent to multiple Rx14s (e.g., via broadcast, multicast, or groupcast, as with the initial transmission). In some examples (e.g., signal 810 in Figure 8A), the vertical check block may be sent via broadcast, multicast, or groupcast to all Rx14s regardless of whether a given Rx14 successfully decoded the initial transmission. In other examples (e.g., signal 856 in Figure 8B), the vertical check block may be sent via multicast or groupcast only to Rx14s that were determined to have failed to decode the initial transmission (in any step 878).

[0137] If necessary (for example, up to a predetermined number of retransmissions), an optional further step can be taken to receive feedback and send subsequent retransmissions.

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

[0139] Figure 9A is a flowchart illustrating an example of a method 900 that a transmitting node can perform for multicast or groupcast communication using Mode 1 as defined in NR-V2X. The transmitting node may be a network-enabled vehicle, or more commonly, referred to as Tx. Multicast or groupcast communication is for multiple receiving nodes (commonly referred to as Rx), which may include other ED110s (e.g., other vehicles, UEs, IoT devices, peripheral sensors, etc.) and / or BS170s.

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

[0141] Optionally, in step 905, if the scheduled transmission includes the transmission of a vertical check block, Tx may provide Rx with information about the parameters for generating the vertical check block (e.g., in configuration signals or control signals such as the PC5-RRC signal or SCI transmission). Information on how the vertical check block is generated allows each Rx14 to use the vertical check block and helps decode the information CB. The configuration shown to Rx may be the same configuration previously shown to Tx by BS170. The configuration or control signals may be transmitted during, together with, or after the transmission of the vertical check block to Rx. For example, step 905 may occur during step 906.

[0142] In 906, Tx performs an initial transmission to multiple Rx (e.g., in a V2X group cast). In some examples, Tx may only send the initial transmission of data in 906, and may require further resource allocation from BS170 for retransmissions related to the same data. In other examples, 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] In step 908, Tx determines if there are any Rx that failed to receive a transmission.

[0144] For example, Tx can determine whether any Rx failed to receive its transmission based on ACK / NACK feedback from Rx. In some cases, not all Rx may be fully recognized by Tx, and each Rx can only send a NACK if it failed to receive its transmission. On 910, if Tx receives a NACK from any Rx, it reports NACK feedback to BS170. Otherwise, if Tx does not receive NACK feedback, it reports an ACK.

[0145] In another example, all Rx devices may be known to Tx. For instance, each Rx has its own dedicated PSFCH resource, and each Rx sends ACK / NACK feedback through its own dedicated PSFCH resource. In this case, on 910, if Tx receives ACK feedback from all Rx devices, it reports an ACK to BS170, and if it receives at least one NACK from an Rx device, it reports a NACK to BS170.

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

[0147] If reception is successful on all Rx (for example, no NACK is received from any Rx, or ACKs are received from all Rx), at 910, Tx reports an ACK to BS170, and method 900 terminates.

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

[0149] Optionally, in step 913, Tx may provide Rx with information about the parameters for generating a vertical check block (e.g., a configuration signal or control signal such as the PC5-RRC signal or SCI transmission). Information on how the vertical check block is generated allows each Rx14 to use the vertical check block and helps decode the information CB. The configuration shown to Rx may be the configuration optionally shown to Tx by BS170 in step 912. The configuration or control signal may be transmitted during, together with, or after the transmission of the vertical check block to Rx. For example, step 913 may occur during step 914.

[0150] In 914, Tx performs one or more retransmissions (up to a predetermined number of retransmissions permitted by the allocated resources). Retransmissions can be sent to all Rx (for example, if not all Rx are fully known to Tx), or only to Rx that failed to receive (for example, if all Rx are known to Tx).

[0151] Figure 9B is a flowchart illustrating an example of a method 950 that a transmitting node can perform for multicast or groupcast communication using Mode 2 as defined in NR-V2X. The transmitting node may be a network-enabled vehicle, or more commonly, referred to as Tx. Multicast or groupcast communication is for multiple receiving nodes (commonly referred to as Rx), which may include other ED110s (e.g., other vehicles, UEs, IoT devices, peripheral sensors, etc.) and / or BS170s.

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

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

[0154] In 954, Tx performs an initial transmission to multiple Rx (for example, in a V2X group cast). Similar to Figure 9A, in some examples, Tx may only send the initial transmission in 954, requiring additional resources for retransmissions. In other examples, Tx may select resources for a predetermined number of retransmissions (each retransmission being a set of one or more vertical check blocks).

[0155] At 956, Tx determines if there are any Rx that failed to receive the transmission.

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

[0157] In another example, Rx may be recognized by Tx. For instance, each Rx may have its own dedicated PSFCH resource, and each Rx may send ACK / NACK feedback through its own dedicated PSFCH resource. In this case, Tx may determine that reception failed if it receives any NACK from any Rx, or that transmission was successful if it receives ACK feedback from all Rx.

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

[0159] If reception is successful on all Rx (for example, no NACK is received from any Rx, or ACKs are received from all Rx), then in step 956, Tx determines that reception failed on one of the Rx, and method 950 terminates.

[0160] If it is determined in 956 that at least one Rx failed to receive, then in 958, Tx selects additional resources from the resource pool to perform one or more retransmissions. The number of retransmissions to perform and the number of vertical check blocks to send in each retransmission can be preconfigured by Tx.

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

[0162] In 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 Rx (for example, if not all Rx are fully known to Tx), or only to Rx that failed to receive (for example, if all Rx are known to Tx).

[0163] In the case of broadcast transmission, in some examples only blind retransmission (i.e., ACK / NACK-less retransmission) may be supported. In blind retransmission, Tx sends an initial transmission and a predetermined number of retransmissions (each retransmission being a set of one or more vertical check blocks). In blind retransmission, Tx may be allocated resources by BS170 (in mode 1), or it may select sufficient resources from the resource pool for the initial transmission and the predetermined number of retransmissions (in 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 descriptions, which refer to packets in some examples, may also apply to TBs. Such vertical check blocks are sometimes called cross-packet check blocks.

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

[0166] As shown in Figure 10A, Tx12 sends multiple TBs to Rx14. Each TB is sent in its own packet (in this example, packets 1, 2, and 3 are sent at 1002, 1004, and 1006, respectively). Each TB contains one or more CBs, and each TB may have a different number of CBs. The transmissions at 1002, 1004, and 1006 may be called initial transmissions of their respective packets (i.e., initial transmission of packet 1 at 1002, initial transmission of packet 2 at 1004, and initial transmission of packet 3 at 1006).

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

[0168] In the example in FIG10A, Tx12 receives no feedback after the last packet is sent at 1006. Tx12 determines that there is at least one Rx14 that failed to decode at least one of the three packets. For example, as shown in Figure 10D, Tx12 sends 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). In particular, each Rx14 may fail to decode different packets. Tx12 generates one or more vertical check blocks using crossblock bits from multiple packets. For example, a vertical check block may be generated by taking the crossblock bits from all crossblock bits across all packets 1-3, as shown by arrow 1018 in Figure 10D.

[0169] As shown in Figures 10A and 10D, at 1008, Tx12 sends a vertical check block to Rx14. Tx12 can continue generating and sending cross-packet vertical check blocks until it receives ACKs from all Rx14s. In this example, only Rx-1 14-1 successfully decodes all three packets following the first retransmission at 1008 and sends an ACK to Tx12 at 1010. Since Rx-2 14-2 and Rx-3 14-3 did not send ACKs, Tx12 performs a second retransmission. In some examples, Tx12 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 sent in separate retransmissions. The second retransmission with 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 obtaining the crossblock bits from all CBs across all packets 1-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 Tx12 at 1014 and 1016, respectively. Tx12 then stops retransmitting. In some examples, Tx12 performs retransmissions up to a predetermined maximum number of times.

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

[0171] In Figures 10B and 10E, Rx14 may provide feedback following each transmission of a packet. For example, following the transmission of packet 1 at 1052, at least one Rx14 may send at least one NACK to Tx12 at 1054 to indicate that it failed 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 return a NACK, while Rx-1 14-1 successfully decodes packet 1 and returns an ACK. Alternatively, instead of sending a NACK, an Rx14 that failed to decode packet 1 may fail to send an ACK. Tx12 uses this feedback (receiving a NACK from at least one Rx or receiving no ACKs from any Rx) to determine that there is at least one Rx14 that failed to decode packet 1.

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

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

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

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

[0176] Figure 10C is a flowchart showing an example of method 1070 that may be performed by the transmitting node, following the signaling examples in Figures 10A and 10B.

[0177] At 1074, Tx12 sends multiple initial transmissions of multiple packets to multiple intended Rx14s (for example, signals 1002-1006 in Figure 10A, or signals 1052, 1056, and 1060 in Figure 10B) (each initial transmission is the communication of each different packet). Each initial transmission may be a broadcast, groupcast, or multicast transmission. Each packet communicated in each initial transmission contains one or more informational CBs.

[0178] If necessary, feedback can be received from one or more Rx14s at 1076. For example, in a feedback-based retransmission scheme, each Rx14 may need to send ACK / NACK feedback back to Tx12 after each initial transmission, or after a expected number of initial transmissions (for example, if Rx14 knows the expected number of initial transmissions from the configuration signal or control signal). In an ACK / NACK-less retransmission scheme, ACK feedback is optional, and NACK feedback may not be present.

[0179] Optionally, in step 1078, Tx12 determines whether reception of at least one packet by at least one Rx14 failed. Reception failure at any Rx14 means that the Rx14 was unable to successfully decode the information CB of at least one packet. In the case of a feedback-based retransmission scheme, if Tx12 receives at least one NACK in step 1076, Tx12 can determine that at least one Rx14 failed to decode at least one packet. In the case of an ACK / NACK-less retransmission scheme, if Tx12 does not receive ACKs from all intended Rx14s, Tx12 can determine that at least one Rx14 failed to decode a packet. In some examples, if feedback is received after each packet is transmitted, Tx12 can also determine which packets were not successfully decoded by at least one Rx14 (it should be noted that different Rx14s may fail to decode different packets). Depending on the feedback received in step 1076, Tx12 can also identify which Rx14 experienced the reception failure.

[0180] In some examples, such as broadcast scenarios, Tx12 may not receive feedback from any Rx14, and instead Tx12 may perform the initial transmission and a predetermined number of retransmissions (also known as a blind retransmission scheme). In such cases, step 1076 can be omitted.

[0181] In step 1080, Tx12 generates one or more vertical check blocks. The vertical check block is generated using bits selected from at least two CBs of the packets sent in the initial transmission in step 1074. To generate the vertical check block, information bits belonging to at least one CB are selected from each of the at least two packets. In an example where Tx12 receives feedback indicating specific packets that it failed to decode successfully (in any step 1076), the vertical check block can be generated using only the bits from these specific packets. The generation of the vertical check block may occur at any time during method 1070 before the transmission of the vertical check block. For example, the vertical check block may be generated before the initial transmission or following any steps 1076 and 1078.

[0182] Optionally, at 1081, configuration signals or control signals (e.g., RRC signals, PC5-RRC signals, DCI transmissions, or SCI transmissions) can be transmitted by Tx12 to provide Rx14 with parameters for generating vertical check blocks. Information on how the vertical check blocks are generated allows each Rx14 to use the vertical check blocks (transmitted in retransmissions) and helps decode the information CB. The configuration signals or control signals can be used to indicate parameters for generating vertical check blocks, such as the NDI, HARQ process ID, iteration count, number of vertical check blocks transmitted, and code block partitions, 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 vertical check blocks, as described above. The configuration information may 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, together with, or after the transmission of the vertical check blocks to Rx14. For example, step 1081 may occur during step 1082.

[0183] In some cases, it may not be necessary to send configuration or control signals, and step 1081 may be omitted. For example, the parameters for generating the vertical check block may be predetermined (e.g., defined in a standard), and it may not be necessary to communicate from Tx12 to each Rx14.

[0184] In step 1082, at least one vertical check block is sent to at least one Rx14. A vertical check block may be sent to multiple Rx14s (for example, by broadcast, multicast, or groupcast, as with the initial transmission). In some examples, a vertical check block may be sent to all Rx14s by broadcast, multicast, or groupcast, regardless of whether a given Rx14 successfully decoded the initial transmission. In other examples, a vertical check block may be sent by multicast or groupcast only to Rx14s that were determined to have failed to decode the initial transmission (in any step 1078).

[0185] If necessary (for example, up to a predetermined number of retransmissions), an optional further step can be taken to receive feedback and send subsequent retransmissions.

[0186] In the example above, the transmitting node sends an informational check block (CB) in the initial transmission and a vertical check block in subsequent retransmissions. However, it is important to understand that in the example described here, at least one vertical check block may be sent along with the informational CB in the initial transmission.

[0187] The signaling performed is the same as in Figures 8A, 8B, 10A, and 10B described above, 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 signal or control signal before the initial transmission to the receiving node indicating that the vertical check block is included in the initial transmission. Subsequent retransmissions of additional vertical check blocks can be performed as needed (for example, based on a predetermined number of retransmissions or based on feedback from the receiving node), as described above.

[0188] In this example, since at least one vertical check block is sent in the initial transmission, the generation and transmission of vertical check blocks are performed by the transmitting node without any feedback from any receiving node. Therefore, in some examples, the generation of 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 cases, the number of vertical check blocks to include in an information CB during the initial transmission may be determined by the transmitting node based on channel characteristics. The transmitting node may characterize the transmitting 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 can be determined based on a trade-off between the increased overhead (due to the addition of vertical check blocks in the initial transmission) and the likelihood that any receiver (due to poor channel quality) can fully decode the information CB. 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 falls 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, for example, based on achieving the minimum probability that all receiving nodes will successfully decode the packet after the initial transmission. For example, there may be several given 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 cases, instead of using the receiving node with the worst channel quality as the criterion for determining the code rate, one might use the average channel quality of all receiving nodes, channel quality based on a specific percentage of receiving nodes, or other statistics on the channel quality of the receiving nodes. For example, if it is known that one or more receiving nodes have low channel quality (and therefore likely that redundant information will be needed to help decode the CB), 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, including not only the vertical check block but also the CB, can be multicast, groupcast, or broadcast to the intended receiving node (for example, similar to MBMS's fountain code).

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

[0192] Figure 11A is a flowchart illustrating an example of method 1100 that may be performed by a transmit node that includes a vertical check block in its initial transmit. Figure 11B shows an example of a transmit by Tx12 to Rx-1 14-1, Rx-2 14-2, and Rx-3 14-3 (commonly referred to as Rx14).

[0193] Optionally, in step 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, consequently, 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. In addition, in step 1102, the number of vertical check blocks to include in the initial transmission may be determined to be 0.

[0194] In 1104, Tx12 generates one or more vertical check blocks. The vertical check blocks are generated using bits selected from at least two of the information CBs that should be sent in the initial transmission.

[0195] Optionally, in step 1106, a configuration signal or control signal (e.g., RRC signal, PC5-RRC signal, DCI transmit, or SCI transmit) can be transmitted by Tx12 to provide Rx14 with parameters for generating vertical check blocks. Information on how the vertical check blocks are generated allows each Rx14 to use the vertical check blocks (transmitted in retransmissions) and helps decode the information CB in the initial transmit. The configuration signal or control signal can be used to indicate parameters for generating vertical check blocks, such as the NDI, HARQ process ID, iteration count, number of vertical check blocks transmitted, 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 vertical check blocks, as described above. 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 Rx14. For example, step 1106 may occur during step 1108. Configuration information may include instructions on whether and how many vertical check blocks are included with the information CB in the initial transmission.

[0196] In some cases, it may not be necessary to transmit configuration or control signals, 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 it may not be necessary to communicate from Tx12 to each Rx14.

[0197] At 1108, Tx12 sends an initial transmission to multiple intended Rx14s. The initial transmission includes an informational CB and at least one vertical check block. The initial transmission may be a broadcast, groupcast, or multicast transmission. In the example in Figure 11B, at 1152, the initial transmission includes CB1-9 and two vertical check blocks (VCB1 and VCB2).

[0198] If necessary, feedback can be received from one or more Rx14s at 1110. For example, in a feedback-based retransmission scheme, each Rx14 may need to send ACK / NACK feedback back to Tx12. In an ACK / NACK-less retransmission scheme, ACK feedback is optional, and NACK feedback may not be present. In the example in Figure 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 send a NACK back at 1154, while Rx-1 14-1 successfully decodes all CBs and sends an ACK back at 1154.

[0199] Optionally, in step 1110, Tx12 determines whether reception by at least one Rx14 failed. Reception failure on any Rx14 means that the Rx14 was unable to successfully decode the information CB. In the case of a feedback-based retransmission scheme, if Tx12 receives at least one NACK in step 1110, it can determine that at least one Rx14 was unable to decode the CB. In the case of an ACK / NACK-less retransmission scheme, if Tx12 does not receive ACKs from all intended Rx14s, it can determine that at least one Rx14 was unable to decode the CB. Depending on the feedback received in step 1110, Tx12 may also identify which Rx14 experienced the reception failure.

[0200] In some examples, such as broadcast scenarios, Tx12 may not receive feedback from any Rx14, and instead Tx12 may perform a predetermined number of retransmissions (also known as a blind retransmission scheme). In such cases, steps 1110 and 1112 can be omitted.

[0201] Optionally, in step 1114, Tx12 generates one or more additional vertical check blocks. Step 1114 may be performed if it is determined in any step 1112 that reception by at least one Rx14 has failed. Alternatively, step 1114 may be performed in a blind retransmission manner as part of a predetermined number of retransmissions. 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 signals or control signals may be sent to Rx14 to indicate the parameters used to generate the additional vertical check blocks.

[0202] Optionally, at step 1115, a configuration signal or control signal (e.g., RRC signal, PC5-RRC signal, DCI transmit, or SCI transmit) can be transmitted by Tx12, and parameters for generating an additional vertical check block can be provided to Rx14, similar to step 1106 described above. For example, step 1115 may occur during step 1116.

[0203] In some cases, it may not be necessary to send configuration or control signals for 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 it may not be necessary to communicate from Tx12 to each Rx14, or the parameters for generating additional vertical check blocks may have already been signaled in step 1106.

[0204] Optionally, at 1116, at least one additional vertical check block is sent to at least one Rx14. The additional vertical check block may be sent to multiple Rx14s (for example, by broadcast, multicast, or groupcast, as with the initial transmission). In some examples, the additional vertical check block may be sent by broadcast, multicast, or groupcast to all Rx14s regardless of whether a given Rx14 successfully decoded the initial transmission. In other examples, the additional vertical check block may be sent by multicast or groupcast only to Rx14s that were determined to have failed to decode the initial transmission (in any step 1112). In the example in Figure 11B, at 1156, one additional vertical check block (VCB3) is sent.

[0205] In some examples, additional vertical check blocks sent in any step 1116 may be from the vertical check blocks generated in step 1106 (in which case step 1114 can 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 sent in step 1116.

[0206] If necessary (for example, up to a predetermined number of retransmissions), an optional further step can be taken to receive feedback and send subsequent retransmissions. In the example in Figure 11B, ACKs are received from all Rx14 at 1158.

[0207] In the example above, the transmitting node that sent the informational check block in the initial transmission is also responsible for sending the vertical check block in the retransmission. However, in the example described here, at least one vertical check block may be sent by another assisting transmitting node. Vertical check blocks may be generated independently by different transmitting nodes without coordination. Therefore, multiple transmitting nodes can cooperate to implement a retransmission scheme together. This may be suitable for blind retransmission schemes (e.g., rateless code) where the assisting transmitting node does not require feedback from the receiving node.

[0208] Figure 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 (denoted as the first transmitting node Tx-1 12-1 and the second transmitting node Tx-2 12-2, commonly referred to as Tx12). For simplicity, Figure 12A does not show each Rx14 individually, but it is important to understand that each Tx12 transmits to multiple Rx14s. Figure 12C shows a transmission following the example in Figure 12A, with three Rx14s. Although not shown in the figure, one or both Tx12s may transmit configuration or control signals to the Rx14s (e.g., before the initial transmission, before the retransmission, with the retransmission, during the retransmission, or immediately after the retransmission) to provide information about the parameters used to generate the vertical check blocks. Such information may be necessary for the Rx14s to utilize the vertical check blocks to aid in decoding.

[0209] In the example in 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 (for example, if both Tx-1 12-1 and Tx-2 12-2 are BS170) or another wired or wireless link (for example, a sidelink if both Tx-1 12-1 and Tx-2 12-2 are ED110). In other examples, Tx-1 12-1 and Tx-2 12-2 may communicate with each other via a source-to-source link (for example, if Tx-1 12-1 and Tx-2 12-2 are different transmitting devices from the same source). In other examples, 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 an informational 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 (for example, if both Tx-1 12-1 and Tx-2 12-2 are ED110, both Tx-1 12-1 and Tx-2 12-2 can be managed by BS170), and the network entity may send an informational CB to both Tx-1 and Tx-2, and the network entity may enable Tx-2 12-2 to obtain the CB or vertical check block. In another example, Tx-2 12-2 may be a coordinating ED that provides cooperation to help Rx14 receive the informational CB. Tx-1 12-1 may be transmitting an informational CB to multiple Rx14s via transmission 1202, while Tx-1 12-1 may also be transmitting an informational CB to Tx-2 12-2 via the same transmission 1202 or via a different link.

[0210] In 1202, Tx-1 12-1 sends an informational CB to Rx14 in its initial transmission. 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 Rx14. For example, in a feedback-based retransmission scheme, each Rx14 may provide ACK or NACK feedback depending on whether it successfully decoded the initial transmission. In some examples, RX14 may provide optional ACK feedback only if it successfully decoded 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 Figure 12C, only Rx-1 14-1 successfully decodes all CBs and sends an ACK at 1204. Rx-2 14-2 and Rx-3 14-3 each fail to decode different CBs and do not send feedback at 1204.

[0212] If Tx-1 12-1 receives feedback from Rx14, Tx-1 12-1 may determine that at least one Rx14 failed to decode the initial transmission. Tx-1 12-1 may indicate to Tx-2 12-2 (e.g., via the communication link) that retransmission is required. Tx-1 12-1 may also provide Tx-2 12-2 with an informational CB to generate one or more vertical check blocks, or it may provide Tx-2 12-2 with the vertical check blocks generated by Tx-1 12-1. Tx-2 12-2 transmits a vertical check block at 1206 (shown as VCB1 in Figure 12C). The transmission at 1206 may be for all Rx14, or it may be for only the Rx14 that failed to decode the initial transmission (e.g., indicated by NACK feedback, or lack of ACK feedback from those Rx14). In the example in Figure 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 can 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 also perform one or more retransmissions. Each vertical check block transmitted by Tx-1 12-1 and Tx-2 12-2 can be generated using different interleavers.

[0215] Optionally, at 1210, Tx-1 12-1 may receive feedback from Rx14 indicating that the CB was successfully decoded. In the example in Figure 12C, all Rx14s provide ACK feedback to Tx-1 12-1. Retransmission may then be terminated. 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] Figure 12B is a flowchart showing an example of Method 1250 that may be performed by the second transmitting node Tx-2 12-2, following the signaling example in Figure 12A.

[0217] Optionally, on 1252, Tx-2 12-2 may receive configuration information (e.g., from another network entity managing Tx-1 12-1 or Tx-2 12-2) indicating the parameters used to generate vertical check blocks. This configuration information may be received via configuration signals or control signals (e.g., RRC signals, PC5-RRC signals, DCI transmissions, or SCI transmissions) or directly via a communication link. This signal can be used to indicate parameters for generating vertical check blocks, such as the NDI, HARQ process ID, iteration count, number of vertical check blocks transmitted, and code block partitions, interleaver selection, RV or RV sequence selection, coding rate, CB index used to generate the vertical check blocks, and / or other information related to the generation of vertical check blocks.

[0218] In some cases, the configuration information may already be configured in Tx-2 12-2, or the configuration information may be predetermined (for example, defined in the standard), and step 1252 may be omitted.

[0219] Optionally, Tx-2 12-2 may acquire CB at 1254 (this is sent by Tx-1 12-1 in an initial transmission, for example, in signal 1102A in Figure 12A). As mentioned above, Tx-2 12-2 can acquire CB in various ways, such as directly via the communication link between Tx-1 12-1 and Tx-2 12-2, or from another network entity (for example, from DL, UL, or SL transmissions). In some examples, configuration information and CB can be acquired simultaneously or together in the same communication.

[0220] In some cases, Tx-2 12-2 may receive configuration information and CB from Tx-1 12-1 only after Tx-1 12-1 has determined that at least one Rx14 has failed to decode the initial transmission and that retransmission is necessary. In other cases, Tx-2 12-2 may generate a vertical check block and perform retransmission independently of Tx-1 12-1.

[0221] In step 1256, one or more vertical check blocks are generated (for example, using parameters shown in any step 1252). The vertical check blocks are generated from selected information bits 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 vertical check blocks (for example, from DL, UL, or SL transmissions), and step 1256 can be omitted.

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

[0223] This disclosure provides several examples with reference to flowcharts. It should be understood that the steps described can be performed in a different order than shown and can 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 called cross-packet check blocks, cross-TB check blocks, or cross-code block check blocks, depending on the implementation, among other possibilities. Furthermore, check blocks may also be referred to as parity blocks or redundancy blocks, among other possibilities. The use of vertical check blocks is sometimes referred to as network coding based on product code.

[0225] This disclosure can be applied not only to unorganized codes (e.g., Polar codes, linear block codes, convolutional codes) but also to organized codes (e.g., LPDC codes, or Turbo codes). In other words, as described herein, vertical check blocks may be generated from encoded CBs using organized or unorganized codes.

[0226] This disclosure describes the use of vertical check blocks for HARQ retransmission in broadcast, multicast, and groupcast scenarios. The 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. A vertical check block can be generated using selected bits from all CBs. In some cases, a vertical check block can be generated using selected bits from CBs belonging to different packets.

[0228] The disclosed examples may be implemented in V2X applications or IoT applications in particular. While some examples are explained in the context of V2X, it is important to understand that the examples described here may also be applicable to other applications.

[0229] In Example 1, this disclosure is a method, The steps include sending two or more information code blocks (CBs) to multiple intended receiving nodes, A step of generating one or more crossCB check blocks, each crossCB check block being generated based on a set of crossCB bits, the set of crossCB bits including at least one bit selected from each of at least two information CBs, The steps include sending at least one of the one or more cross-CB check blocks to at least one of the intended receiving nodes, This provides a method that includes this.

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

[0231] In Example 3 of this disclosure, the method is as follows: The steps include receiving feedback indicating whether each intended receiving node has successfully decoded the two or more information CBs, After determining from the feedback that at least one of the intended receiving nodes failed to decode the two or more information CBs, the step of sending the at least one cross-CB check block, The present invention provides a method according to Example 1 or 2, which further includes the following:

[0232] Example 4 of the present disclosure provides the method of Example 3, wherein negative acknowledgment (NACK) feedback is received to indicate that each of the intended receiving nodes failed to decode the two or more information CBs.

[0233] Example 5 of the present disclosure provides a method of the present invention in which the absence of acknowledgment (ACK) feedback from each of the intended receiving nodes indicates that each of the intended receiving nodes failed to decode the two or more information CBs.

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

[0235] Example 7 of the present disclosure provides the method of Example 1 or 2, 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 sent if there is no feedback from any of the intended receiving nodes.

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

[0238] Example 10 of the present disclosure provides the method of 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 bits selected from each of the CBs of the at least two packets.

[0239] Example 11 of this disclosure includes the step of receiving feedback indicating whether at least one intended receiving node failed to decrypt at least one packet, The steps of generating one or more cross-CB check blocks based on bits selected from at least one packet that failed to decrypt, A method is provided in Example 10, which further includes the following.

[0240] Example 12 of the present disclosure provides the method of Example 11, wherein at least one of the one or more cross-CB check blocks is sent only to the at least one intended receiving node that failed to decode the two or more packets.

[0241] Example 13 of the present disclosure provides the method of Example 10, wherein at least one of the one or more cross-CB check blocks is sent if there is no 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 of Example 14, further comprising the step of determining from channel feedback received from the intended receiving node how many cross-CB check blocks should be transmitted with the two or more information CBs in the single transmission.

[0244] Example 16 of the present disclosure further includes the step of transmitting a configuration or control signal to the intended receiving node, wherein the configuration signal includes information about one or more parameters used to generate the one or more cross-CB check blocks, and the method according to any one of Examples 1 to 14 is provided.

[0245] In Example 17 of this disclosure, the configuration or control signal is as follows: Instructions for new transmission or retransmission, HARQ process identifier, Number of retransmission iterations, Number of cross-CB check blocks sent, The 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 aforementioned one or more cross-CB check blocks, or A redundant version (RV) or RV sequence showing a method for generating one or more cross-CB check blocks, A method of the action described in Example 16 is provided, which includes information relating to one or more of the following.

[0246] Example 18 of the present disclosure further includes the step of receiving a configuration or control signal, wherein the configuration or control signal includes information about one or more parameters used to generate the one or more cross-CB check blocks, and the method described in any one of Examples 1 to 17 is provided.

[0247] Example 19 of the present disclosure provides a method according to 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 of 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 other set of cross-CB bits is selected according to another predetermined interleaver.

[0249] In Example 21 of this disclosure, The steps include receiving a resource allocation from a base station that is scheduled to transmit the two or more information CBs, The steps include: receiving feedback indicating whether at least one intended receiving node failed to decode at least one of the two or more information CBs; The steps include sending a negative acknowledgment (NACK) report to the aforementioned base station, The steps include receiving an additional scaled resource allocation from the base station for transmitting the at least one cross-CB check block, A method is provided in any one of Examples 1 to 20, which further includes the following.

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

[0251] In Example 23 of this disclosure, A method is provided according to any one of Examples 1 to 20, further comprising the step of selecting a resource from a resource pool for transmitting the two or more information CBs.

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

[0253] Example 25 of this disclosure is a method, A step of receiving information for generating one or more crosscode block (CB) check blocks, each crossCB check block being generated based on a set of crossCB bits, the set of crossCB bits comprising at least one bit selected from each of at least two information CBs, The steps include sending at least one of the one or more cross-CB check blocks to multiple intended receiving nodes, A method including this is provided.

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

[0255] In Example 27 of the present disclosure, the method described in Example 25 or 26 is provided, wherein the received information includes the at least two information CBs.

[0256] In Example 28 of the present disclosure, the method described in any one of Examples 25 to 27 is provided, wherein the received information includes information regarding one or more parameters used for generating the one or more cross-CB check blocks.

[0257] In Example 29 of the present disclosure, the received information is as follows: Instruction for new transmission or retransmission, HARQ process identifier, Number of retransmission iterations, Number of transmitted cross-CB check blocks, Indices of the two or more information CBs used for generating the one or more cross-CB check blocks, An interleaver used for generating the one or more cross-CB check blocks, or A redundancy version (RV) or RV sequence indicating the method for generating the one or more cross-CB check blocks, The method described in Example 28 is provided, which includes information regarding one or more of the above.

[0258] In Example 30 of the present disclosure, the method described in any one of Examples 1 to 29 is provided, which is executed in a network-compatible vehicle.

[0259] In Example 31 of the present disclosure, the method described in any one of Examples 1 to 29 is provided, which is executed in a user equipment device.

[0260] Example 32 of this disclosure provides the method described in any one of Examples 1-20 or 25-29, which is performed at a base station.

[0261] Example 33 of this disclosure provides the method according to any one of Examples 1 to 32, wherein the CB is encoded using an organized 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 this disclosure provides the method according to any one of Examples 1 to 32, wherein the CB is encoded using an unorganized 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] Example 37 of the present disclosure provides a device including a processing unit, the processing unit being configured to execute machine-readable instructions to cause the device to perform the method described in any one of Examples 1 to 36.

[0266] Example 38 of the present disclosure provides a computer-readable medium having stored machine-executable instructions, wherein, when executed by a processing unit of a device, the instructions cause the device to perform the method described in any one of Examples 1 to 36.

[0267] This disclosure describes methods and processes having steps in a specific order, but one or more steps of a method or process may be omitted or modified as necessary. One or more steps may be performed in an order other than that described, as necessary.

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

[0269] This disclosure can be embodied in other specific forms without departing from the subject matter of the claims. The exemplary embodiments described are in all respects illustrative and not limiting. Alternative embodiments not expressly described can be created by combining features selected from one or more of the embodiments described above, and features suitable for such combinations will be understood within the scope of this disclosure.

[0270] All values ​​and sub-ranges within the disclosed scope are also disclosed. Furthermore, while the systems, apparatus, and processes disclosed and shown herein may include a certain number of elements / components, the systems, apparatus, 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 as singular, the embodiments disclosed herein can be modified to include multiple such elements / components. The subject matter described herein covers and encompasses any appropriate technical modifications.

Claims

1. It is a method, The first transmitting node transmits three or more information code blocks (CBs) to multiple intended receiving nodes, A second transmitting node generates one or more cross-CB check blocks based on received information received from the first transmitting node, wherein 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 information CBs, and the at least two information CBs are part of the three or more information CBs. The second transmitting node transmits at least one of the one or more cross-CB check blocks to at least one of the intended receiving nodes. A method that includes this.

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

3. The feedback from the intended receiving node indicates whether each intended receiving node has successfully decoded the three or more information CBs, and the method is as follows: The method according to claim 1 or 2, further comprising the step of transmitting the at least one cross-CB check block by the second transmitting node after determining from the absence of received negative acknowledgment (NACK) feedback or acknowledgment (ACK) feedback that at least one of the intended receiving nodes failed to decode the three or more information CBs.

4. The method according to claim 3, wherein negative acknowledgment (NACK) feedback is received to indicate that each of the intended receiving nodes failed to decode the three or more information CBs.

5. The method according to claim 3, wherein the absence of acknowledgment (ACK) feedback from each of the intended receiving nodes indicates that each of the intended receiving nodes failed to decode the three or more information CBs.

6. The method according to claim 3, wherein the at least one cross-CB check block is transmitted only to at least one of the intended receiving nodes that failed to decode the three or more information CBs.

7. The method according to claim 1 or 2, wherein the at least one cross-CB check block is transmitted to all of the plurality of intended receiving nodes, and the at least one cross-CB check block is transmitted if there is no feedback from any of the intended receiving nodes.

8. The method according to claim 1 or 2, wherein each set of one or more cross-CB check blocks is transmitted in each retransmission for a predetermined number of retransmissions without requiring any feedback from any of the receiving nodes intended for the initial transmission.

9. The second transmitting node further includes receiving acknowledgment (ACK) feedback from at least one intended receiving node after the initial transmission or a given retransmission, The method according to claim 1 or 2, wherein the initial transmission or the retransmission after the given retransmission is not transmitted to at least one intended receiving node that has received ACK feedback.

10. The method according to claim 1 or 2, wherein if negative acknowledgment (NACK) feedback is not received, the transmission of at least one of the one or more cross-CB check blocks to the multiple intended receiving nodes is repeated until acknowledgment (ACK) feedback is received from each of the multiple intended receiving nodes.

11. The method according to any one of claims 1 to 10, wherein the three or more information CBs are transmitted to the plurality of intended receiving nodes in at least two separately transmitted packets, and the one or more cross-CB check blocks are generated based on bits selected from each of the CBs of the at least two packets.

12. The second transmitting node receives feedback indicating whether at least one intended receiving node failed to decode at least one packet; The second transmitting node generates one or more cross-CB check blocks based on bits selected only from the at least one packet that failed to decrypt, The method according to claim 11, further comprising:

13. The method according to claim 12, wherein at least one of the one or more cross-CB check blocks is transmitted only to at least one intended receiving node that failed to decode at least one of the packets.

14. The method according to claim 11, wherein at least one of the one or more cross-CB check blocks is transmitted when there is no feedback from any of the intended receiving nodes.

15. The method according to any one of claims 1 to 10, wherein the at least one cross-CB check block is transmitted together with the three or more information CBs in a single transmission.

16. The method according to claim 15, further comprising the step of determining the number of cross-CB check blocks to be transmitted with the three or more information CBs in the single transmission from the channel feedback received from the intended receiving node.

17. The second transmitting node transmits a control signal to the intended receiving node, the control signal comprising information relating to one or more parameters used to generate the one or more cross-CB check blocks, The aforementioned control signal is as follows: Instructions for new transmission or retransmission, HARQ process identifier, Number of retransmission iterations, Number of cross-CB check blocks sent, The indices of the three or more information CBs used to generate the one or more cross CB check blocks, An interleaver used to generate the aforementioned one or more cross-CB check blocks, or A redundant version (RV) or RV sequence showing a method for generating one or more cross-CB check blocks, The method according to any one of claims 1 to 16, relating to one or more of the following.

18. The further step includes receiving a resource allocation from a base station for transmitting the three or more information CBs, The method according to any one of claims 1 to 17, wherein the resources for transmitting the at least one cross-CB check block are also allocated by the base station.

19. The steps include: receiving feedback indicating whether at least one intended receiving node has failed to decode at least one of the three or more information CBs; The steps include sending a negative acknowledgment (NACK) report to the base station, The steps include receiving an additional resource allocation from the base station for transmitting the at least one cross-CB check block, The method according to claim 18, further comprising:

20. The method according to claim 18 or 19, wherein the resource allocation from the base station also allocates resources for transmitting a predetermined number of cross-CB check blocks.

21. The further step includes selecting a resource from a resource pool for transmitting the three or more information CBs, The method according to any one of claims 1 to 17, wherein the resource for transmitting the at least one cross-CB check block is also selected from the resource pool.

22. The method according to any one of claims 1 to 21, wherein the received information includes the at least two pieces of information CB.

23. The received information includes information about one or more parameters used to generate the one or more cross-CB check blocks, The received information is as follows: Instructions for new transmission or retransmission, HARQ process identifier, Number of retransmission iterations, Number of cross-CB check blocks sent, The indices of three or more information CBs used to generate the aforementioned one or more cross CB check blocks, An interleaver used to generate the aforementioned one or more cross-CB check blocks, or A redundant version (RV) or RV sequence showing a method for generating one or more cross-CB check blocks, The method according to any one of claims 1 to 22, comprising information relating to one or more of the following.

24. The method according to any one of claims 1 to 23, wherein the first transmitting node is a network-enabled vehicle and / or the second transmitting node is another network-enabled vehicle.

25. The method according to any one of claims 1 to 23, wherein the first transmitting node is a user device and / or the second transmitting node is another user device.

26. The method according to any one of claims 1 to 17, wherein the first transmitting node is a base station and / or the second transmitting node is a network-enabled vehicle or user equipment.

27. A device including a processing unit, wherein the processing unit is configured to execute machine-readable instructions to cause the device to perform the method according to any one of claims 1 to 26.

28. A computer-readable storage medium having stored machine-executable instructions, wherein, when executed by a processing unit of a device, the instructions cause the device to perform the method according to any one of claims 1 to 26.

Images