Systems and Methods for User Equipment Cooperation with Sidelink HARQ Feedback
Methods and devices utilizing sidelink transmission between user equipment (UEs) for HARQ retransmission are provided. The sidelink HARQ retransmissions include data from the initial transmission or an outer coded version thereof. HARQ feedback from the targeted receiver of the initial transmission may identify code block groups and/or individual code blocks the target receiver did not successfully decode. A UE that has not successfully decoded an entire transport block, may still cooperate in HARQ retransmission for the targeted receiver of the transport block by retransmitting at least a subset of the code block groups that it was able to successfully decode for the transport block.
This application is a continuation of U.S. patent application Ser. No. 16/272,333, filed on Feb. 11, 2019, and entitled “Systems and Methods for User Equipment Cooperation with Sidelink HARQ Feedback,” which application is hereby incorporated herein by reference in its entirety.
TECHNICAL FIELDThe present application relates to wireless communication, and particularly to User Equipment (UE) cooperation with sidelink (SL) hybrid automatic repeat request (HARQ) feedback.
BACKGROUNDIn some wireless communication systems, user equipments (UEs) wirelessly communicate with a base station to send data to the base station and/or receive data from the base station. A wireless communication from a UE to a base station is referred to as an uplink (UL) communication. A wireless communication from a base station to a UE is referred to as a downlink (DL) communication. A wireless communication from a first UE to a second UE is referred to as a sidelink (SL) communication or device-to-device (D2D) communication.
Resources are required to perform uplink, downlink and sidelink communications. For example, a base station may wirelessly transmit data, such as a transport block (TB), to a UE in a downlink transmission at a particular frequency and over a particular duration of time. The frequency and time duration used are examples of resources.
UE cooperation has been proposed to enhance reliability, throughput and capacity. For example, UE cooperation can be used to provide diversity in space, time and frequency, and increase the robustness against fading and interference. In UE cooperation, SL communications are used to establish joint UE reception, where some of the UEs, referred to as cooperating UEs (CUEs), act as relays for other UEs, referred to as target UEs (TUEs) to improve system throughput and coverage. However, joint UE reception using SL communications can also increase the complexity of the network communications, such as for hybrid-automatic repeat request (HARQ) signaling. The HARQ mechanism is a link adaptation technique that can improve communications for erroneous data packets in wireless communication networks. However, current implementations of HARQ do not efficiently exploit the SL communication capabilities of UE cooperation. Therefore, there is a need for efficient schemes that leverage UE cooperation and SL communications with the HARQ mechanism.
SUMMARYAccording to a first aspect, the present disclosure provides a method for user equipment (UE) cooperation. The method includes receiving, at a first UE, a transport block intended for a second UE, the transport block comprising a plurality of code block groups, each code block group comprising a plurality of code blocks. The method further includes transmitting, from the first UE to the second UE, at least one code block based on at least one code block group of the transport block intended for the second UE, the at least one code block group including less than all code block groups of the transport block.
In some embodiments of the method according to the first aspect of the present disclosure, transmitting at least one code block based on the at least one code block group of the transport block intended for the second UE comprises transmitting at least one outer coded code block based on less than all code block groups of the transport block.
In some embodiments of the method according to the first aspect of the present disclosure, outer coding used to generate the at least one outer coded code block comprises one of: raptor coding, Reed Solomon (RS) coding, parity check coding, and erasure coding.
In some embodiments of the method according to the first aspect of the present disclosure, transmitting at least one outer coded code block based on less than all code block groups of the transport block comprises transmitting at least one outer coded code block based on the content of each code block group among the less than all code block groups of the transport block.
In some embodiments of the method according to the first aspect of the present disclosure, the method further includes receiving, at the first UE, a feedback message from the second UE including information identifying at least one code block group the second UE failed to decode for the transport block. In such embodiments, the at least one code block group upon which the at least one code block transmitted from the first UE is based may be selected from among the plurality of code block groups of the transport block based at least in part on the feedback message from the second UE.
In some embodiments of the method according to the first aspect of the present disclosure, transmitting the at least one outer coded code block includes generating, for each code block group of the transport block, an outer coded code block based on contents of the code block group, and transmitting the outer coded versions of the code block groups to the second UE.
In some embodiments of the method according to the first aspect of the present disclosure, the method further includes receiving, at the first UE, a feedback message from the second UE. The feedback message may include information identifying at least one code block group the second UE failed to decode for the transport block, and information indicating, for each code block group the second UE failed to decode, a quantity of code blocks the second UE failed to decode for the code block group. In such embodiments, transmitting at least one outer coded code block to the second UE may include transmitting, for each of at least one code block group the second UE failed to decode, a quantity of outer coded code blocks for the code block group based on the feedback information.
In some embodiments of the method according to the first aspect of the present disclosure, the method further includes receiving, at the first UE, scheduling information from a base station. In such embodiments, the at least one code block transmitted from the first UE may include at least one code block group selected from among the plurality of code block groups of the transport block based at least in part on the scheduling information from the base station.
In some embodiments of the method according to the first aspect of the present disclosure, the at least one code block transmitted from the first UE includes at least one code block group of the transport block. In such embodiments, the method may further include transmitting, from the first UE in sidelink control information (SCI) in a sidelink control channel, information identifying the index of each code block group of the at least one code block group transmitted from the first UE among all the code block groups of the transport block.
In some embodiments of the method according to the first aspect of the present disclosure, the method further includes transmitting, from the first UE in sidelink control information (SCI) in a sidelink control channel, at least one of the following: information identifying the index of each code block group of the transport block upon which the at least one outer coded code block is based; information identifying the number of outer coded code blocks transmitted for each code block group; and information identifying parameters to generate each outer coded code block for each code block group.
According to a second aspect, the present disclosure provides a user equipment (UE). The UE includes one or more processors and a non-transitory computer readable storage medium storing programming for execution by the one or more processors. The programming includes instructions to: receive a transport block intended for a second UE, the transport block comprising a plurality of code block groups, each code block group comprising a plurality of code blocks; and transmit, to the second UE, at least one code block based on at least one code block group of the transport block intended for the second UE, the at least one code block group including less than all code block groups of the transport block.
In some embodiments of the UE according to the second aspect of the present disclosure, the instructions to transmit at least one code block based on the at least one code block group of the transport block intended for the second UE comprise instructions to transmit at least one outer coded code block based on less than all code block groups of the transport block.
In some embodiments of the UE according to the second aspect of the present disclosure, outer coding used to generate the at least one outer coded code block includes one of: raptor coding, Reed Solomon (RS) coding, parity check coding, and erasure coding.
In some embodiments of the UE according to the second aspect of the present disclosure, the instructions to transmit at least one outer coded code block based on less than all code block groups of the transport block include instructions to transmit at least one outer coded code block based on the content of each code block group among the less than all code block groups of the transport block.
In some embodiments of the UE according to the second aspect of the present disclosure, the programming further includes instructions to receive a feedback message from the second UE including information identifying at least one code block group the second UE failed to decode for the transport block. In such embodiments, the at least one code block group upon which the at least one code block transmitted to the second UE is based is selected from among the plurality of code block groups of the transport block based at least in part on the feedback message from the second UE.
In some embodiments of the UE according to the second aspect of the present disclosure, the instructions to transmit the at least one outer coded code block based on less than all code block groups of the transport block includes instructions to: generate, for each code block group of the transport block, an outer coded code block based on contents of the code block group; and transmit the outer coded versions of the code block groups to the second UE.
In some embodiments of the UE according to the second aspect of the present disclosure, the programming further includes instructions to receive a feedback message from the second UE that includes: information identifying at least one code block group the second UE failed to decode for the transport block; and information indicating, for each code block group the second UE failed to decode, a quantity of code blocks the second UE failed to decode for the code block group. In such embodiments, the instructions to transmit at least one outer coded code block to the second UE may include instructions to transmit, for each of at least one code block group the second UE failed to decode, a quantity of outer coded code blocks for the code block group based on the feedback information.
In some embodiments of the UE according to the second aspect of the present disclosure, the programming further includes instructions to receive scheduling information from a base station. In such embodiments, the instructions to transmit at least one code block based on at least one code block group of the transport block may include instructions to transmit at least one code block group selected from among the plurality of code block groups of the transport block based at least in part on the scheduling information from the base station.
In some embodiments of the UE according to the second aspect of the present disclosure, the instructions to transmit at least one code block based on at least one code block group of the transport block include instructions to transmit at least one code block group of the transport block. In such embodiments, the programming may further include instructions to transmit, in sidelink control information (SCI) in a sidelink control channel, information identifying the index of each code block group of the at least one code block group among all the code block groups of the transport block.
In some embodiments of the UE according to the second aspect of the present disclosure, the programming further includes instructions to transmit, in sidelink control information (SCI) in a sidelink control channel, at least one of the following: information identifying the index of each code block group of the transport block upon which the at least one outer coded code block is based; information identifying the number of outer coded code blocks transmitted for each code block group; and information identifying parameters to generate each outer coded code block for each code block group.
Embodiments will be described, by way of example only, with reference to the accompanying figures wherein:
As noted above, resources are required to perform uplink, downlink and sidelink communications. For example, a base station may wirelessly transmit data, such as a transport block (TB), to a UE in a downlink transmission at a particular frequency and over a particular duration of time. The frequency and time duration used are examples of resources.
Channel coding, such as forward error-correction (FEC) coding or error-correction coding, introduces redundancy into the data prior to transmission. The receiving system exploits the redundancy to detect and possibly correct errors introduced during transmission, e.g. errors introduced by the channel, the receiver, the transmitter, a storage medium, etc. For example, in a communication system that employs FEC coding, a source provides data to an encoder, which is also referred to as a coder. The encoder encodes the data to generate a longer sequence of coded bits called a “codeword”. The coded bits include redundancy, which may be in the form of parity bits. Codewords are transmitted to a receiver. The receiver uses a suitable decoder to try to extract the original unencoded data. The decoder may also correct errors, which may have been caused during transmission of the codeword, e.g. because of a noisy channel.
Channel coding can thus be used to detect and/or correct errors, which may reduce the need for the transmitter to retransmit data that was corrupted during transmission. By reducing the need to retransmit data, the throughput of the channel or link may be improved.
In some systems, a TB is divided into several FEC blocks, and the FEC blocks are scheduled for transmission by a scheduler. However, if a TB transmission fails, e.g. if the decode output does not pass cyclic redundancy check (CRC), then the redundant versions of all the FEC blocks in the TB are retransmitted, even though some of the FEC blocks may have been correctly received. That is, HARQ retransmission is TB based in such systems. The retransmission may use the same or a different redundancy version (RV) of the TB. Soft combining of the different transmissions of the TB is used. To manage complexity, each UE may have a limited number of HARQ processes, e.g. eight HARQ processes.
In some systems, code block group (CBG) based retransmission is supported for downlink communications. A CBG refers to a group of code blocks (CBs). A possible benefit of CBG based retransmission compared to TB based retransmission is that in CBG based retransmission one or multiple CBGs may be retransmitted instead of the whole TB. Soft combining of different transmissions of a CBG may be performed. However, for CBG based retransmission, the receiving UE needs to feedback a CBG index that indicates which CBGs failed. The CBG index increases the overhead of the HARQ feedback.
Furthermore, depending upon the application, soft combining based HARQ might not work well. As one example, some systems support multiplexing of different traffic types, including pre-empting scheduled enhanced mobile broadband (eMBB) traffic when more urgent ultra-reliable low latency communications (URLLC) traffic arrives for transmission. The FEC block or CBG corresponding to the pre-empted traffic might not be known to the decoder, in which case the receiver may be attempting to soft-combine a transmission containing different information intended for a different receiver. As a result, HARQ combining based on soft combining might not work or may have worse performance than not performing soft combining on the pre-empted traffic.
SL transmission between UEs may be utilized for HARQ retransmissions in a two level HARQ scheme. For example, such a two level HARQ scheme may have two phases, a first DL multicast phase and a second SL cooperation phase. In the first phase, a BS or evolved NodeB (eNB) broadcasts data to both CUE(s) and TUE. In the second phase, the CUE(s) send a retransmission of the data that they received in the first phase to the TUE. If the TUE successfully received the data, the TUE may send an acknowledgement (ACK) to the BS and the CUE(s). After the initial broadcast transmission of the data in the first phase, the BS may choose to resend the data if it does not receive an ACK before a time period T0 elapses.
However, a CUE might not always be able to decode an entire data block it received from the BS. In conventional UE cooperation solutions that utilize a TB based HARQ retransmission scheme, a CUE that does not fully decode the data block cannot cooperate and help the transmission for the TUE.
Aspects of the present disclosure improve the communication technology by addressing at least one of the disadvantages outlined above.
Vehicle to everything (V2X) refers to a category of communications scenarios (along with their corresponding technical challenges), including communication between a vehicle and another vehicle (V2V), vehicle to infrastructure (V2I), vehicle to pedestrian (V2P), and many other scenarios. In V2X, the transmission can be done through a link between network and UE, such as uplink and downlink or a sidelink between UE and UE. UE cooperation can be used to enhance the reliability, throughput, and capacity of V2X communications, as well as next generation wireless communications in general.
In LTE, a conventional V2X transmission scheme relies on the concept of a transmit resource pool (RP). The conventional LTE V2X transmission scheme includes two transmission modes: mode 3 and mode 4. In mode 3, BS schedules time-frequency resources (from the UE's RP) for SL transmission using DCI, either dynamically or semi-persistently. In mode 4, UE randomly selects resources within its transmit RP. UE may also reselect resources based on previous measurement and sensing results.
The conventional resource pool approach has downsides and limitations, which are addressed by the present invention. For example, the scheduling in mode 3 results in scheduling-related limitations, such as latency and having the SL transmission rely on DCI. For another example, when the UE autonomously selects resources in mode 4, there can be a collision or conflict with the same resource being selected by another UE.
Aspects of the present disclosure provide different UE cooperating schemes based on different HARQ feedback. Broadly speaking, UE cooperating schemes in accordance with aspects of the present disclosure can be grouped into two different categories. The first category is CBG or CB level cooperation without outer coding. In this first category, a CUE retransmits, via SL transmission, one or more CBGs or CBs it received from the first DL multicast phase. These transmissions can be done according to the SL HARQ feedback. The second category is outer code based, where CUE may transmit data using an outer code applied to the data block or selected CBGs of the data received from the from the first DL multicast phase. Similar to the first category, in the second category, how a CUE cooperates may depend on the SL HARQ feedback. Both categories can potentially enable distributed UE cooperation, whereby CUEs can cooperate without base station scheduling. For example, CUEs can make decisions on how to cooperate based on SL HARQ feedback. In addition, CUE can cooperate even without fully decoding the data block intended for the TUE. In addition, the UE cooperation schemes with sidelink HARQ feedback can potentially significantly reduce the resources used for SL transmission and improve UE cooperation efficiency.
According to an aspect of the present disclosure, rather than retransmitting an entire transport block during the SL cooperation phase, a CUE may transmit at least one code block based on less than all code block groups of the transport block during the SL cooperation phase. For example, an aspect of the present disclosure enables a CUE that has successfully decoded less than all code block groups of a transport block received during the multicast phase to still cooperate during the SL cooperation phase by transmitting at least one code block to the TUE that is based on at least one code block group from the partial subset of code block group the CUE was able to successfully decode.
For illustrative purposes, specific example embodiments will now be explained in greater detail below in conjunction with the figures. Before discussing detailed embodiments of aspects of the present disclosure, examples of communication systems and devices in which such aspects might be implemented will first be discussed.
Example Communication Systems and DevicesIn this example, the communication system 100 includes electronic devices (ED) 110a-110c, radio access networks (RANs) 120a-120b, a core network 130, a public switched telephone network (PSTN) 140, the internet 150, and other networks 160. Although certain numbers of these components or elements are shown in
The EDs 110a-110c are configured to operate, communicate, or both, in the communication system 100. For example, the EDs 110a-110c are configured to transmit, receive, or both via wireless or wired communication channels. Each ED 110a-110c represents any suitable end user device for wireless operation and may include such devices (or may be referred to) as a user equipment/device (UE), wireless transmit/receive unit (WTRU), mobile station, fixed or mobile subscriber unit, cellular telephone, station (STA), machine type communication (MTC) device, personal digital assistant (PDA), smartphone, laptop, computer, tablet, wireless sensor, or consumer electronics device.
In
The EDs 110a-110c and base stations 170a-170b are examples of communication equipment that can be configured to implement some or all of the functionality and/or embodiments described herein. In the embodiment shown in
The base stations 170a-170b communicate with one or more of the EDs 110a-110c over one or more air interfaces 190 using wireless communication links e.g. radio frequency (RF), microwave, infrared (IR), etc. The air interfaces 190 may utilize any suitable radio access technology. For example, the communication system 100 may implement one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), or single-carrier FDMA (SC-FDMA) in the air interfaces 190.
A base station 170a-170b may implement Universal Mobile Telecommunication System (UMTS) Terrestrial Radio Access (UTRA) to establish an air interface 190 using wideband CDMA (WCDMA). In doing so, the base station 170a-170b may implement protocols such as HSPA, HSPA+ optionally including HSDPA, HSUPA or both. Alternatively, a base station 170a-170b may establish an air interface 190 with Evolved UTMS Terrestrial Radio Access (E-UTRA) using LTE, LTE-A, and/or LTE-B. It is contemplated that the communication system 100 may use multiple channel access functionality, including such schemes as described above. Other radio technologies for implementing air interfaces include IEEE 802.11, 802.15, 802.16, CDMA2000, CDMA2000 1×, CDMA2000 EV-DO, IS-2000, IS-95, IS-856, GSM, EDGE, and GERAN. Other multiple access schemes and wireless protocols may be utilized.
The RANs 120a-120b are in communication with the core network 130 to provide the EDs 110a-110c with various services such as voice, data, and other services. The RANs 120a-120b and/or the core network 130 may be in direct or indirect communication with one or more other RANs (not shown), which may or may not be directly served by core network 130, and may or may not employ the same radio access technology as RAN 120a, RAN 120b or both. The core network 130 may also serve as a gateway access between (i) the RANs 120a-120b or EDs 110a-110c or both, and (ii) other networks (such as the PSTN 140, the internet 150, and the other networks 160).
The EDs 110a-110c communicate with one another over one or more SL air interfaces 180 using wireless communication links e.g. radio frequency (RF), microwave, infrared (IR), etc. The SL air interfaces 180 may utilize any suitable radio access technology, and may be substantially similar to the air interfaces 190 over which the EDs 110a-110c communication with one or more of the base stations 170a-170c, or they may be substantially different. For example, the communication system 100 may implement one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), or single-carrier FDMA (SC-FDMA) in the SL air interfaces 180. In some embodiments, the SL air interfaces 180 may be, at least in part, implemented over unlicensed spectrum.
In addition, some or all of the EDs 110a-110c may include functionality for communicating with different wireless networks over different wireless links using different wireless technologies and/or protocols. Instead of wireless communication (or in addition thereto), the EDs may communicate via wired communication channels to a service provider or switch (not shown), and to the internet 150. PSTN 140 may include circuit switched telephone networks for providing plain old telephone service (POTS). Internet 150 may include a network of computers and subnets (intranets) or both, and incorporate protocols, such as IP, TCP, UDP. EDs 110a-110c may be multimode devices capable of operation according to multiple radio access technologies, and incorporate multiple transceivers necessary to support such.
As shown in
The UE 110 also includes at least one transceiver 202. The transceiver 202 is configured to modulate data or other content for transmission by at least one antenna 204 or Network Interface Controller (NIC). The transceiver 202 is also configured to demodulate data or other content received by the at least one antenna 204. Each transceiver 202 includes any suitable structure for generating signals for wireless or wired transmission and/or processing signals received wirelessly or by wire. Each antenna 204 includes any suitable structure for transmitting and/or receiving wireless or wired signals. One or multiple transceivers 202 could be used in the UE 110. One or multiple antennas 204 could be used in the UE 110. Although shown as a single functional unit, a transceiver 202 could also be implemented using at least one transmitter and at least one separate receiver.
The UE 110 further includes one or more input/output devices 206 or interfaces (such as a wired interface to the internet 150). The input/output devices 206 permit interaction with a user or other devices in the network. Each input/output device 206 includes any suitable structure for providing information to or receiving information from a user, such as a speaker, microphone, keypad, keyboard, display, or touch screen, including network interface communications.
In addition, the UE 110 includes at least one memory 208. The memory 208 stores instructions and data used, generated, or collected by the UE 110. For example, the memory 208 could store software instructions or modules configured to implement some or all of the functionality and/or embodiments described herein and that are executed by the processing unit(s) 200. Each memory 208 includes any suitable volatile and/or non-volatile storage and retrieval device(s). Any suitable type of memory may be used, such as random access memory (RAM), read only memory (ROM), hard disk, optical disc, subscriber identity module (SIM) card, memory stick, secure digital (SD) memory card, and the like.
As shown in
Each transmitter 252 includes any suitable structure for generating signals for wireless or wired transmission to one or more UEs or other devices. Each receiver 254 includes any suitable structure for processing signals received wirelessly or by wire from one or more UEs or other devices. Although shown as separate components, at least one transmitter 252 and at least one receiver 254 could be combined into a transceiver. Each antenna 256 includes any suitable structure for transmitting and/or receiving wireless or wired signals. Although a common antenna 256 is shown here as being coupled to both the transmitter 252 and the receiver 254, one or more antennas 256 could be coupled to the transmitter(s) 252, and one or more separate antennas 256 could be coupled to the receiver(s) 254. Each memory 258 includes any suitable volatile and/or non-volatile storage and retrieval device(s) such as those described above in connection to the UE 110. The memory 258 stores instructions and data used, generated, or collected by the base station 170. For example, the memory 258 could store software instructions or modules configured to implement some or all of the functionality and/or embodiments described above and that are executed by the processing unit(s) 250.
Each input/output device 266 permits interaction with a user or other devices in the network. Each input/output device 266 includes any suitable structure for providing information to or receiving/providing information from a user, including network interface communications.
Additional details regarding the UEs 110 and the base stations 170 are known to those of skill in the art. As such, these details are omitted here for clarity.
The following section describes examples of different UE cooperation procedures that aspects of the present disclosure may be applied to, and different kinds of SL HARQ feedback are also discussed. After that, several examples of UE cooperation schemes in accordance with the present disclosure are provided. The examples include a first group of examples in accordance with the first category of UE cooperation described above, in which a CUE retransmits selected CBGs or CBs among the data block or TB the CUE received during the first multicast phase, based on different HARQ feedback schemes. The examples also include a second group in accordance with the second category of UE cooperation described above, in which a CUE retransmits an outer coded version of the TB or selected CBGs thereof based on different HARQ feedback schemes.
UE Cooperation ProcedureAs shown in
In the example method shown in
Referring now to
Turning now to
Referring again to
Aspects of the present disclosure provide cooperative transmission schemes that allow cooperating UE to cooperate more intelligently and efficiently, rather than simply retransmitting whole transport blocks.
An aspect of the present disclosure relates to a cooperative transmission scheme in which data starts from a first network device, such as a BS or a UE, and is transmitted to a UE that is the target receiver. For simplicity, many of the following examples of cooperative transmission schemes in accordance with the present disclosure are described in the context of cooperative transmission scenarios in which the original transmitter is a BS (or eNB), the target receiver is a UE (or multiple UEs), and some other UE (or UEs) serves as the helper or cooperating device. The receiver UE may be referred to as the target UE (TUE) and the helper or cooperating UE may be referred to as a cooperating UE (CUE). However, embodiments of the cooperative transmission schemes in accordance with the present disclosure are not limited to cooperative transmission scenarios where the original transmission is a DL transmission from a BS. For example, as discussed in further detail below, in some embodiments the cooperative transmission schemes of the present disclosure are applied to SL cooperation transmission scenarios in which the original transmitter is also a UE. In such scenarios, the original transmitter UE may be referred to as a Leader UE (LUE).
If the CUE (UE1) does not receive an ACK of the data block, the CUE can participate in the cooperation phase 411 by resending at least a portion of the data packet that the CUE successfully received from the BS in the first phase 401 through SL transmission to the TUE, as indicated at 406. For example, the SL transmission from UE1 to UE2 at 406 may include at least one code block based on at least one code block group of a transport block in the DL multicast intended for UE2, the at least one code block group including less than all code block groups of the transport block. After retransmission at 406, the TUE may again send HARQ feedback to CUE and/or the BS. For example, in
In this example, UE0 is the LUE, and in the first SL multicast phase 441 UE0 multicasts data that includes a first transport block TB1 to the other three UEs as indicated at 440. In this scenario, the data multicast by UE0 at 440 is intended for UE3. In the SL multicast phase 451, UE3 may optionally send HARQ feedback to UE0, UE1 and UE2, as indicated at 442. If the CUEs, e.g., UE1 and UE2 in this scenario, do not receive an ACK of the data block TB1, the CUEs can participate in the cooperation phase 451 by resending at least a portion of the data block that they successfully received from the LUE in the first SL multicast phase 441 through SL transmission to UE3 as well as to each other, as indicated at 444. Although not shown in
In the foregoing examples, SL transmission between UEs are utilized for HARQ retransmissions of downlink transmissions or sidelink transmissions. In some embodiments, SL transmission between UEs may be utilized to help with HARQ retransmissions of uplink transmissions, i.e., for transmissions from a UE to a BS. In such embodiments, the initial transmitter is a UE, the targeted receiver is the BS, and one or more other UEs act as CUEs to help with transmission from the transmitter UE to the BS. In the first multicast phase, the transmitter UE sends the data to the BS and the CUEs using UL transmission and SL transmission, respectively. In the second cooperation phase, the CUE retransmits the UL transmission to the BS. All the UE cooperation methodologies described in this disclosure can be applicable to this UL transmission scenario as well.
Sidelink HARQ FeedbackThere may be different types of HARQ feedback that a TUE may send to CUEs, the LUE and/or a BS. Based on these different types of feedback, CUEs may choose different cooperation schemes for the SL retransmission in the cooperation phase. For example, instead of sending a simple ACK/NACK for an entire TB, SL HARQ feedback that is sent in accordance with the present disclosure may include CBG level feedback information or CB level feedback information for more efficient SL retransmission. This section of the present disclosure describes several types of HARQ feedback that may be employed in embodiments of the present disclosure. A detailed description of the various feedback options and embodiments of cooperative transmission schemes based on the various feedback options are described in more detail in the next section.
In one scenario, a TUE does not send SL HARQ feedback. In such a scenario where there is no SL HARQ feedback, a CUE may choose to cooperate in the cooperation phase by sending a predefined number of retransmissions.
In scenarios where some form of SL HARQ feedback is sent, there are a number of options for the form and content of the feedback. Four example types of SL HARQ feedback are outlined below. These four types of SL HARQ feedback are referred to herein as Types 1 to 4.
Type 1 HARQ feedback is a simple ACK/NACK feedback, which indicates whether the whole data block (or TB) is decoded successfully or not.
Type 2 feedback includes information indicating which CBGs or CBs of a TB are decoded successfully. An example of Type 2 HARQ feedback that provides CBG level feedback is a CBG ACK/NACK bit map, in which each bit represents whether a corresponding CBG is decoded successfully or not. For example, if there are m CBGs per TB, such feedback may utilize a bit map with at least m bits. Similarly, a CB level ACK/NACK bit map can be applied to provide CB level feedback.
Type 3 HARQ feedback includes information indicating how many CBs (or CBGs) of a TB are decoded successfully, but it does not include information identifying the CB(s)/CBG(s) that are successfully decoded or that failed decoding. For example, Type 3 HARQ feedback may include information indicating that N CBGs of a TB that includes m CBGs, N≤m, failed to decode successfully, but does not include information indicating the specific CBG indexes of the failed CBGs. If a TB contains p CBs, such feedback requires log2 p bits, which is less than the number of bits that would be required for Type 2 CB level feedback that includes information identifying the CB index of the CBs for which decoding succeeded or failed.
Type 4 HARQ feedback can be considered a hybrid of Type 2 and Type 3 feedback, in that it combines features of the two. In one form of Type 4 feedback, the feedback includes information identifying the number of non-successfully decoded CBs in each CBG of a TB. In another form of such feedback, the feedback includes information indicating, for each CBG of a TB, whether the CBG is decoded successfully (similar to Type 2 feedback), and the maximum number of CBs that are not decoded in any CBG of the TB. This type of feedback requires less overhead, in terms of bits required to convey the feedback information, than indicating the number of non-successfully decoded CBs for all CBGs of the TB.
As noted above, aspects of the present disclosure provide different UE cooperating schemes that, broadly speaking, fall into one of two different categories and are based on different HARQ feedback types, such as the various HARQ feedback types described above. The first category is CBG or CB based UE cooperation without outer coding, and the second category is outer code based, where CUE may transmit data using an outer code applied to the data block or selected CBGs of the data received from the from the first multicast phase.
The next section of the present disclosure describes aspects and considerations related to the first category of UE cooperating schemes in accordance with the present disclosure. The subsequent section then provides a similarly detailed description of the second category.
CBG/CB Based UE CooperationIn the first category, CUEs in the cooperation phase send a selected number of CBGs or CBs to the TUE. The CBGs or CBs that the CUE sends to the TUE may be only a portion of the TB that the CUE received from the original transmitter in the first phase. Which CBGs/CBs the CUE sends to the TUE via SL retransmission may depend on HARQ feedback from the TUE and/or which CB/CBGs are successfully decoded by the CUE in the first phase.
For example, if the HARQ feedback sent by the TUE is the Type 2 HARQ feedback described above, which indicates which CBGs/CBs of the TB transmitted by the original transmitter have been successfully decoded by the TUE, the CUE may cooperate in one of the following ways:
If the CUE has successfully decoded all of the CBs of the TB, the CUE may retransmit all the CBGs/CBs that the TUE has not successfully decoded based on the HARQ feedback from the TUE.
If the CUE does not successfully decode all of the CBs of the TB, the CUE may still cooperate by sending the CBGs/CBs the CUE successfully decoded among the CBGs/CBs that the TUE has not successfully decoded based on the HARQ feedback from the TUE.
If the CUE does not successfully decode any CBG/CB that the TUE has not decoded successfully based on the HARQ feedback, the CUE does not cooperate.
In this first category of UE cooperative transmission schemes in accordance with the present disclosure, when a CUE retransmits the CBGs/CBs via SL transmission, the CUE may use the same redundancy version (RV) or a different RV. In the SL transmission, the CUE may also send SL control information (SCI) in a SL control channel so that the TUE can determine:
i)) which CUE is transmitting the message;
ii) which UE (the TUE) is targeted as the destination of the message; and
iii) the resource and parameters to be used for the SL transmission.
For example, the SCI may include information indicating an identifier (ID) associated with the CUE, an ID associated with the TUE, and information that can be used by the TUE to determine the resource and parameters to be used for the SL transmission. When CBG/CB level retransmission is used, the SCI sent by the CUE in the SL control channel may also include the CBG or CB index of the CBG(s) or CB(s) that the CUE retransmits. That way, when the TUE decodes the SCI, it knows which CBGs/CBs are sent by the CUE, which may facilitate the TUE's decoding process for the SL retransmission from the CUE.
The transport block TB1 transmitted in the first phase 501 contains 9 CBs, identified as CB1 to CB9, respectively. The nine CBs of TB1 are grouped into three CBGs, identified as CBG1, CBG2 and CBG3, respectively, such that CBG1 includes CB1, CB2 and CB3; CBG2 includes CB4, CB5 and CB6; and CBG3 includes CB7, CB8 and CB9.
In this example, CUE1 successfully decoded all the CBs in the data block TB1. CUE2 successfully decoded all CBs in TB1 except CB2, which belongs to CBG1. The TUE successfully decoded all CBs in TB1 except CB1 and CB2 of CBG1 and CB6 of CBG2.
After the first transmission, the TUE sends HARQ feedback (e.g., Type 2 HARQ feedback) at 502 indicating that CBG1 and CBG2 are not successfully decoded and CBG3 was successfully decoded. For example, in the case of a CBG bitmap type feedback, the feedback may simply be three bits “001”, where each bit corresponds to one of the CBGs CBG1, CBG2 and CBG3 of TB1. In the cooperation phase 511, based on the HARQ feedback from the TUE, the CUEs retransmit to the TUE at least a portion of the TB1 that they were able to successfully decode from the BS's or LUE's initial transmission in the multicast phase 501. In particular, as indicated at 504 in
After the second retransmission at 508, if the TUE correctly decodes CBG1, the TUE may send another HARQ feedback message indicating CBG1 is successfully decoded, as indicated at 510 in
A CBG/CB level UE cooperation scheme, such as the one shown in
The CBG/CB level UE cooperation scheme also enables a CUE to cooperate even if it does not decode the entire TB, whereas in a conventional TB level retransmission scheme a CUE that does not decode the whole TB cannot cooperate.
The CBG/CB level UE cooperation scheme also enables distributed cooperation where each CUE can cooperate based on its own decoding results and SL HARQ feedback from the TUE, without needing a BS to schedule the retransmission.
Outer Coding Based UE CooperationIn the second category of UE cooperating schemes of the present disclosure, rather than sending selected CBGs/CBs or the entire TB (possibly with different RVs) during the cooperation phase, CUEs instead send an outer coded version of selected CBGs or the entire TB. The outer code can further reduce the amount of retransmission data for more efficient cooperation.
Some general background on the concepts of inner and outer coding is provided below, after which outer coding and examples of its use in the context of the second category of UE cooperating schemes of the present disclosure will be described.
When a first network device, such as a BS or UE, has data to transmit to a second network device in the form of a plurality of bits, the first network device will first partition the plurality of bits into a plurality of chunks. Each chunk is referred to as an information code block (CB). A TB may be partitioned into the plurality of information CBs, or the plurality of information CBs may be mapped to one or more TBs for transmission, depending upon the implementation. In some cases, the plurality of information CBs may be grouped into a plurality of CBGs, as discussed previously. In some embodiments, a cyclic redundancy check (CRC) for the TB may be first appended to the TB before segmentation of the TB to different CBs. The first network device appends a CRC check to each information CB and then encodes each information CB using a channel code to obtain an encoded information CB. The channel code used is implementation specific and different channel codes may be applied to different information CBs. Examples of channel codes that may be used include polar codes, turbo codes, and low-density parity-check (LDPC) codes. The encoding of individual CBs is referred to as “inner coding” or “applying an inner code”.
Note that “outer code” and “inner code” refer to concatenating two codes together. When concatenating two codes, the information bits are first encoded by the outer code, the output of outer code is then encoded by the inner code. The output of the inner code is then transmitted through the wireless channel. The second network device that receives the transmission first decodes the inner code, e.g., using an inner code decoder, and the output from the inner decoding is then outer decoded to decode the information bits, e.g., using an outer code decoder. In the decoding process, the inner code is first decoded for each CB to obtain information bits of each CB, and then the CRC of each CB can be used to check whether the CB is decoded correctly or not. Then the outer coding, if used, may be further decoded to recover any failed CBs using the output CBs of inner code.
An example of inner coding is illustrated in
In the method illustrated in
The 3rd Generation Partnership Project (3GPP) release 15 specification for 5G New Radio (NR) supports eMBB and URLLC multiplexing where pre-emption of an eMBB signal may happen when a more urgent URLLC traffic arrives for transmission. The dynamic multiplexing of eMBB and URLLC services can use both FDM and TDM over the system bandwidth. In order to support dynamic multiplexing between eMBB and URLLC, a bursty puncturing/error recovery scheme may be used to recover the punctured part of eMBB that is punctured for URLLC multiplexing. In such a scenario, the CB corresponding to the pre-empting signal might not be known to the receiver, thus HARQ combining based on soft combining might not work in this situation.
One technique to solve the bursty puncturing/error recovery scheme adopts an outer erasure code (herein called an outer code) to do retransmission, which is shown in
A potential advantage of this approach is that the receiver does not need to tell the transmitter which CB(s) were not successfully decoded, and the CBs are still able to share the same HARQ process. In other words, the transmitter simply transmits the PCB(s) after knowing that the TB was not successfully decoded. The receiver will be able to recover the unsuccessfully decoded CBs, by knowing which CBs were unsuccessfully decoded, and by using the newly received PCB(s).
One application of outer codes is in puncturing an eMBB TB with URLLC signals, when the eMBB receiver does not know that the URLLC signals were actually not intended for the eMBB receiver. In that case, decoding the eMBB TB will fail, because combining redundant versions of the failed CBs with the CBs that are not intended for the receiver (and hence are interferences in this sense) will not succeed in recovering the original eMBB data. In that case, outer codes could be especially useful.
A single parity check CB has previously been proposed as a redundant version of outer codes. The single parity check CB is encoded across all data code blocks of a TB and generates a parity code block which could protect data code blocks from bursty interference and/or puncturing. One key here is that each CB is protected by PHY coding (LDPC/Turbo/Polar) and some error detection overhead such as CRC (as needed). Whenever one CB decoding fails, these bits are treated as known to be erased instead of code bit errors that are unknown. Based on the PHY coding/CRC, which marks the erased CB location, erasure decoding could be used to recover these failed CBs.
Encoding of single parity check code, according to an embodiment, is described below.
In a parity check code block scheme, assuming that a TB is divided into m CBs of equal length k, the ith CB is denoted as {ci,0, ci,1, . . . ci,k-1}. The PCB {p1,0, p1,1, . . . , pi,k-1} is obtained as
p1,l=c1,l⊕c2,l⊕ . . . ⊕cm,l, (Equation 1)
where ⊕ indicates an XOR operation. The PCB {p1,0, p1,1, . . . , p1,k-1} is then FEC encoded and transmitted. For example, the FEC can be LDPC, Turbo or Polar. The receiver receives the FEC coded PCB {p1,0, p1,1, . . . , p1,k-1}, and decodes it. If the ith CB is not successfully decoded, but {p1,0, p1,1, . . . , p1,k-1} is correctly received, the ith CB can be recovered as
ci,l=c1,l⊕c2,l⊕ . . . ⊕ci−1,l⊕ci+1,l⊕ . . . ⊕cm,l⊕pi,l, (Equation 2)
The above single parity check code method is performed with a simple XOR operation. However, there is a limitation that a parity check CB can only provide for error correction of one additional CB, which sometimes might not be enough. For example, if 2 CBs in a TB are unsuccessfully decoded, the 2 CBs cannot be correctly decoded using the single parity check code method. In this situation, other outer erasure codes, for example Hamming codes, could correct up to 2 CB erasures.
In addition to a parity check CB, a Reed-Solomon code could also be used as an outer code. The Reed-Solomon code has a shortcoming in that it needs to know in advance how many redundant versions need to be transmitted, and in addition, the Reed-Solomon code has a limitation in code parameters, e.g. its block length n=pm−1, where p is a prime number, and m is an integer. Also, shortened Reed-Solomon codes are usually less efficient than parity check codes.
In order to address the problem of unsuccessfully decoding CBs, U.S. patent application Ser. No. 15/718,523, filed Sep. 28, 2017, entitled “Systems and Methods for Outer Coding”, the entire contents of which is hereby incorporated by reference in its entirety, discloses a method which uses a shifted version of parity check CB as outer codes, in which the first data retransmission uses the single parity check CB, and the second data retransmission uses a shifted parity check CB. The receiver can correctly decode the CBs, and also decoding using more than one parity check CB can be done with reduced complexity. The technique can be used to correct two parity check CBs. In addition, the transmitter does not need to know in advance how many PCBs are needed, which means the transmitter can retransmit as needed.
U.S. Provisional Patent Application Ser. No. 62/657,611, filed Apr. 13, 2018, entitled “Systems and Methods for HARQ Retransmission Using an Outer Code”, the entire content of which is hereby incorporated by reference in its entirety, discloses a cyclic shift based outer code which can correct an arbitrary number of failed CBs.
In this technique, the encoder of a first transmitting network device, such as a BS or UE, may need to compute N parity CBs for an outer code applied to m information CBs. The decoder of a second receiving network device may need to use the received and correctly decoded N parity CBs to recover up to N failed information CBs, where m and N are both positive integers greater than zero and 1≤N≤m. The generation of N parity CBs by the encoder of a first network device, and the recovery of N failed information CBs by the decoder of a second network device, in accordance with this technique are explained below with reference to a simple example. In the example, m=4, k=5, and N=3, where m is the number of CBs in a TB, k is the number of bits in a CB, and N is the number of parity CBs. In some embodiments, k is a prime number so that there are no repeated patterns with the cyclic shift design described below. In the embodiments described below, the number of bits in each CB is assumed to be the same. However, the embodiments can be easily extended to the case where the number of bits in different CBs are different. For example, the encoder can pad some CBs with unused or predetermined bits to make the total number of bits in different CBs equal. Also, without loss of generality, in the example information CBs C1, C2, and C3 fail, none of the three parity CBs P1, P2, and P3 fail, and the three parity CBs P1, P2, and P3 are used to recover the three failed information CBs C1, C2, and C3.
In one embodiment, the encoder of the first transmitting network device computes each parity CB Pj, 1≤j≤N as follows:
Pj=C1(0)⊕C2((j-1)*1) . . . ⊕Ci((j-1)*(i-1)) . . . ⊕Cm((j-1)*(m-1))=Σi=1mCi((j-1)*(i-1)) (Equation 3).
The notation Ci(x) is used herein to designate a CB Ci that undergoes a left cyclic shift by x elements. In the following, we also refer to x as the cyclic shift value. For example, C1(0)=C1={C1,0, C1,1, C1,2, C1,3, . . . , C1,k-1}, C1(1)={C1,1, C1,2, C1,3, . . . , C1,k-1, C1,0}, C1(2)={C1,2, C1,3, . . . , Ci,k-1, C1,0, C1,1}, etc. The element Ci,l, where 0≤l≤k−1, refers to the l-th element of Ci. Ci,l(x) refers to the lth element of Ci after Ci undergoes a left cyclic shift by x elements. This can be expressed as Ci,l(x)=Ci,(l+x)mod k, where mod is the modular operation. Note that if x=0 then there is no cyclic shift, i.e. Ci(0)=Ci. Also, although not explicitly indicated in the notation, any cyclic shift is mod k, i.e. Ci(x) is equal to Ci(x mod k)mod k. For example, if k=5 and x=6, then Ci(6)=Ci(1). The symbol ⊕ used herein represents the XOR operation. The symbol Σ used herein refers to an XOR summation. The XOR of two CBs is implemented by XORing the two CBs on an element-by-element basis. That is, if Ca={Ca,0, Ca,1, . . . , Ca,k-1} and Cb={Cb,0, Cb,1, . . . , Cb,k-1}, then Ca⊕Cb={Ca,0⊕Cb,0, Ca,1⊕Cb,1, . . . , Ca,k-1⊕Cb,k-1}. Therefore, each element Pi,l of parity CB Pj (1≤j≤N, 0≤l≤k−1) is computed by encoder 310 as:
Pj,l=C1,l(0)⊕C2,l((j-1)*) . . . ⊕Ci,l((j-1)*(i-1)) . . . ⊕Cm,l((j-1)*(m-1))=Σi=1mCi,l((j-1)*(i-1)) (Equation 4).
Referring to the example introduced earlier in relation to
Note that C4(6)=C4(1) because k=5
On an element-by-element basis, the computations are:
P1,0=C1,0 ⊕C2,0⊕C3,0⊕C4,0; P2,0=C1,0⊕C2,1⊕C3,2⊕C4,3; P3,0=C1,0 ⊕C2,2⊕C3,4⊕C4,1
P1,1=C1,1 ⊕C2,1⊕C3,1⊕C4,1; P2,1=C1,1⊕C2,2⊕C3,3⊕C4,4; P3,1=C1,1 ⊕C2,3⊕C3,0 ⊕C4,2
P1,2=C1,2 ⊕C2,2⊕C3,2⊕C4,2; P2,2=C1,2⊕C2,3⊕C3,4⊕C4,0; P3,2=C1,2 ⊕C2,4⊕C3,1⊕C4,3
P1,3=C1,3 ⊕C2,3⊕C3,3⊕C4,3; P2,3=C1,3⊕C2,4⊕C3,0⊕C4,1; P3,3=C1,3 ⊕C2,0⊕C3,2⊕C4,4
P1,4=C1,4⊕C2,4⊕C3,4 ⊕C4,4; P2,4=C1,4⊕C2,0⊕C3,1⊕C4,2; P3,4=C1,4⊕C2,1⊕C3,3⊕C4,0.
The computations above are illustrated in
More generally, the encoder of a first network device computes N parity CBs from m information CBs in a way that is known to the decoder of the second network device. Each parity CB Pj, 1≤j≤N, is computed by performing an XOR of the m information CBs or cyclic shifts thereof.
U.S. Provisional Patent Application Ser. No. 62/657,611 further discloses a decoding function that is recursively executed by the decoder to recover failed information CBs at the decoder. Each parity CB Pj, 1≤j≤N, is a function of all m of the information CBs. In the first step of the decoding function the N parity CBs P1 to PN are modified to remove the effect of the correctly decoded information CBs by XORing the parity CB with the known information CB or with the cyclic shifted version of the known information CB that was used to generate the parity CB. The result is a set of N≤modified parity CBs to , which are represented as:
{tilde over (P)}j=i
where 1≤j≤N, and where it represents the t-th failed information CB.
In the example introduced in
=P1⊕C4=(C1⊕C2⊕C3⊕C4)⊕C4=C1⊕C2⊕C3
=P2⊕C4(3)=(C1⊕C2(1)⊕C3(2)⊕C4(3))−C1⊕C2(1)⊕C3(2)
=P3⊕C4(6)=(C1⊕C2(2)⊕C3(4)⊕C4(6))⊕C4(6)=C1⊕C2(2)⊕C3(4)
To decode the incorrectly decoded information CBs using the modified parity CBs, the decoder executes a recursive decoding function that invokes itself, as explained in detail below. The operation and execution of the decoding function is based on the following observations.
N−1 new parity CBs Q1 to QN-1 can be computed from the parity CBs to such that the effect of first incorrectly decoded information CB Ci
Qj={tilde over (P)}j−((j-1)*(i1-1))⊕{tilde over (P)}j+1−(j*(i
where {tilde over (P)}j−((j-1)*(i
Note that
{tilde over (P)}j−((j-1)*(i
and so Qj may be alternatively expressed as
Qj={tilde over (P)}j−(j-1)*(i
Alternatively, Qj may be expressed as
Qj=Σt=1N-1(Ci
N−1 information CBs D1 to DN-1 corresponding to the parity CBs Q1 to QN-1 may be defined as follows:
Dt=Ci
Note that the information CB Dt is defined as original failed information CB Ci
If Dt is defined as per Equation 5, then Dt left cyclic shifted by (j−1)*(it+1−i1) is Dt(j-1)*(i
Qj may therefore be expressed as
Qj=Σt=1N-1Dt((j-1)*(i
Note that Equation 8 is the same format as Equation 5, but with one less dimension: there are N−1 unknown information CBs D1 to DN-1, which are to be determined using N−1 known parity CBs Q1 to QN-1. The input of Equation 5 is dimension N, parity CBs Pj 1≤j≤N, and CB index it, and the output to be computed is Ci
A decoding function may therefore be defined and recursively executed by the decoder based on Equation 5 to recover the failed information CBs at the decoder.
U.S. Provisional Patent Application Ser. No. 62/657,611 also discloses a nested HARQ scheme that may be performed when the decoding of one or more of the parity CBs fails. In one embodiment, the nested HARQ method operates as follows. If a transmission is sent having N parity CBs, where 1≤N≤m, and decoding of one or more of the parity CBs fails, then the incorrectly decoded parity CBs may be recovered using the same method described above for recovering information CBs. Once the failed parity CBs are recovered, then the parity CBs may be used to recover the failed information CBs. As one example, an initial transmission is sent from a first network device to a second network device. The initial transmission includes m=7 information CBs C1 to C7. The decoder of the second network device incorrectly decodes N=3 of the information CBs. HARQ feedback is sent back to the first network device indicating that N=3 information CBs failed. N=3 parity CBs P1 to P3 are therefore generated by the encoder of the first network device and sent to the second network device. The decoder of the second network device incorrectly decodes N1=1 of the parity CBs. HARQ feedback is therefore sent back to the first network device indicating that decoding failed for N1=1 parity CBs. N1=1 parity CB P11 is generated by the encoder of the first network device, e.g., using an outer code encoder, with the parity CBs P1 to P3 as the input information CBs and sent to the second network device. The decoder of the second network device correctly decodes parity CB P11. Parity CB P11 is used to recover the failed one of parity CBs P1 to P3. Parity CBs P1 to P3 are then used to recover the N=3 failed information CBs. Each outer encoding and outer decoding step in the example may be implemented in the manner discussed above. In one implementation, the encoder of the first network device computes P11 as P11=P1⊕P2⊕P3.
More generally, the HARQ nesting method may have a plurality of iterations. Once an iteration occurs in which all transmitted parity CBs are correctly decoded, then the correctly decoded parity CBs may be used to correctly decode the failed CBs in the previous iteration, which are then used to correctly decode the failed CBs in the previous iteration, and so on, until the N failed information CBs are correctly decoded. For example,
Returning now to the second category of cooperative transmission schemes according to the present disclosure, which utilize outer coding based UE cooperation, it is noted that many of the following examples of cooperative transmission schemes in accordance with the second category use a cyclic shift based outer code, such as the one disclosed in U.S. Provisional Patent Application Ser. No. 62/657,611. However, more generally, outer codes used in embodiments of the second category can be a fountain code (or rateless code), Reed-Solomon (RS) code, a cyclic shift based outer code or any erasure code. A practical implementation of a fountain code could be Raptor codes, for example.
Similar to the cooperative transmission schemes of the first category, outer coding based cooperative transmission schemes in accordance with the second category of the present disclosure comprises two phases: a first multicast phase and a second cooperation phase. In the first multicast phase, the original transmitter, e.g., a BS or a LUE, sends a TB containing multiple information CBs to the CUEs and TUE. If a CUE decodes the TB successfully, it can cooperate by sending a number of parity CBs generated using the outer code. The generation of the parity CBs may be based on an outer code applied to the whole TB. An example of this is shown in
The number of parity CBs generated may be dependent on the feedback from the TUE after the multicast phase or after the previous transmission. For example, in one scenario, a TUE may feedback the number of CBs it failed to decode for the transmission from the first phase (e.g., via the Type 3 feedback described above). In this case, the CUE may generate the number of parity CBs equals to the number of failed CBs indicated in the TUE feedback. An embodiment of this scenario is shown in
After the first transmission, the TUE sends HARQ feedback (e.g., Type 3 HARQ feedback) at 702 indicating the number of CBs in the TB that were not successfully decoded. In the example shown in
In another scenario, a TUE may only feedback ACK/NACK of the TB (e.g., via the Type 1 feedback described above). In this case, the CUE may generate and transmit to the TUE just one parity CB or a fixed number of parity CBs.
The above example of a cooperation scheme in accordance with the second category of cooperative transmission schemes of the present disclosure assumes a CUE only cooperates if it successfully decodes the entire TB. In an alternative cooperation scheme using outer code in accordance with the second category of cooperative transmission schemes of the present disclosure, a CUE may still cooperate even if it does not decode the entire TB. For example, a CUE may generate the desired number of parity CBs based on less than all code block groups of the transport block, i.e., based on all the decoded CB(s) and not include the CB(s) it does not decode. In this case, a CUE cooperates based on a best effort scenario, because the CB it does not decode may be successfully decoded by the TUE or the TUE may be able to resolve the CB from cooperation of other CUE or the BS.
Another way to cooperate using outer code is for the CUE to send outer coded versions of CBGs, i.e., the CUE may send parity CBs generated using outer code applied to less than all CBGs of the TB instead of the whole TB. Again, the cooperation scheme may depend on the HARQ feedback from the TUE for previous transmissions. If the feedback from the TUE indicates which CBG(s) is/are successfully decoded (e.g., via the Type 2 feedback described above), then instead of retransmitting select CBGs that the CUE decoded successfully but that were not decoded by the TUE, the CUE can generate a small number of parity CBs based on the selected CBGs. In many cases only a small number of CBs among the CBGs of a given TB are corrupted. For example, if only one CB of a CBG is not successfully decoded, then only one parity CB may need to be generated and transmitted to the TUE in order to allow the TUE to resolve the undecoded CB. Therefore, using an outer code in this manner can reduce the number of CBs that need to be retransmitted to allow the TUE to resolve undecoded CBs/CBGs. Furthermore, in situations where multiple CUEs are available for cooperative transmission in this manner, the chance that the TUE will receive enough parity CBs from the group of CUEs for each failed CBG is increased.
An example of such a transmission scheme is shown in
The transport block TB1 transmitted in the first phase 801 contains 9 CBs, identified as CB1 to CB9, respectively. The nine CBs of TB1 are grouped into three CBGs, identified as CBG1, CBG2 and CBG3, respectively, such that CBG1 includes CB1, CB2 and CB3; CBG2 includes CB4, CB5 and CB6; and CBG3 includes CB7, CB8 and CB9.
CUE1 successfully decoded all the CBs in the data block TB1. CUE2 successfully decoded all CBs in TB1 except CB2, which belongs to CBG1. The TUE successfully decoded all CBs in TB1 except CB1 and CB2 of CBG1 and CB6 of CBG2.
After the first transmission, the TUE sends HARQ feedback (e.g., Type 2 HARQ feedback) at 802 indicating that CBG1 and CBG2 are not successfully decoded.
Based on the HARQ feedback from the TUE, CUE1 and CUE2 each generate at least one parity CB based on less than all CBGs of TB1. In particular, CUE generates a parity CB PCB1 using an outer code based on CBG1 and a parity CB PCB1 for CBG2 using an outer code based on CBG2, and CUE2 generates a parity CB PCB1 for CBG2 using an outer code based on CBG2. For example, the parity CB PCB1 for CBG1 may be generated by XORing the CBs of CBG1, i.e., CB1⊕CB2⊕CB3, and the parity CB PCB1 for CBG2 may be generated by XORing the CBs of CBG2, i.e., CB4⊕CB5⊕CB6. In the cooperation phase 811, CUE1 and CUE2 send the PCBs they have generated to the TUE in a second transmission, as indicated at 804. The TUE successfully decodes all the parity CBs received in the second transmission, which is enough to recover CBG2, because only one CB was not successfully decoded in CBG2. However, because a single PCB only allows the TUE to recover a single corrupted CB, the TUE cannot yet recover CBG1, because there were two unsuccessfully decoded CBs in CBG1.
At 806, the TUE sends another HARQ feedback indicating CBG1 is still unsuccessfully decoded. CUE1 then generates another different parity CB, PCB2, for CBG1 using an outer code based on CBG1. For example, CUE1 may use a cyclic shift based outer code similar to the one described above with reference to
At 808, CUE1 sends the parity CB PCB2 to the TUE. In this scenario, CUE2 does not generate another parity CB or retransmit at 808 because it did not successfully decode CBG1.
After the second transmission at 808, if the TUE correctly decodes CBG1 using PCB2, the TUE may send another HARQ feedback message indicating CBG1 or the entire TB is successfully decoded, as indicated at 810 in
In some embodiments, the TUE can also feedback more information to help CUE determine how many parity CBs to generate for each CBG. For example, in such embodiments, the TUE may feedback the number of CBs that it did not successfully decode for each CBG (i.e., the Type 4 feedback described above), which provides more information than simply which CBGs are successfully decoded. Alternatively, in order to further reduce the feedback overhead, the TUE can feedback the maximum number of failed CBs among all CBGs in addition to which CBGs are successfully decoded. In this scenario, all CUEs that correctly decode the CBGs that the TUE does not successfully decode may send one or more parity CBs for those CBGs. The number of parity CBs generated for each CBG can be determined based on the feedback. For example, if the number of failed CBs for each CBG is fed back by the TUE, the CUE may generate a number of parity CBs equal to the number of failed CBs for that CBG reported by the TUE. If the maximum number of failed CBs for all CBGs is fed back, the CUE may generate a number of parity CBs for each failed CBG equal to the maximum number of failed CBs for all CBGs reported by the TUE. For example, referring again to the embodiment shown in
One extension to this transmission scheme is the use of nested HARQ in CBG based outer coding. For example, after a CBG of an initial transmission fails to be successfully decoded, and a CUE sends a transmission that includes a number of parity CBs of the failed CBG, the TUE may send feedback indicating the number of parity CBs that have not been successfully decoded for the last transmission. Then the CUE can generate and transmit to the TUE a number of parity CBs using outer code based on the parity CBs transmitted in the last transmission instead of generating different parity CBs using outer code based on the original information CBs in the initial transmission. The TUE can then use the parity CBs received in the latest transmission to recover the parity CBs in the preceding transmission, then use the parity CBs in the preceding transmission to recover the CBs in the earlier transmissions. This process can go on until the TUE can recover the original information CBs of the CBG.
An example of such a transmission scheme that includes a nested HARQ transmission is shown in
The transport block TB1 transmitted in the first phase 901 contains 9 CBs, identified as CB1 to CB9, respectively. The nine CBs of TB1 are grouped into three CBGs, identified as CBG1, CBG2 and CBG3, respectively, such that CBG1 includes CB1, CB2 and CB3, CBG2 includes CB4, CB5 and CB6, and CBG3 includes CB7, CB8 and CB9.
As in the previous examples, in this example CUE1 successfully decoded all the CBs in the data block TB1. CUE2 successfully decoded all CBs in TB1 except CB2, which belongs to CBG1. The TUE successfully decoded all CBs in TB1 except CB1 and CB2 of CBG1 and CB6 of CBG2.
After the first transmission, the TUE sends HARQ feedback (e.g Type 4 HARQ feedback) at 902 indicating that two CBs are not successfully decoded in CBG1 and one CB is not successfully decoded in CBG2.
Based on the HARQ feedback from the TUE, CUE1 and CUE2 generate parity CB(s) using an outer code based on the CBG(s) the TUE did not successfully decode such that each parity CB is based on at least one, but less than all, code block groups of the transport block. In this example, CUE1 generates two parity CBs, PCB1 and PCB2, for CBG1 using an outer code based on CBG1. CUE1 also generates one parity CB, PCB1, for CBG2 using an outer code based on CBG2. CUE2 generates one parity CB, PCB1, for CBG2 using an outer code based on CBG2. As in the previous example, the parity CBs for the CBGs may be generated by XORing the CBs of the CBGs or cyclic shifts thereof, e.g., PCB1 for CBG1 may be equal to CB1⊕CB2⊕CB3, and PCB2 for CBG1 may be equal to CB1⊕CB2(1)⊕CB3(2).
In the cooperation phase 911, CUE1 and CUE2 send the PCBs they have generated to the TUE in a second transmission, as indicated at 904. In this example, the TUE successfully decodes PCB2 for CBG1 and PCB1 for CBG2, but the TUE fails to successfully decode the first parity CB, PCB1, that CUE1 generated using an outer code based on CBG1. Using a nested HARQ scheme, at 906 the TUE sends another HARQ feedback indicating that one of the two PCBs is not successfully decoded for CBG1 and CBG2 is successfully decoded. CUE then generates one parity CB, PPCB (parity of parity CB), using outer code based on the two parity CBs, PCB1 and PCB2, that CUE1 sent for CBG1 in the last transmission at 904. For example, CUE1 may generate the PPCB by XORing the PCBs of the last transmission, i.e., PPCB may be equal to PCB1⊕PCB2.
CUEi sends the PPCB to the TUE in a third transmission, as indicated at 908. After successfully receiving the PPCB in the third transmission, the TUE uses the PPCB to recover the PCB1 for CBG1. After using PCB1 and PCB2 for CBG1 to successfully decode CBG1, the TUE sends another HARQ feedback at 910 that includes an ACK to the CUEs, and possibly the BS, to confirm that the CBGs of TB1 have been successfully decoded. Note that if nested HARQ is not used, the TUE may send HARQ feedback indicating that it still needs another PCB for CBG1. In which case CUE1 may operate in accordance with the previous example shown in
In another outer code based cooperation scheme, the TUE may only provides simple TB-level HARQ feedback. For example, the TUE might send an ACK or NACK of the TB. In another example, the TUE sends an ACK if the TUE successfully decodes the TB, but does not send anything if the TUE fails to decode the TB. In other outer code based cooperation schemes, the TUE might not send any feedback at all. In either of these scenarios, a CUE may repeatedly send a parity CB of the TB until an ACK is received. In such cases, a CUE may wait a certain time in between sending parity CBs to accommodate possible feedback from the TUE. The time window between sending parity CBs may be predefined or signaled by the BS.
An example of such a transmission scheme is shown in
As in the previous examples, in this example CUE1 successfully decoded all the CBs in the data block TB1. CUE2 successfully decoded all CBs in TB1 except CB2, which belongs to CBG1. The TUE successfully decoded all CBs in TB1 except CB1 and CB2 of CBG1 and CB6 of CBG2.
In the cooperation phase 1011, in response to the lack of an ACK from the TUE within a time window 1003 following the initial transmission, CUE1 generates a parity CB, PCB1, for TB1 using an outer code based on all the original information CBs of TB1 and sends PCB1 to the TUE in a second transmission, as indicated at 1002. For example, CUE1 may generate the parity CB PCB1 for TB1 by XORing the CBs of TB1 or cyclic shifts thereof, e.g., PCB1 may be equal to CB1⊕CB2⊕CB3⊕CB4⊕CB5⊕CB6⊕CB7⊕CB8⊕CB9. In this example, CUE2 does not generate a parity CB based on TB1 or retransmit at 1002 because it did not successfully decode CBG1.
In this example, because CUE1 does not receive an ACK from the TUE within a time window 1003 after the second transmission, CUE sends a third transmission that includes a different parity CB, PCB2, for TB1 to the TUE, as indicated at 1004. For example, CUE1 may use a cyclic shift based outer code similar to the one described above with reference to
At 1006, because CUE1 does not receive an ACK from the TUE within a time window 1003 after the third transmission, CUE1 sends a third parity CB, PCB3, for TB1 to the TUE. PCB3 is different from both PCB1 and PCB2. For example, PCB3 may be equal to CB1⊕CB2(2)⊕CB3(4) ⊕CB4(6)⊕CB5(8) ⊕CB6(10)⊕CB7(12)⊕CB8(14)⊕CB9(16).
After the third transmission at 1006, the TUE correctly decodes TB1 using the successfully received parity CBs, PCB1, PCB2 and PCB3 to recover the failed CBs, CB1, CB2 and CB6, and sends a HARQ feedback message that includes an ACK indicating TB1 is successfully decoded, as indicated at 1008 in
The cooperation UE may also transmit the partition of CBGs or outer coded CBs/CBGs based on a best-effort cooperation scheme. For example, a CUE might not receive feedback information or might not receive enough feedback information from the TUE to determine which CB(s) or CBG(s) are decoded successfully. In one embodiment, a CUE may only cooperate if it can decode the entire TB. In such an embodiment, the CUE may retransmit the whole TB or may generate an outer coded version of the TB and transmit the outer coded version to the TUE. In another embodiment, a CUE may cooperate even if it only successfully decodes a partial subset of the CBs or CBGs of the entire TB. In such an embodiment, when an outer code is not used, the CUE may simply retransmit all of the CBs or CBGs that it can successfully decode to the TUE. When an outer code is used, the CUE may generate an outer coded version of information based on all the CBs or CBGs it can successfully decode. In one example, the CUE may transmit one or more parity CBs based on all the CBs that it successfully decode or all the CBs within the CBGs that it successfully decodes. In another example, the CUE may generate one or more parity CBs for each CBG it has successfully decoded, where each parity CB is generated based on an outer coded version of the CBs within a CBG.
Selection of Parity Index for Outer CodeIn all the above schemes involving cooperating using outer codes, the transmitter (e.g. CUE) determines which parity CB to transmit. In one example, when the outer code is the outer code proposed in U.S. patent application Ser. No. 15/718,523, a CUE needs to determine the parity index j (see Equation 3). In another example, if the outer code is the Raptor code, a key or seed that can be used to generate pseudo random coefficients for parity bits, and therefore in embodiments that utilize the Raptor code as an outer code, the choice of parity CB index involves determining the key or seed. Several options for selecting and generating parity CBs are discussed below.
In some embodiments, the transmitter (e.g. CUE) follows a predefined order of generating parity CBs. For example, if a cyclic shift based outer code is used, a CUE may always generate PCB_1, PCB_2, . . . , PCB_N if N PCBs are needed for the transmission (or according to the feedback). Referring to Equation 3 for generating PCBs, an example of the order would be j=1, 2, . . . , N. The advantage is that the code can be designed in a way that it is easy and efficient to decode if the particular order of PCBs is used.
In a second scheme, the transmitter randomly or pseudo randomly selects a parity CB index. For example, in the case of Raptor code, a CUE may randomly or pseudo randomly select a key or seed. The key and seed can be selected from a predefined seed pool. In the case of a cyclic shift based outer code, a CUE can select the parity index j randomly among a given range, e.g. [1, M]. This method may be best suited to scenarios where the number of failed CBs is unknown and/or multiple CUEs are likely to be available, because multiple CUEs may select different PCBs, thus increasing the number of failed CBs that the TUE can recover if the PCBs are successfully decoded.
In a third scheme, CUEs may each use a different parity CB index, which may be determined by a different starting point of parity CBs. For example, the starting point can be a starting value of the parity index j=j0, and the rest of the PCBs follow a predefined order after the starting point, e.g. in the order of (j0,j0+1,j0+2, . . . ). In another example, the starting point can be a seed, and all the rest of the PCBs for the particular CUE are generated using the seed. The starting value of j or the seed may be associated with the CUE. For example, the starting value may be associated with an ID associated with the CUE, such as the UE ID, that can be signaled by the BS.
In addition, in order for the TUE to know which PCBs are sent and how they are generated, in some embodiments CUEs may send PCB information in a control channel. Because the transmission is in SL, UE may indicate the one or more PCB index (e.g. j or seed) in the sidelink control channel information (SCI) that is associated with the data transmission. A CUE may also indicate the CBG index in the SCI if the transmission is based on selected CBGs.
The CUE may indicate the information identifying the selected CBGs and the parity CB transmitted using the outer code to the TUE. The information may be transmitted in the SCI. In this case, when the TUE decodes the SCI, it is able to know how to decode the received CBs. The information may include which selected CBs or CBGs among the TB are transmitted by the CUE to the TUE. For example, the information may include the CBG index of the CBGs that are transmitted by the CUE to the TUE. In some other embodiments, in addition to identifying which CBGs are transmitted by the CUE to the TUE, the information may indicate how many outer coded CBs the CUE generated and transmitted to the TUE for each CBG. For example, CUE1 may generate a parity CB (PCB1) using an outer code based on CBG1, and transmit PCB1 to the TUE. CUE1 uses SCI to inform the TUE that one parity CB for CBG1 is transmitted. In some embodiments, the information may include how the outer coded CB is generated for each CBG. This information may include the parameters to generate the outer code or the index of the parity CB for each CBG. In one example, CUE1 generates the parity CB (PCB2) using an outer code based on CBG1 and transmits PCB2 to the TUE. The TUE then indicates in the SCI the index of the parity CB (e.g. index 2 for PCB2) and the CBG index (index 1 for CBG1) needed to be transmitted by CUE1 to the TUE. In the case when the outer code is the outer code proposed in U.S. patent application Ser. No. 15/718,523, the CUE can generate the parity CB based on the parity index j=2 (see Equation 3). After the TUE decodes SCI, the TUE knows that PCB1 of CBG1 is transmitted, and it can follow the decoding algorithm to decode PCB1.
In addition to the advantage mentioned for the first category of CBG/CB based cooperation schemes without outer code, the outer code based cooperation schemes of the second category can further reduce the amount of retransmission data for more efficient cooperation. The outer code based cooperation schemes also allows a CUE to cooperate without fully decoding the entire TB, and enables distributed cooperation where each CUE cooperates based on its own decoding results and SL HARQ feedback without scheduling instructions from the network. In addition, a PHY layer outer-code may minimize the number of retransmit bits even without full feedback on the decoded CB index. Also, if the transmission channel is close to an erasure channel, soft combining of retransmissions is typically not effective, and therefore an outer code can be more efficient than using a different redundancy version for retransmission.
Although many of the embodiments described above are focused on distributed UE cooperation where CUEs cooperate without BS scheduling, many elements of the cooperative transmission schemes of the present disclosure can also be applied to schedule-based cooperation. For example, in such cases, a BS may schedule the CUEs to transmit selected CBGs or outer coded code blocks based on selected CBGs or the entire TB. In this case, the BS may send scheduling information via a control channel (e.g. downlink control information (DCI)) to the transmitter UE. The scheduling information may include information identifying which selected CBs or CBGs among the TB are to be transmitted by the CUE to the TUE. For example, the scheduling information may include the CBG index of each CBG among the CBGs of the TB that is to be transmitted by the CUE to the TUE. In some other embodiments, in addition to information identifying which CBGs are to be transmitted by the CUE to the TUE, the scheduling information may indicate how many outer coded CBs of each CBG should be generated and transmitted by the CUE to the TUE. In such embodiments, the CUE then follows the BS's instructions conveyed via the scheduling information and sends corresponding CBGs or outer coded CB(s) or CBG(s) to the TUE. For example, the BS may send DCI that includes scheduling information that indicates 1 parity CB of CBG1 needs to be retransmitted by CUE1 to the TUE. CUE, then generates a parity CB (PCB1) using an outer code based on CBG1 and transmits PCB1 to the TUE according to the scheduling information in the DCI. In some embodiments, the scheduling information may further include information on how the outer coded CB is generated for each CBG. This information may further include the parameters to generate the outer code or the index of the parity CB for each CBG. In one example, a BS may send DCI to indicate that the index of the parity CB (e.g. index 2 for PCB2) and CBG index (index 1 for CBG1) needs to be retransmitted by CUE1 to the TUE. CUE, then generates the parity CB (PCB2) using an outer code based on CBG1 and transmits PCB2 to the TUE according to the scheduling information in DCI. In the case when the outer code is the outer code proposed in U.S. patent application Ser. No. 15/718,523, the CUE can generate the parity CB based the parity index j=2 (see Equation 3). In some embodiments, a CUE may indicate all the above scheduling information in SCI that is associated with the transmission to the TUE so that the TUE can identify the SL retransmissions from the CUE through decoding of the SCI. However, the feedback scheme and the transmission scheme, as well as information in the SL control channel, are still applicable to these schedule based cooperation embodiments.
Furthermore, although many of the embodiments described above are related to cooperative transmission schemes for UE cooperation, many elements of the cooperative transmission schemes of the present disclosure also have application outside of the context of UE cooperation and sidelink transmission. For example, the use of CBG level outer coding, HARQ feedback that includes both CBG level ACK/NACK and information indicating the number of failed CBs per CBG or the maximum number of failed CBs in all CBGs, and nested HARQ techniques using per-CBG outer code and feedback, each have application outside of UE cooperation and sidelink transmission. More generally, these techniques may be applied for any communication between a first network device and a second network device, e.g., where the first network device is a BS and the second network device is a UE. Examples of the application of the foregoing techniques in the context of transmissions between first and second network devices are described below with reference to
In response to the lack of an ACK from Device B within a time window following the initial transmission, Device A generates a parity CB, PCB1, for TB1 using an outer code based on all the original information CBs of TB1, and sends PCB1 to Device B in a second transmission, as indicated at 1102. For example, Device A may generate the parity CB PCB1 for TB by XORing the CBs of TB1 or cyclic shifts thereof, e.g., PCB1 may be equal to CB1⊕CB2⊕CB3⊕CB4⊕CB5⊕CB6⊕CB7⊕CB8⊕CB9.
In this example, because Device A does not receive an ACK from Device B within a time window after the second transmission, Device A sends a third transmission that includes a different parity CB, PCB2, for TB1 to Device B, as indicated at 1104. For example, Device A may use a cyclic shift based outer code similar to the one described above with reference to
For example, PCB2 may be equal to CB1⊕CB2(1)⊕CB3(2) ⊕CB4(3)⊕CB5(4) ⊕CB6(5)⊕CB7(6)⊕CB8(7)⊕CB9(8).
At 1106, because Device A does not receive an ACK from Device B within a time window after the third transmission, Device A sends a third parity CB, PCB3, for TB1 to Device B. PCB3 is different from both PCB1 and PCB2. For example, PCB3 may be equal to CB1⊕CB2(2)⊕CB3(4) ⊕CB4(6)⊕CB5(8) ⊕CB6(10)⊕CB7(12)⊕CB8(14)⊕CB9(16).
In this example, after the third transmission at 1106, Device B correctly decodes TB1 using the successfully received parity CBs, PCB1, PCB2 and PCB3 to recover the failed CBs, CB1, CB2 and CB6, and sends a HARQ feedback message that includes an ACK indicating TB1 is successfully decoded, as indicated at 1108 in
Similar to the previous example, the original transmitter, Device A, transmits a data block that includes a transport block TB1 to the receiving device, Device B, as indicated at 1200 in
As in the previous example, Device B successfully decodes all CBs in TB1 except CB1 and CB2 of CBG1 and CB6 of CBG2.
After the first transmission, Device B sends CBG level HARQ feedback (e.g., the Type 2 HARQ feedback described earlier) at 1202 indicating that CBG1 and CBG2 are not successfully decoded.
Based on the HARQ feedback, Device A generates a parity CB PCB1 using an outer code based on CBG1 and a parity CB PCB1 for CBG2 using an outer code based on CBG2. For example, the parity CB PCB1 for CBG1 may be generated by XORing the CBs of CBG1, i.e., CB1⊕CB2⊕CB3, and the parity CB PCB1 for CBG2 may be generated by XORing the CBs of CBG2, i.e., CB4⊕CB5⊕CB6. Device A sends the parity CBs it generated to Device B in a second transmission, as indicated at 1204. In this example, Device B successfully decodes the parity CBs received in the second transmission, which is enough to recover CBG2, because only one CB was not successfully decoded in CBG2. However, because a single PCB only allows the Device B to recover a single corrupted CB, Device B cannot yet recover CBG1, because there were two unsuccessfully decoded CBs in CBG1.
At 1206, Device B sends another HARQ feedback indicating CBG1 is still unsuccessfully decoded. Device A then generates another different parity CB, PCB2, for CBG1 using an outer code based on CBG1. For example, Device A may use a cyclic shift based outer code similar to the one described above with reference to
At 1208, Device B sends the parity CB PCB2 to Device B. After the third transmission at 1208, if Device B correctly decodes CBG1 using PCB2, it may send another HARQ feedback message indicating CBG1 or the entire TB is successfully decoded, as indicated at 1210 in
In some embodiments, the receiving network device, which in this example is Device B, can also feedback more information to help the transmitting network device determine how many parity CBs to generate for each CBG. For example, the receiving network device may feedback the number of CBs that it did not successfully decode for each CBG (i.e., the Type 4 feedback described above), which provides more information than simply which CBGs are successfully decoded. Alternatively, in order to further reduce the feedback overhead, the receiving network device can feedback the maximum number of failed CBs among all CBGs in addition to which CBGs are successfully decoded. In this scenario, the number of parity CBs generated for each CBG can be determined based on the feedback. For example, if the number of failed CBs for each CBG is fed back by the receiving network device, the transmitting network device may generate a number of parity CBs equal to the number of failed CBs reported for that CBG. If the maximum number of failed CBs for all CBGs is fed back, the transmitting device may generate a number of parity CBs for each failed CBG equal to the maximum number of failed CBs for all CBGs reported by the receiving network device. For example, referring again to the embodiment shown in
Similar to the previous two examples, the original transmitter, Device A, transmits a data block that includes a transport block TB1 to the receiving device, Device B, as indicated at 1300, and Device B successfully decodes all CBs in TB1 except CB1 and CB2 of CBG1 and CB6 of CBG2.
After the first transmission, Device B sends HARQ feedback (e.g Type 4 HARQ feedback) at 1302 indicating that two CBs are not successfully decoded in CBG1 and one CB is not successfully decoded in CBG2. Based on the HARQ feedback, Device A generates two parity CBs, PCB1 and PCB2, for CBG1 using an outer code based on CBG1 and one parity CB, PCB1, for CBG2 using an outer code based on CBG2. As in the previous example, the parity CBs for the CBGs may be generated by XORing the CBs of the CBGs or cyclic shifts thereof, e.g., PCB1 for CBG1 may be equal to CB1⊕CB2⊕CB3, and PCB2 for CBG1 may be equal to CB1⊕CB2(1)⊕CB3(2).
Device A sends the PCBs it generated to Device B in a second transmission, as indicated at 1304. In this example, Device B successfully decodes PCB2 for CBG1 and PCB1 for CBG2, but fails to successfully decode PCB1 for CBG1. At 1306, Device B sends another HARQ feedback indicating that one CB is still not successfully decoded for CBG1. Based on this additional HARQ feedback, Device A then generates a third parity CB, PCB3, for CBG1 and sends PCB3 to Device B in a third transmission, as indicated at 1308.
PCB3 may be generated in the same manner as the first two parity CBs, PCB1 and PCB2, for CBG1, such that PCB3 is generated using outer coding based on the CBs of CBG1. For example, CUE1 may use a cyclic shift based outer code similar to the one described above with reference to
Alternatively, if a nested HARQ scheme is used, the HARQ feedback sent by Device B at 1306 may instead indicate that one of the parity CBs for CBG1 was not successfully decoded. In this scenario, rather than being generated based on the CBs of CBG1, PCB3 may be a PPCB generated using outer coding based on the parity CBs, PCB1 and PCB2, that Device A sent for CBG1 in the second transmission. For example, PCB3 may be equal to PCB1⊕PCB2. In which case, after successfully receiving PCB3 in the third transmission, Device B may use PCB3 to recover the PCB1 for CBG1. After using PCB1 and PCB2 for CBG1 to successfully decode CBG1, the TUE sends the HARQ feedback at 1310 that includes an ACK to Device A, to confirm that the CBGs of TB1 have been successfully decoded.
EXAMPLE EMBODIMENTSThe following provides a non-limiting list of additional Example Embodiments of the present disclosure:
Example Embodiment 1. A method for user equipment (UE) cooperation, the method comprising:
receiving, at a first UE, a transport block intended for a second UE, the transport block comprising a plurality of code block groups, each code block group comprising a plurality of code blocks; and
transmitting, from the first UE to the second UE, at least one code block group of the transport block intended for the second UE, the at least one code block group including less than all code block groups of the transport block.
Example Embodiment 2. The method of Example Embodiment 1, wherein the at least one code block group transmitted from the first UE comprises each code block group that the first UE was able to successfully decode for the transport bock.
Example Embodiment 3. The method of Example Embodiment 1, further comprising:
receiving, at the first UE, scheduling information from a base station,
wherein the at least one code block group transmitted from the first UE is selected from among the plurality of code block groups of the transport block based at least in part on the scheduling information from the base station.
Example Embodiment 4. The method of Example Embodiment 1, further comprising:
receiving, at the first UE, a feedback message from the second UE including information identifying at least one code block or code block group the second UE failed to decode for the transport block,
wherein the at least one code block group transmitted from the first UE is selected from among the plurality of code block groups of the transport block based at least in part on the feedback message from the second UE.
Example Embodiment 5. The method of Example Embodiment 4, wherein the feedback message comprises, for each code block or code block group the second UE failed to decode, a code block index or code block group index corresponding to the code block or code block group.
Example Embodiment 6. The method of Example Embodiment 1, further comprising:
transmitting, from the first UE, information identifying each code block group of the at least one code block group transmitted from the first UE.
Example Embodiment 7. The method of Example Embodiment 6, wherein the information identifying each code block group of the at least one code block group comprises, for each code block group of the at least one code block group, a code block group index corresponding to the code block group.
Example Embodiment 8. The method of Example Embodiment 7, wherein the information identifying each code block group of the at least one code block group transmitted from the first UE is included in sidelink control information (SCI) transmitted in a sidelink control channel.
Example Embodiment 9. The method of Example Embodiment 1, wherein the first UE successfully decodes all of the code block groups of the transport block.
Example Embodiment 10. The method of Example Embodiment 1, wherein receiving the transport block intended for the second UE comprises receiving the transport block from a third UE.
Example Embodiment 11. The method of Example Embodiment 10, wherein receiving the transport block from the third UE comprises receiving the transport block via a multicast sidelink transmission from the third UE.
Example Embodiment 12. The method of Example Embodiment 1, wherein receiving the transport block comprises receiving the transport block from a base station.
Example Embodiment 13. The method of Example Embodiment 12, wherein receiving the transport block from the base station comprises receiving the transport block via a multicast downlink transmission from the base station.
Example Embodiment 14. A method for user equipment (UE) cooperation, the method comprising:
receiving, at a first UE, a transport block intended for a second UE, the transport block comprising a plurality of code block groups, each code block group comprising a plurality of code blocks;
generating, by the first UE, at least one outer coded code block based on less than all code block groups of the transport block;
transmitting, from the first UE to the second UE, the at least one outer coded code block.
Example Embodiment 15. The method of Example Embodiment 14, wherein:
generating at least one outer coded code block comprises generating a single outer coded code block based on contents of less than all of the code block groups of the transport block; and
transmitting the at least one outer coded code block comprises transmitting the single outer coded code block to the second UE.
Example Embodiment 16. The method of Example Embodiment 15, wherein the single outer coded code block is based on contents of two or more code block groups of the transport block.
Example Embodiment 17. The method of Example Embodiment 14, wherein generating and transmitting the at least one outer coded code block comprises:
generating, for each code block group of the transport block, an outer coded version of the code block group based on contents of the code block group; and
transmitting the outer coded versions of the code block groups to the second UE.
Example Embodiment 18. The method of Example Embodiment 14, wherein generating the at least one outer coded code block comprises applying outer coding to less than all of the contents of the transport block, the outer coding being selected from the group consisting of: raptor coding, Reed Solomon (RS) coding, parity check coding, and erasure coding.
Example Embodiment 19. The method of Example Embodiment 18, wherein applying the outer coding comprises applying parity check coding, wherein applying the parity check coding comprises computing at least one parity check code block by, for each one of the at least one parity check code block, performing an XOR operation on one or more of the code block groups or cyclic shifts thereof.
Example Embodiment 20. The method of Example Embodiment 14, further comprising:
receiving, at the first UE, a feedback message from the second UE including information indicating the second UE failed to decode at least one code block or code block group of the transport block,
wherein generating the at least one outer coded code block comprises generating the at least one outer coded code block based on:
-
- i) the feedback message from the second UE; and
- ii) one or more code block groups the first UE was able to successfully decode for the transport bock.
Example Embodiment 21. The method of Example Embodiment 20, wherein the feedback message comprises information identifying the at least one code block or code block group the second UE failed to decode.
Example Embodiment 22. The method of Example Embodiment 21, wherein the information identifying the at least one code block or code block group comprises, for each code block or code block group the second UE failed to decode, a code block index or code block group index corresponding to the code block or code block group.
Example Embodiment 23. The method of Example Embodiment 15, further comprising:
transmitting, from the first UE, outer coding information identifying each code block group that the at least one outer coded code block is based on.
Example Embodiment 24. The method of Example Embodiment 23, wherein the outer coding information comprises, for each code block group that the at least one outer coded code block is based on, a code block group index corresponding to the code block group.
Example Embodiment 25. The method of Example Embodiment 21, wherein the information indicating the second UE failed to decode at least one code block or code block group of the transport block further comprises information identifying, for each code block group the second UE failed to decode, a quantity of code blocks the second UE failed to decode for the code block group.
Example Embodiment 26. The method of Example Embodiment 25, wherein generating and transmitting the at least one outer coded code block comprises:
generating, for each of at least a subset of the code block groups the second UE failed to decode, an outer coded version of the code block group based on contents of the code block group; and
transmitting the outer coded versions of the code block groups of the transport block to the second UE.
Example Embodiment 27. The method of Example Embodiment 26, wherein generating the outer coded versions of the code block groups comprises generating, for each of at least a subset of the code block groups the second UE failed to decode, a quantity of outer coded code blocks based on the contents of the code block group equal to the quantity of code blocks the second UE failed to decode for the code block group.
Example Embodiment 28. The method of Example Embodiment 20, wherein the information indicating the second UE failed to decode at least one code block or code block group of the transport block comprises information identifying a quantity of code blocks the second UE failed to decode for the transport block.
Example Embodiment 29. The method of Example Embodiment 21, wherein the information indicating the second UE failed to decode at least one code block or code block group of the transport block further comprises information identifying a maximum quantity of code blocks the second UE failed to decode for any given code block group of the transport block.
Example Embodiment 30. The method of Example Embodiment 29, wherein generating and transmitting the at least one outer coded code block comprises:
generating, for each of at least a subset of the code block groups the second UE failed to decode, an outer coded version of the code block group based on contents of the code block group; and
transmitting the outer coded versions of the code block groups of the transport block to the second UE.
Example Embodiment 31. The method of Example Embodiment 30, wherein generating the outer coded versions of the code block groups comprises generating, for each of at least a subset of the code block groups the second UE failed to decode, a quantity of outer coded code blocks based on contents of the code block group equal to the maximum quantity of code blocks the second UE failed to decode for any given code block group of the transport block.
Example Embodiment 32. A method performed by a first network device, the method comprising
generating, by the first network device, for each of N code block groups of a transport block, an outer coded version of the code block group, the outer coded version comprising at least one outer coded code block based on contents of the code block group, the transport block including m code block groups, N≤m and m≥2, each code block group comprising a plurality of code blocks;
transmitting, by the first network device, the outer coded versions of the N code block groups to a second network device.
Example Embodiment 33. The method of Example Embodiment 32, further comprising:
receiving, by the first network device, a feedback message from the second network device, the feedback message comprising information identifying the N code block groups of the transport block as failed code block groups that the second network device has not successfully decoded,
wherein the generating and transmitting of the outer coded versions of the N code block groups is responsive to receiving the feedback message.
Example Embodiment 34. The method of Example Embodiment 33, wherein:
the feedback message further comprises information indicating a maximum quantity of failed code blocks in any given failed code block group of the transport block; and
generating the outer coded versions of the N code block groups comprises generating, for each of the N code block groups, a quantity of outer coded code blocks equal to the maximum quantity of failed code blocks in any given failed code block group of the transport block.
Example Embodiment 35. The method of Example Embodiment 33, wherein the feedback message is a first feedback message, and wherein the method further comprises:
receiving, by the first network device, a second feedback message from the second network device, the second feedback message comprising information identifying N1 of the outer coded versions of the N code block groups as failed first outer coded versions the second network device has not successfully decoded, N1≤N;
generating, by the first network device, for each of the N1 failed first outer coded versions, a second outer coded version based on contents of the outer coded code block(s) of the failed first outer coded version; and
transmitting, by the first network device, the second outer coded versions of the N1 failed first outer coded versions of failed code block groups of the transport block to the second network device.
Example Embodiment 36. The method of Example Embodiment 32, wherein the first network device is a UE, and the second network device is a base station; or the first network device is a base station, and the second network device is a UE.
Example Embodiment 37. The method of Example Embodiment 32, wherein generating the outer coded versions of the N code block groups comprises, for each of the N code block groups, applying outer coding to the contents of the code block group, the outer coding being selected from the group consisting of: raptor coding, Reed Solomon (RS) coding, parity check coding, and erasure coding.
Example Embodiment 38. The method of Example Embodiment 32, wherein generating the outer coded versions of the N code block groups comprises, for each of the N code block groups, computing at least one parity check code block by, for each one of the at least one parity check code block, performing an XOR operation on all of the code blocks of the code block group or cyclic shifts thereof.
Example Embodiment 39. The method of Example Embodiment 38, wherein computing the at least one parity check code block for a given one of the N failed code block groups comprises:
for each parity check code block, computing an XOR of p words, wherein each one of the p words is either equal to or a cyclic shift of a respective different one of p code blocks in the failed code block group.
Example Embodiment 40. The method of Example Embodiment 38, wherein the cyclic shift applied to a code block Ci to compute a parity check code block P is different from the cyclic shift applied to that code block Ci to compute another parity check code block Phj.
Example Embodiment 41. The method of Example Embodiment 32, wherein generating the outer coded versions of the N code block groups comprises, for each of the N code block groups, generating each outer coded code block of the outer coded version of the code block group based on contents of all of the code blocks of the code block group.
Example Embodiment 42. The method of Example Embodiment 32, wherein generating the outer coded versions of the N code block groups comprises, for each of the N code block groups, generating each outer coded code block of the outer coded version of the code block group based on contents of less than all of the code blocks of the code block group.
Example Embodiment 43. A method for user equipment (UE) cooperation, the method comprising:
receiving, by a second UE, a transport block comprising m code block groups, m≥2, each code block group comprising a plurality of code blocks;
decoding, by the second UE, the transport block;
subsequent to decoding failing for N code block groups of the transport block, N≤m, receiving, by the second UE from a first UE, at least one code block group of the N failed code block groups, the at least one code block group including less than all m code block groups of the transport block; and
decoding, by the second UE, the at least one code block group of the N failed code block groups based, at least in part, on the at least one code block group received from the first UE.
Example Embodiment 44. The method of Example Embodiment 43, further comprising:
in response to the decoding failing for N code block groups of the transport block, transmitting, from the second UE, a feedback message comprising information identifying at least one failed code block or failed code block group of the N failed code block groups.
Example Embodiment 45. The method of Example Embodiment 43, further comprising:
receiving, by the second UE from the first UE, information identifying the at least one code block group transmitted by the first UE, wherein decoding the at least one code block group of the N failed code block groups is further based, at least in part, on the information identifying the at least one code block group transmitted by the first UE.
Example Embodiment 46. The method of Example Embodiment 45, wherein the information identifying the at least one code block group transmitted by the first UE comprises, for each code block group of the at least one code block group, a code block group index corresponding to the code block group.
Example Embodiment 47. The method of Example Embodiment 46, wherein the information identifying the at least one code block group transmitted by the first UE is included in sidelink control information (SCI) transmitted in a sidelink control channel.
Example Embodiment 48. The method of Example Embodiment 43, wherein receiving the transport block comprises receiving the transport block via a multicast transmission from a third UE or a base station.
Example Embodiment 49. A method for user equipment (UE) cooperation, the method comprising:
receiving, by a second UE, a transport block comprising m code block groups, m≥2, each code block group comprising a plurality of code blocks;
decoding, by the second UE, the transport block;
subsequent to decoding failing for N code block groups of the transport block, N≤m, receiving, by the second UE, at least one outer coded code block based on less than all code block groups of the transport block; and
decoding, by the second UE, at least one code block group of the N failed code block groups based, at least in part, on the at least one outer coded code block received from the first UE.
Example Embodiment 50. The method of Example Embodiment 49, wherein:
the at least one outer coded code block comprises a single outer coded code block based on contents of less than all of the m code block groups of the transport block; an decoding at least one code block group of the N failed code block groups comprises decoding at least one code block group of the N failed code block groups based, at least in part, on the single outer coded code block received from the first UE.
Example Embodiment 51. The method of Example Embodiment 49, wherein:
the at least one outer coded code block comprises, for each code block group of at least a subset of the m code block groups of the transport block, an outer coded version of the code block group based on contents of the code block group; and
decoding, by the second UE, at least one code block group of the N failed code block groups comprises decoding at least one code block group of the N failed code block groups based, at least in part, on the corresponding outer coded version of the code block group received from the first UE.
Example Embodiment 52. The method of Example Embodiment 49, further comprising:
in response to the decoding failing for N code block groups of the transport block, transmitting, from the second UE, a feedback message including information indicating the second UE failed to decode at least one code block or code block group of the transport block.
Example Embodiment 53. The method of Example Embodiment 52, wherein the feedback message comprises information identifying the at least one code block or code block group the second UE failed to decode.
Example Embodiment 54. The method of Example Embodiment 53, wherein the information identifying the at least one code block or code block group comprises, for each code block or code block group the second UE failed to decode, a code block index or code block group index corresponding to the code block or code block group.
Example Embodiment 55. The method of Example Embodiment 53, further comprising:
receiving, by the second UE, a message from the first UE comprising outer coding information identifying, each code block group that the at least one outer coded code block is based on,
wherein decoding at least one code block group of the N failed code block groups is further based on the outer coding information in the message from the first UE.
Example Embodiment 56. The method of Example Embodiment 55, wherein the outer coding information comprises, for each code block group that the at least one outer coded code block is based on, a code block group index corresponding to the code block group.
Example Embodiment 57. The method of Example Embodiment 53, wherein the information indicating the second UE failed to decode at least one code block or code block group of the transport block further comprises information identifying, for each code block group the second UE failed to decode, a quantity of code blocks the second UE failed to decode for the code block group.
Example Embodiment 58. The method of Example Embodiment 57, wherein the at least one outer coded code block comprises, for each of at least a subset of the N code block groups the second UE failed to decode, a quantity of outer coded code blocks based on the contents of the code block group equal to the quantity of code blocks the second UE failed to decode for the code block group.
Example Embodiment 59. The method of Example Embodiment 52, wherein the information indicating the second UE failed to decode at least one code block or code block group of the transport block comprises information identifying a quantity of code blocks the second UE failed to decode for the transport block.
Example Embodiment 60. The method of Example Embodiment 53, wherein the information indicating the second UE failed to decode at least one code block or code block group of the transport block further comprises information identifying a maximum quantity of code blocks the second UE failed to decode for any given code block group of the transport block.
Example Embodiment 61. The method of Example Embodiment 51, further comprising:
in response to decoding failing for a quantity N1 of the outer coded versions of the N code block groups of the transport block, N1≤N, transmitting, from the second UE, a second feedback message comprising information identifying the N1 outer coded versions of the N failed code block groups of the transport block as failed first outer coded versions the second UE has not successfully decoded;
receiving, by the second UE, for each of at least a subset of the N1 failed first outer coded versions, a second outer coded version of the failed code block group based on contents of the at least one outer coded code block of the failed first outer coded version of the failed code block group; and
decoding, by the second UE, at least one code block group of the N failed code block groups based, at least in part, on the second outer coded version of the failed code block group.
Example Embodiment 62. A method performed by a network device, the method comprising:
receiving, by the network device, a transport block comprising m code block groups, m≥2, each code block group comprising a plurality of code blocks;
decoding, by the network device, the transport block;
subsequent to decoding failing for N code block groups of the transport block, N≤m, receiving, by the network device, for each of at least a subset of the N failed code block groups, an outer coded version of the failed code block group, the outer coded version comprising at least one outer coded code block based on contents of the failed code block group; and
decoding, by the network device, at least one code block group of the N code block groups based, at least in part, on the outer coded version of the code block group.
Example Embodiment 63. The method of Example Embodiment 62, further comprising:
in response to the decoding failing for the N code block groups, transmitting, by the network device, a feedback message comprising:
code block group level acknowledgement/negative acknowledgement (ACK/NACK) information identifying the N failed code block groups of the transport block; and
information indicating a maximum quantity of failed code blocks in any given failed code block group of the transport block
Example Embodiment 64. The method of Example Embodiment 63, wherein the feedback message is a first feedback message, and wherein the method further comprises:
in response to decoding failing for a quantity N1 of the outer coded versions of the N failed code block groups of the transport block, N1≤N, transmitting, from the network device, a second feedback message comprising information identifying the N1 outer coded versions of the N failed code block groups of the transport block as failed first outer coded versions the network device has not successfully decoded.
Example Embodiment 65. The method of Example Embodiment 64, further comprising:
receiving, by the network device, for each of at least a subset of the N1 failed first outer coded versions, a second outer coded version of the failed code block group based on contents of the at least one outer coded code block of the failed first outer coded version of the failed code block group; and
decoding, by the network device, at least one code block group of the N failed code block groups based, at least in part, on the second outer coded version of the failed code block group.
Example Embodiment 66. The method of Example Embodiment 62, wherein outer coding applied to at least a subset of the N failed code block groups of the transport block to generate the outer coded versions of the code block groups is selected from the group consisting of: raptor coding, Reed Solomon (RS) coding, parity check coding, and erasure coding.
CONCLUSIONAlthough the present invention has been described with reference to specific features and embodiments thereof, various modifications and combinations can be made thereto without departing from the invention. The description and drawings are, accordingly, to be regarded simply as an illustration of some embodiments of the invention as defined by the appended claims, and are contemplated to cover any and all modifications, variations, combinations or equivalents that fall within the scope of the present invention. Therefore, although the present invention and its advantages have been described in detail, various changes, substitutions and alterations can be made herein without departing from the invention as defined by the appended claims. Moreover, the scope of the present application is not intended to be limited to the particular embodiments of the process, machine, manufacture, composition of matter, means, methods and steps described in the specification. As one of ordinary skill in the art will readily appreciate from the disclosure of the present invention, processes, machines, manufacture, compositions of matter, means, methods, or steps, presently existing or later to be developed, that perform substantially the same function or achieve substantially the same result as the corresponding embodiments described herein may be utilized according to the present invention. Accordingly, the appended claims are intended to include within their scope such processes, machines, manufacture, compositions of matter, means, methods, or steps.
Moreover, any module, component, or device exemplified herein that executes instructions may include or otherwise have access to a non-transitory computer/processor readable storage medium or media for storage of information, such as computer/processor readable instructions, data structures, program modules, and/or other data. A non-exhaustive list of examples of non-transitory computer/processor readable storage media includes magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, optical disks such as compact disc read-only memory (CD-ROM), digital video discs or digital versatile disc (DVDs), Blu-ray Disc™, or other optical storage, volatile and non-volatile, removable and non-removable media implemented in any method or technology, random-access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology. Any such non-transitory computer/processor storage media may be part of a device or accessible or connectable thereto. Any application or module herein described may be implemented using computer/processor readable/executable instructions that may be stored or otherwise held by such non-transitory computer/processor readable storage media.
Claims
1. A method, the method comprising:
- receiving, by a first apparatus, a transport block intended for a second apparatus, the transport block comprising a plurality of code blocks; and
- transmitting, from the first apparatus to the second apparatus, at least one code block based on an outer coded version of the at least one code block of the plurality of code blocks in the received transport block intended for the second apparatus.
2. The method of claim 1, wherein the transmitting the at least one code block comprises:
- transmitting the outer coded version of the at least one code block based on a first set of code blocks, the first set of code blocks being less than all of the plurality of code blocks in the transport block.
3. The method of claim 1, wherein outer coding used to generate the outer coded version of the at least one code block comprises one of: raptor coding, Reed Solomon (RS) coding, parity check coding, or erasure coding.
4. The method of claim 1, further comprising:
- receiving, by the first apparatus from the second apparatus, a feedback message, the feedback message including: information indicating a quantity of one or more code blocks that the second apparatus failed to decode,
- wherein the transmitting the outer coded version of the at least one code block comprises:
- transmitting the quantity of the one or more code blocks that the second apparatus failed to decode based on the feedback message.
5. The method of claim 1, further comprising:
- transmitting, from the first apparatus in sidelink control information (SCI) in a sidelink control channel, at least one of:
- information identifying an index of the at least one code block,
- information identifying a number of outer coded versions of the plurality of code blocks transmitted from the first apparatus, or
- information identifying parameters to generate each of the outer coded versions of the plurality of code blocks transmitted from the first apparatus.
6. The method of claim 1, further comprising:
- receiving, by the first apparatus, a feedback message from the second apparatus including information identifying one or more code blocks that the second apparatus failed to decode for the transport block,
- wherein the at least one code block is selected from among the plurality of code blocks in the transport block based at least in part on the feedback message from the second apparatus.
7. The method of claim 1, further comprising:
- receiving, by the first apparatus, scheduling information from a base station,
- wherein the at least one code block transmitted from the first apparatus is selected from among the plurality of code blocks the transport block based at least in part on the scheduling information from the base station.
8. The method of claim 1, further comprising:
- transmitting, from the first apparatus in sidelink control information (SCI) in a sidelink control channel, information identifying an index of the at least one code block.
9. The method of claim 1, wherein the transport block includes a plurality of code block groups, and each code block group of the plurality of code block groups includes multiple code blocks, the transmitting comprising:
- transmitting, from the first apparatus to the second apparatus, the at least one code block based on at least one code block group of the plurality of code block groups in the transport block.
10. The method of claim 9, the transmitting the at least one code block comprising:
- generating an outer coded code block based on contents of the at least one code block group; and
- transmitting outer coded versions of the at least one code block group to the second apparatus.
11. An apparatus, the apparatus comprising:
- one or more processors; and
- a non-transitory computer readable storage medium storing programming for execution by the one or more processors, the programming including instructions to: receive a transport block intended for a second apparatus, the transport block comprising a plurality of code blocks; and transmit, to the second apparatus, at least one code block based on an outer coded version of the at least one code block of the plurality of code blocks in the received transport block intended for the second apparatus.
12. The apparatus of claim 11, wherein the instructions to transmit the at least one code block include instructions to:
- transmit the outer coded version of the at least one code block based on a first set of code blocks, the first set of code blocks being less than all of the plurality of code blocks in the transport block.
13. The apparatus of claim 11, wherein outer coding used to generate the outer coded version of the at least one code block comprises one of: raptor coding, Reed Solomon (RS) coding, parity check coding, or erasure coding.
14. The apparatus of claim 11, the programming further including instructions to:
- receive, from the second apparatus, a feedback message, the feedback message including: information indicating a quantity of one or more code blocks that the second apparatus failed to decode,
- wherein the instructions to transmit the outer coded version of the at least one code block include instructions to:
- transmit the quantity of the one or more code blocks that the second apparatus failed to decode based on the feedback message.
15. The apparatus of claim 11, the programming further including instructions to:
- transmit, in sidelink control information (SCI) in a sidelink control channel, at least one of:
- information identifying an index of the at least one code block,
- information identifying a number of outer coded versions of the plurality of code blocks transmitted from the apparatus, or
- information identifying parameters to generate each of the outer coded versions of the plurality of code blocks transmitted from the apparatus.
16. The apparatus of claim 11, the programming further including instructions to:
- receive a feedback message from the second apparatus including information identifying one or more code blocks that the second apparatus failed to decode for the transport block,
- wherein the at least one code block is selected from among the plurality of code blocks in the transport block based at least in part on the feedback message from the second apparatus.
17. The apparatus of claim 11, the programming further including instructions to:
- receive scheduling information from a base station,
- wherein the at least one code block transmitted from the apparatus is selected from among the plurality of code blocks the transport block based at least in part on the scheduling information from the base station.
18. The apparatus of claim 11, the programming further including instructions to:
- transmit, in sidelink control information (SCI) in a sidelink control channel, information identifying an index of the at least one code block.
19. The apparatus of claim 11, wherein the transport block includes a plurality of code block groups, and each code block group of the plurality of code block groups includes multiple code blocks, the instructions to transmit the at least one code block including instructions to:
- transmit, to the second apparatus, the at least one code block based on at least one code block group of the plurality of code block groups in the transport block.
20. The apparatus of claim 19, the instructions to transmit the at least one code block including instructions to:
- generate an outer coded code block based on contents of the at least one code block group; and
- transmit outer coded versions of the at least one code block group to the second apparatus.
Type: Application
Filed: Nov 5, 2020
Publication Date: Feb 25, 2021
Patent Grant number: 11496250
Inventors: Yu Cao (Ottawa), Amine Maaref (Ottawa), Jianglei Ma (Ottawa)
Application Number: 17/090,282
