Patent Description:
Automatic repeat request (ARQ) is an error-control method for data transmission that can be applied to improve reliability in a communication system such as a wireless communication system. ARQ protocols typically use acknowledgements and timeouts that allow a transmitter to detect if an error has occurred in respect of a previously transmitted data frame, and retransmit some or all of the data frame if an error is detected. For example, if a transmitter does not receive an expected acknowledgement (Ack) within a specified timeout period in respect of a transmitted data frame, the transmitter will determine an error has occurred and retransmit some or all of the previously transmitted data frame. Some ARQ protocols may also rely on negative acknowledgment (Nack) messages sent by a receiver that specify that an error has occurred.

ARQ protocols are specified as medium access control (MAC) procedures in networks that operate according to Wi-Fi protocols such as IEEE <NUM>. 11a/n/ac/ad [IEEE std <NUM>™-<NUM>], IEEE <NUM>. 11ax [<NUM>. <NUM>], IEEE <NUM>. 11ay [<NUM>. For example, IEEE std <NUM>™-2016specifies an ARQ protocol for the transmission of a physical layer (PHY) protocol data unit (PPDU) that embeds a single MAC protocol data unit (MPDU), and also for the transmission of an aggregate-MPDU (A-MPDU) PPDU that embeds multiple MPDUs. In the case of a single-MPDU PPDU transmitted with an Ack requirement, a receiving station that successfully receives the MPDU (with success being determined based on a frame check sequence (FCS)) will transmit an Ack frame following a defined short inter-frame space (SIFS). The transmitting station will interpret a failure to receive a valid Ack frame within a specified timeout period as failure of the MPDU transmission. The transmitting station may then retransmit the MPDU. In the case of an A-MPDU PPDU, the receiving station determines the success of each MPDU individually based on respective FCSs and then transmits a BlockAck frame that includes a Block Ack bitmap that specifies a decoding error status (e.g. successful or unsuccessful) for each of the MPDUs. Upon receiving a BlockAck frame in response to a transmitted A-MPDU PPDU, the transmitting station may requeue and retransmit data from any MPDUs that were indicated in the Block Ack bitmap as unsuccessful.

Forward error correction (FEC) is a further error-control method for data transmission that can be applied to improve reliability in a communication system such as a wireless communication system. Although ARQ methods suffer from decreasing throughput as channel error rate increases, the throughput of FEC methods for a given code rate is not substantially changed as channel error rate increases. The combination of ARQ and FEC, known as hybrid ARQ (HARQ), has been adopted or considered in wireless network systems, including for example 3rd Generation Partnership Project (3GPP) <NUM>th Generation (<NUM>) Long Term Evolution LTE) [3GPP TS <NUM> v12. <NUM>] and 5th Generation (<NUM>) New Radio (NR) [3GPP TS <NUM> v15. Further development of HARQ error-control methods, including methods for use in wireless local area network (WLAN) systems such as Wi-Fi, is desirable.

<CIT> concerns coding and retransmission schemes including variations to HARQ feedback techniques for broadband wireless communication networks. A first codeword is obtained by encoding an information block according to a first parity-check matrix. A portion of the first codeword is transmitted to a remote device. A second codeword is obtained by encoding the information block according to a second parity-check matrix. A portion of the second codeword is transmitted to the remote device for soft-combining decoding. According to <CIT>, a LAN device receives a data frame with a hybrid automatic repeat request (HARQ) data indicator in a frame header. The WLAN device sends an acknowledgement frame when the data frame is correctly received and decoded. The WLAN device sends a negative acknowledgement frame when the data frame is not correctly received and decoded. <NPL>) discloses that using a different interleaver when retransmitting is beneficial.

Particularly advantageous embodiments are specified by the dependent claims.

According to a first example aspect is a method of transmitting data. The method includes: segmenting a group of information bits into a set of information blocks that each include a respective plurality of the information bits; encoding, using low density parity check (LDPC) encoding, each of the information blocks to generate corresponding codewords; transmitting the codewords to a destination station; receiving a feedback message indicating that at least one of the codewords has not been successfully decoded by the destination station; interleaving the information bits of the information block that corresponds to the at least one of the codewords; encoding, using low density parity check (LDPC) encoding, the interleaved information bits to generate an interleaved codeword; and transmitting the interleaved codeword to the destination station.

The inventive method includes selecting an interleaver to use for the interleaving based on an LDPC code used for the LDPC encoding. No interleaving is selected for a first retransmission, a row-column block interleaver configuration is selected for a second retransmission, and a further row-column block interleaver configuration is selected for a third retransmission. In some example, the method includes selecting an interleaver to use for the interleaving based on a number of times the information bits of the information block that corresponds to the at least one codeword have been previously included in codewords sent to the destination station. In some examples, interleaving the information bits comprises applying row-column block interleaving to the information bits by writing the information bits into an M row by N column matrix in a first order and reading the information bits out of the matrix in a second order, wherein M* N is equal to the number of information bits. In some examples, N =<NUM>, and the information bits are written into the matrix on a row-by-row basis and read out of the matrix on a column-by-column basis. In some examples, interleaving the information bits comprises applying circular permutation interleaving.

In some example embodiments of the first example aspect, the feedback message includes a codeword bitmap field containing a decoding status bit for each codeword indicating whether the codeword was successfully decoded.

According to a second example aspect is a station configured to perform the method of the first example aspect. In an example embodiment, the station is for use in a wireless area local area network (WLAN), and configured to: segment a group of information bits into a set of information blocks that each include a respective plurality of the information bits; encode, using low density parity check (LDPC) encoding, each of the information blocks to generate corresponding codewords; transmit the codewords to a destination station; receive a feedback message indicating that at least one of the codewords has not been successfully decoded by the destination station; interleave the information bits of the information block that corresponds to the at least one of the codewords; encode, using low density parity check (LDPC) encoding, the interleaved information bits to generate an interleaved codeword; and transmit the interleaved codeword to the destination station.

According to a third example aspect is a method for decoding codewords at a station of a wireless local area network (WLAN). The method includes: receiving at the station, through a wireless medium, a first packet that includes a plurality of low density parity check (LDPC) encoded codewords; and transmitting a feedback message that includes a codeword bitmap field containing a decoding status bit for each codeword indicating whether the codeword was successfully decoded.

The method further includes, after transmitting the message, receiving at the station, through the wireless medium, a second packet including an LDPC encoded codeword generated at a source station by interleaving the information bits used to generate a corresponding codeword included in the first packet and indicated in the message as having an unsuccessful decoding status; and decoding the LDPC codeword included in the second packet. The LDPC encoded codeword is interleaved at least based on a retransmission iteration. No interleaving is selected for a first retransmission, a row-column block interleaver configuration is selected for a second retransmission, and a further row-column block interleaver configuration is selected for a third retransmission.

In some example embodiments of the third example aspect, the feedback message includes a frame that includes, in the following order: a frame control field, a duration field, the codeword bitmap field, and a frame check sequence (FCS) field. In some examples, the frame control field and the duration field each have a size of <NUM> octets, the codeword bitmap field has a size of <NUM> octets, and the FCS field has a size of <NUM> octets.

In some example embodiments of the third example aspect, the feedback message comprises a frame that includes, in the following order: a frame control field, a duration field, a receiver address field, the codeword bitmap field and a frame check sequence (FCS) field. In some examples the frame control field and the duration field each have a size of <NUM> octets, the receiver address field has a size of <NUM> octets, the codeword bitmap field has a size of <NUM> octets, and the FCS field has a size of <NUM> octets. In some examples, the codeword bitmap field has a size greater than <NUM> octets.

In some example embodiments of the third example aspect, the method includes, after transmitting the message, receiving at the station, through the wireless medium, a second packet including an LDPC encoded codeword generated at a source station by interleaving the information bits used to generate a corresponding codeword included in the first packet and indicated in the message as having an unsuccessful decoding status; and decoding the LDPC codeword included in the second packet.

In some examples, decoding the LDPC codeword included in the second packet includes combing information from LDPC codeword included in the second packet with information from the corresponding codeword included in the first packet.

In some example embodiments of the third example aspect, combining information includes soft combining log-likelihood ratio (LLR) values obtained in respect of information bits included in the LDPC codeword included in the second packet with LLR values obtained in respect of corresponding information bits included the corresponding codeword included in the first packet. In some examples, combining information includes concatenating the soft combined LLR values for the information bits with values obtained in respect of parity check bits included in the LDPC codeword included in the second packet. In some examples, combining information includes concatenating the soft combined LLR values for the information bits with values obtained in respect of parity check bits included in the LDPC codeword included in the first packet.

In some example embodiments of the third example aspect, combining information includes: soft combining channel bit values obtained in respect of information bits included in the LDPC codeword included in the second packet with channel bit values obtained in respect of corresponding information bits included the corresponding codeword included in the first packet. In some examples, combining information includes concatenating the soft combined channel bit values for the information bits with values obtained in respect of parity check bits included in the LDPC codeword included in the second packet. In some examples, combining information includes concatenating the soft combined channel bit values for the information bits with values obtained in respect of parity check bits included in the LDPC codeword included in the first packet.

According to a fourth example aspect is a station enabled for use in a wireless area local area network (WLAN) and configured to perform the method of the third example aspect.

In at least some configurations, some of the example aspects may mitigate against patterns in the codeword bits that could fall into trapping sets or improve the reliability of retransmission data provided to a decoder, or both, improving one or both of efficiency and accuracy in a communication system.

Reference will now be made, by way of example, to the accompanying figures which show example embodiments of the present application, and in which:.

Like reference numerals are used throughout the Figures to denote similar elements and features. While aspects of the invention will be described in conjunction with the illustrated embodiments, it will be understood that it is not intended to limit the invention to such embodiments.

The present disclosure teaches methods, devices, and systems for retransmitting data in a wireless network. Next generation WLAN systems, including for example next generation Wi-Fi systems, will require higher data rates and higher reliability than prior generation systems. HARQ error control methods may help achieve high data rate and reliability goals. As noted above, HARQ error control includes a combination of ARQ and FEC error control methods. In at least some Wi-Fi systems (for examples IEEE <NUM>/n/ac/ax compliant systems), low-density parity-check (LDPC) codes are employed for FEC. Example embodiments of a HARQ error control method are presented in this disclosure that combine LPDC code based FEC error control procedures with Nack error control procedures in a WLAN system.

An example of an environment in which the error control procedures described below can operate will be provided with reference to <FIG> and <FIG>. <FIG> illustrates a communication network <NUM> comprising a plurality of stations (STAs) that can include fixed, portable, and moving stations. The example of <FIG> illustrates a single fixed STA, accesspoint station (AP-STA) <NUM>, and a plurality of STAs <NUM> that may be portable or mobile. Each of the STAs <NUM> and AP-STA <NUM> may include a transmitter, a receiver, an encoder, a decoder, a modulator, and/or demodulator as described herein. The network <NUM> may operate according to one or more communications or data standards or technologies, however in at least some examples the network <NUM> is a WLAN, and in at least some examples is a next generation Wi-Fi compliant network that operates in accordance with one or more protocols from the <NUM> family of protocols.

Each STA <NUM> may be a laptop, a desktop PC, PDA, Wi-Fi phone, wireless transmit/receive unit (WTRU), mobile station (MS), mobile terminal, smartphone, mobile telephone, sensor, internet of things (IOT) device, or other wireless enabled computing or mobile device. In some embodiments, a STA <NUM> comprises a machine which has the capability to send, receive, or send and receive data in the communications network <NUM> but which performs primary functions other than communications. In some embodiments, a machine includes an apparatus or device with means to transmit and/or receive data through the communications network <NUM> but such apparatus or device is not typically operated by a user for the primary purpose of communications. The AP-STA <NUM> may comprise a network access interface which functions as a wireless transmission and/or reception point for STAs <NUM> in the network <NUM>. The AP-STA <NUM> may be connected to a backhaul network <NUM> which enables data to be exchanged between the AP-STA <NUM> and other remote networks (including for example the Internet), nodes, APs, and devices (not shown). The AP-STA <NUM> may support communications through unlicensed radio frequency spectrum wireless medium <NUM> with each STA <NUM> by establishing uplink and downlink communications channels with each STA <NUM>, as represented by the arrows in <FIG>. In some examples, STAs <NUM> may be configured to communicate with each other. Communications in the network <NUM> may be unscheduled, scheduled by the AP-STA <NUM> or by a scheduling or management entity (not shown) in the network <NUM>, or a mix of scheduled and unscheduled communications.

<FIG> illustrates an example processing system <NUM>, which may be used to implement methods and systems described herein, such as the STA <NUM> or the AP-STA <NUM>. Other processing systems suitable for implementing the methods and systems described in the present disclosure may be used, which may include components different from those discussed below. Although <FIG> shows a single instance of each component, there may be multiple instances of each component in the processing system <NUM>.

The processing system <NUM> may include one or more processing devices <NUM>, such as a processor, a microprocessor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a dedicated logic circuitry, or combinations thereof. The processing system <NUM> may also include one or more input/output (I/O) interfaces <NUM>, which may enable interfacing with one or more appropriate input devices and/or output devices (not shown). One or more of the input devices and/or output devices may be included as a component of the processing system <NUM> or may be external to the processing system <NUM>. The processing system <NUM> may include one or more network interfaces <NUM> for wired or wireless communication with a network. In example embodiments, network interfaces <NUM> include one or more wireless transceivers that enable communications in a WLAN such as network <NUM>. Network interfaces <NUM> may also include interfaces for wired or wireless communication with networks, such as but not limited to, an intranet, the Internet, a P2P network, a WAN, LAN, and/or a cellular or mobile communications network such as a <NUM> NR, <NUM> LTE or other network as noted above. The network interface(s) <NUM> may include interfaces for wired links (e.g., Ethernet cable) and/or wireless links (e.g., one or more radio frequency links) for intra-network and/or inter-network communications. The network interface(s) <NUM> may provide wireless communication via one or more transmitters or transmitting antennas, one or more receivers or receiving antennas, and various signal processing hardware and software, for example. In this regard, some network interface(s) <NUM> may include respective processing systems that are similar to processing system <NUM>. In this example, a single antenna <NUM> is shown, which may serve as both transmitting and receiving antenna. However, in other examples there may be separate antennas for transmitting and receiving. The network interface(s) <NUM> may be configured for sending and receiving data to the backhaul network <NUM> or to other STAs, user devices, access points, reception points, transmission points, network nodes, gateways or relays (not shown) in the network <NUM>.

The processing system <NUM> may also include one or more storage units <NUM>, which may include a mass storage unit such as a solid state drive, a hard disk drive, a magnetic disk drive and/or an optical disk drive. The processing system <NUM> may include one or more memories <NUM>, which may include a volatile or non-volatile memory (e.g., a flash memory, a random access memory (RAM), and/or a read-only memory (ROM)). The non-transitory memory(ies) <NUM> may store instructions for execution by the processing device(s) <NUM>, such as to carry out the present disclosure. The memory(ies) <NUM> may include other software instructions, such as for implementing an operating system and other applications/functions. In some examples, one or more data sets and/or module(s) may be provided by an external memory (e.g., an external drive in wired or wireless communication with the processing system <NUM>) or may be provided by a transitory or non-transitory computer-readable medium. Examples of non-transitory computer readable media include a RAM, a ROM, an erasable programmable ROM (EPROM), an electrically erasable programmable ROM (EEPROM), a flash memory, a CD-ROM, or other portable memory storage.

In example embodiments the processing system <NUM> includes one or more encoders <NUM> for encoding source words to codewords and a modulator <NUM> for modulating codewords to symbols. As explained below, the encoder <NUM> performs LDPC encoding on source words to generate codewords in bits. The modulator <NUM> performs modulation on the codewords (e.g., by modulation techniques such as BPSK, QPSK, 16QAM, or 64QAM). In some examples, instructions coded in the memory <NUM> may configure processing device <NUM> to perform the functions of the encoder <NUM> and/or the modulator <NUM>, such that the encoder <NUM> and/or the modulator <NUM> may not be distinct physical modules of the processing system <NUM>. In some examples, the encoder <NUM> and the modulator <NUM> may be embodied within a transmitter module that is part of a network interface <NUM> of the processing system <NUM>. In some examples, the transmitting antenna <NUM>, the encoder <NUM>, and the modulator <NUM> may be embodied as a transmitter component external to the processing system <NUM>, and may simply communicate the source words from the processing system <NUM>.

The processing system <NUM> may include a demodulator <NUM> and one or more decoders <NUM> for processing a received signal. The demodulator <NUM> may perform demodulation on a received modulated signal (e.g., a BPSK, QPSK, 16QAM, or 64QAM signal). The decoder <NUM> may then perform appropriate decoding on the demodulated signal, in order to recover the original source words contained in the received signal. In some examples, instructions coded in the memory <NUM> may configure processing device <NUM> to perform the functions of the demodulator <NUM> and/or the decoder <NUM>, such that the demodulator <NUM> and/or the decoder <NUM> may not be distinct physical modules of the processing system <NUM>. In some examples, the demodulator <NUM> and the decoder <NUM> may be embodied within a receiver module of a network interface <NUM> of the processing system <NUM>. In some examples, the receiving antenna <NUM>, demodulator <NUM> and decoder <NUM> may be embodied as a receiver component external to the processing system <NUM>, and may simply communicate the signal decoded from the received signal to the processing system <NUM>.

There may be a bus <NUM> providing communication among components of the processing system <NUM>, including the processing device(s) <NUM>, I/O interface(s) <NUM>, network interface(s) <NUM>, storage unit(s) <NUM>, memory(ies) <NUM>, encoder <NUM>, modulator <NUM>, demodulator <NUM> and decoder <NUM>. The bus <NUM> may be any suitable bus architecture including, for example, a memory bus, a peripheral bus or a video bus.

In example embodiments, communications between STAs, including for example between a STA <NUM> and the AP-STA <NUM>, in the network <NUM> may be implemented by encoding source words using low density parity check (LDPC) encoding techniques to generate codewords. The codewords resulting from LDPC encoding of respective source words are embedded in packets that are modulated and transmitted over a wireless medium between AP-STA <NUM> and STA <NUM>. In example embodiments, the physical layer packet structure used for communications in network <NUM> corresponds to the PPDU packet structure defined in IEEE std <NUM>™-<NUM>, an example of which is shown in <FIG>. In this regard, the PPDU <NUM> packet structure can include several fields that respectively include PHY preamble (synchronization information <NUM> and channel estimation information <NUM>), PHY header information <NUM>, and a PHY payload <NUM>. The PHY payload <NUM> can be embedded with an encoded MPDU <NUM> or an A-MPDU <NUM>.

As illustrated in <FIG>, an MPDU <NUM> includes respective fields for MAC header information <NUM>, a MAC service data unit (MSDU) <NUM> and an FCS <NUM>. The FCS <NUM> includes a frame check sequence determined for the combined content of the MAC header information <NUM> and MSDU <NUM>. An A-MPDU <NUM> includes multiple MPDUs <NUM>. In particular, an A-MPDU includes A-MPDU subframes <NUM>(<NUM>) to <NUM>(n), followed by end of frame padding (EOF) <NUM>. Each A-MPDU subframe <NUM>(i) includes respective fields for an MPDU delimiter <NUM>, MPDU <NUM>, and padding <NUM>.

<FIG> illustrates, according to example embodiments, source actions <NUM> performed by a source station (for example AP-STA <NUM>) and destination actions <NUM> performed by a destination station (for example a STA <NUM>), in respect of codewords (included for example in a PPDU <NUM>) transmitted through wireless medium <NUM>. Although AP-STA <NUM> is illustrated as the source station and STA <NUM> is illustrated as the destination station in the present example, the roles can be reversed and furthermore, in some embodiments the destination station and source station may be two respective STAs <NUM> communicating with each other.

As illustrated in <FIG>, AP-STA <NUM> is configured to generate and transmit a PPDU <NUM> including one or more sets of LDPC codewords b<NUM> to bNCW (Action <NUM>) which are obtained by LDPC-encoding one or more MPDUs <NUM>. In this regard, <FIG> illustrates an example of an encoding procedure <NUM>, which may for example be performed at an encoder <NUM> of the AP-STA <NUM>, for generating a set of codewords b<NUM> to bNCW for inclusion in a PPDU <NUM>. In example embodiments, encoding procedure <NUM> can be the same as known procedures used to generate LDPC codewords for a PPDU <NUM> that is compliant with IEEE std <NUM>™-<NUM>. In this regard, data bits (e.g. the bits that make up MPDU <NUM>, or an A-MPDU <NUM>) are subjected to scrambling, shortening and segmenting <NUM>, resulting in a set of information blocks IB<NUM> to IBNCW that are each k-bits in length. In the example of <FIG>, the information blocks IB<NUM> to IBNCW are used as respective k-bit source words s<NUM> to SNCW that are each subjected to LDPC encoding <NUM>, resulting in respective n-bit codewords b<NUM> to bNCW. In the present description, the subscript "j" is used to denote a generic information block IBj, source word sj, and codeword bj where <NUM>≤j≤NCW.

In example embodiments, the LDPC encoding <NUM> applied in example embodiments uses LDPC codes that are specified in one or more of the IEEE <NUM>. 11n/ac/ax protocols, including for example the code rates and codeword block sizes specified in Sec. <NUM> of IEEE std <NUM>™-2016and the parity check matrices specified in Sec. <NUM> of IEEE std <NUM>™-<NUM>.

Accordingly, in encoding procedure <NUM>, the data bits that are to be included in the PSDU <NUM> of PPDU <NUM> are segmented into Ncw information blocks IB<NUM> to IBNCW, which correspond to Ncw k-bit source words s<NUM> to sNCW. Each k-bit source word sj may be considered as a <NUM> x k row vector or a one-dimensional binary <NUM> x k matrix sj = [s<NUM>,. Each k-bit source word sj is then encoded to respective n-bit codeword bj = [b<NUM>,. ,bn] by multiplying the source word with a generator matrix G (e.g. b= s·G). The n-bit codeword bj includes k information bits and n-k parity check bits. In example embodiments, known procedures for generating LDPC codewords from source words using generator matrix G can be applied to perform LDPC encoding <NUM>.

Codewords b<NUM> to bNCW may each be subjected to respective puncturing and repeating operations <NUM>, and combined into a bitstream for inclusion in a PPDU <NUM>. The codewords b<NUM> to bNCW in a PPDU <NUM> are modulated onto an RF signal <NUM> and transmitted to destination STA <NUM>. As noted above, in some examples, PPDU <NUM> payload <NUM> may include a set of codewords generated from a single MPDU <NUM>, and in some examples PPDU <NUM> payload <NUM> may include multiple codewords generated from multiple MPDUs <NUM> aggregated into an A-MPDU <NUM>. The encoding procedure <NUM> is performed in the same manner as described above to generate a set of codewords for the bits in A-MPDU <NUM>.

Referring again to <FIG>, destination STA <NUM> is configured to receive a signal modulated with the PPDU <NUM> (Action <NUM>) transmitted by source AP-STA <NUM> and decode the received codewords b<NUM>T to bNCWT embedded in the PPDU <NUM> (Action <NUM>) (superscript "T" denotes a codeword received at the destination STA <NUM> after passing through a channel of wireless medium <NUM>). By way of example, <FIG> is a block diagram representation of demodulator <NUM> and decoder <NUM> of destination STA <NUM>. In example embodiments, the received signal <NUM> is equalized to reduce intersymbol interference caused by the RF channel, and demodulated by demodulator <NUM> to generate an initial set of soft channel bit values for each of the codewords b<NUM>T to bNCWT. In example embodiments, decoder <NUM> applies known procedures for decoding LDPC codewords b<NUM>T to bNCWT. As known in the art, decoding is performed based on the parity check matrix H and Tanner graph corresponding to the generator matrix G applied at the transmitting source to generate LDPC codewords b<NUM> to bNCW. In this regard, Decoder <NUM> includes a log-likelihood ratio (LLR) calculator <NUM> that is configured to calculate LLR values for each of the soft channel bits of a codeword bjT, which are initially assigned to the corresponding variable nodes of the Tanner graph during the decoding. An LDPC decoder <NUM> then applies an iterative message passing algorithm (MPA) based on the log-likelihood ratio (LLR) values to either successfully decode the codeword bjT and recover the source word sj, or determine that the codeword bjT cannot be successfully decoded. As known in the art, a received codeword bjT is determined to be valid (e.g. successfully decoded) if the codeword bjT, after decoding, can satisfy H•bjT=<NUM>. In example embodiments, decoder <NUM> provides a decoding status for each of the codewords b<NUM>T to BNCW T in the received PPDU <NUM>, based on the validity of each codeword after decoding. In particular, the decoding status for each codeword b<NUM>T to bNCWT can be either: (a) successfully decoded or (b) unsuccessfully decoded.

As noted above, each set of codewords b<NUM>T to bNCWT corresponds to a MPDU <NUM>, and thus the recovered source words obtained from decoding the codewords b<NUM>T to bNCWT correspond to the bits of an MPDU <NUM>, which as indicated above includes a MAC header <NUM>, an MSDU <NUM>, and an FCS <NUM>. In example embodiments, the decoder <NUM> is configured to determine a decoding status for the MPDU <NUM> based on whether an FCS calculated at the destination STA <NUM> in respect of the bits of the recovered MAC header <NUM> and MSDU <NUM> bits matches the recovered FCS <NUM>. Accordingly, in example embodiments, decoder <NUM> provides a decoding status for MPDU <NUM> recovered from the received PPDU <NUM>, along with the a decoding status for each of the codewords b<NUM>T to bNCWT that correspond to each MPDU <NUM>.

In example embodiments, the destination STA <NUM> is configured to store the interim and final decoding results for any codewords b<NUM>T to bNCWT that are unsuccessfully decoded and thus labelled as unsuccessfully decoded. By way of example, destination STA <NUM> may provide a codeword decoding log that identifies, for each unsuccessfully decoded codeword bjT, one or both of: the soft channel bit values output by demodulator <NUM>; and the LLR values output by LLR calculator <NUM>. The soft bit LDPC decoding values generated during the iterations of the MPA performed by LDPC decoder <NUM> may also be stored. As described in greater detail below, in example embodiments, these values can be combined with corresponding values generated in respect of retransmitted codewords to assist in decoding of the retransmitted codewords.

Referring again to <FIG>, in example embodiments, as indicated in Action <NUM>, the destination STA <NUM> is configured to generate and send a feedback message <NUM> modulated on an RF signal <NUM> back to the source AP-STA <NUM> after a SIFS duration following the transmission of PPDU <NUM>. In example embodiments, the type of feedback message <NUM> sent and the content of the feedback message <NUM> are based on a determination of whether (i) the decoding results are completely successful, or (ii) the decoding results include some errors. Accordingly, in some example embodiments, if the FCS decoding status for all MPDUs <NUM> indicates successful decoding, the destination STA <NUM> is configured to send a feedback message <NUM> using an Ack frame format that will be interpreted by the source AP-STA <NUM> as indicating complete decoding success. In some examples, the Ack frame format indicating successful decoding is identical to the Ack frame format specified in Sec <NUM>. <NUM> of IEEE std <NUM>™-<NUM>,and includes the following fields in the following order: <NUM> octet frame control field; <NUM> octet duration field; <NUM> octet receiver address (RA) field; and <NUM> octet FCS field.

In some examples, in the case where the FCS decoding status in respect of at least one MPDU indicates that an error has occurred, the feedback message <NUM> uses a HARQ frame format to provide a negative acknowledgement (Nack) message to the source AP-STA <NUM>. In example embodiments, different types of HARQ frame formats are used for Nack-type feedback messages <NUM> in respect of PPDUs <NUM> that include a single MPDU <NUM> and PPDUs <NUM> that includes an A-MPDU <NUM>. Examples of HARQ frame formats used to acknowledge a PPDU <NUM> that embeds a single MPDU <NUM> will be described first with respect to <FIG>.

<FIG> shows the frame format of a HARQ frame 600A that can be modulated on an RF signal <NUM> in a first example embodiment as feedback message <NUM> to provide feedback from the destination STA <NUM> to the source AP-STA <NUM>. HARQ frame 600A has a frame format that is identical to the format specified for a clear-to-send (CTS) frame in Sec. <NUM> of IEEE std <NUM>™-<NUM>,with the exception that the receiver address (RA) field of the MAC header of the CTS frame is replaced with a codeword (CW) Bitmap field. Accordingly, as shown in <FIG>, the frame format for HARQ frame 600A has a length of <NUM> octets divided into the following fields: <NUM> octet "Frame control" field for frame control information; <NUM> octet "Duration" field; <NUM> octet "CW Bitmap" field and a <NUM> octet FCS field. The CW Bitmap is used to specify the decoding status for each received codeword b<NUM>T to bNCWT. For example, each received codeword b<NUM>T to bNCWT can have a respective bit location allocated to it in the CW Bitmap, with a bit value of "<NUM>" in the location allocated to a codeword bjT indicating that the codeword bjT has been successfully decoded and a bit value of "<NUM>" in the location allocated to a codeword bjT indicating that the codeword bjT has been unsuccessfully decoded. It will be appreciated that a <NUM> octet "CW Bitmap" field includes <NUM> bits, thus allowing the decoding status for up to <NUM> codewords to be indicated. Accordingly, in the illustrated example, NCW ≤ <NUM>. In example embodiments, multiple HARQ frames may be used if the number of codewords is greater than <NUM>. In an example embodiment, the Duration field is used for an estimated duration value for the total time required for: (i) transmission of pending data including any codewords to be retransmitted, which are identified in the CW Bitmap as being unsuccessfully decoded, and any new data to be transmitted from the source AP-STA <NUM> to the destination STA <NUM>; (ii) a further HARQ or Ack frame to be transmitted; and (iii) two SIFS.

The HARQ frame 600A has the same length, <NUM> octets, as the current Ack frame format specified in Sec. <NUM> IEEE std <NUM>™-<NUM>. The use of a HARQ frame that is the same size as an Ack frame may in some examples facilitate an accurate estimation of the Duration time that is included in the Duration field.

<FIG> shows the frame format of a HARQ frame 600B that can be modulated on RF signal <NUM> in a second example embodiment of feedback message <NUM> to provide feedback from the destination STA <NUM> to the source AP-STA <NUM>. HARQ frame 600B has a frame format that longer than the <NUM> octet length of the current Ack frame format specified in Sec. <NUM> of IEEE std <NUM>™-<NUM>. In one example embodiment, HARQ frame 600B is identical to the format specified for a request-to-send (RTS) frame in Sec. <NUM> of IEEE std <NUM>™-<NUM> , with the exception that the sender or transmitter address (TA) field of the MAC header of the RTS frame is replaced with codeword (CW) Bitmap field. Accordingly, as shown in <FIG>, in an example embodiment the frame format for HARQ frame 600B has a length of <NUM> octets divided into the following fields: <NUM> octet "Frame control" field; <NUM> octet "Duration" field; <NUM> octet "receiver address (RA)" field; <NUM> octet "CW Bitmap" field and a <NUM> octet FCS field.

In an example embodiment, the respective fields are used as follows: (A) Frame control field: the Frame control field includes Type and Subtype subfields that indicate that HARQ frame 600B is type of control frame that is not currently specified in IEEE std <NUM>™-<NUM>, namely a Control frame - "HARQ" (e.g., combination of Type value B3 B2=<NUM> and Subtype value B7 B6 B5 B4=<NUM> in Frame control field indicates a "HARQ" type frame). (B) Duration field: the duration field includes a duration value is the total estimated time required for: (i) transmission of a pending data including any codewords to be retransmitted, which are identified in the CW Bitmap as being unsuccessfully decoded and new data to be transmitted from the source AP-STA <NUM> to the destination STA <NUM>; (ii) a further HARQ frame or Ack frame to be transmitted; and (iii) two SIFS. (C) RA field: the RA field is the same as that defined for the Ack frame format specified in Sec. <NUM> of IEEE std <NUM>™-<NUM> (i.e. address of the nonbandwidth signaling TA from the Address <NUM> field of the immediately previous individually addressed data frames - e.g., the address of source AP-STA <NUM> in the present example). ) (D) FCS field: specifies an FCS calculated over all of the fields of the MAC header and the Frame Body field (for example, as specified in Sec. <NUM> of IEEE std <NUM>™-<NUM>). (E) CW Bitmap field: provides a bit map indication of the decoding status of each of the codewords b<NUM>T to bNCWT decoding status, e.g. "<NUM>" means the codeword was successfully decoded; "<NUM>" means the codeword was unsuccessfully decoded.

As indicated above, the CW Bitmap field of HARQ frame 600B has a length of <NUM> octets, thus allowing the decoding status for up to <NUM> codewords to be indicated. In some examples, an alternative format may be used for HARQ frame 600B in which the CW Bitmap field has a length greater than <NUM> octets, for example K octets, where K is greater than or equal to <NUM>, and the value of K is specified or selected based on the number of codewords. In some examples, the destination STA <NUM> may by configured to use HARQ frame 600B with a <NUM>-octet CW Bitmap field, and in some examples STA <NUM> will use a HARQ frame 600B with a K-octet CW Bitmap field when NCW ≤<NUM>*K.

In some example embodiments, the source station AP-STA <NUM> and destination station STA <NUM> may be configured to also use HARQ frame 600A or 600B instead of an Ack frame to indicate a completely successful decoding. In such cases, CW Bitmap field of the HARQ frame 600A or 600B will be set to indicate a successful decoding for all received codewords. Accordingly, in example embodiments, a HARQ frame 600A or 600B can function as an Ack frame (e.g. CW Bitmap set to indicate all codewords are successfully decoded) and as a Nack Frame (e.g. at least some bits in CW Bitmap indicate unsuccessfully decoded codewords).

In some cases, a situation may occur in where all codewords are successfully decoded at destination STA <NUM>, however the FCS decoding status does not pass, and in some examples the destination STA <NUM> is configured to respond to such situations by not sending any feedback message <NUM>. As specified in existing IEEE Std <NUM>™-<NUM>, if the source STA does not receive an acknowledgement within a timeout period, it interprets that a failure of PPDU transmission has occurred and may retransmit the PPDU.

An example format used for a HARQ-type frame in feedback message <NUM> to acknowledge a PPDU <NUM> that includes an A-MPDU <NUM> having MPDUs <NUM> will be described with respect to <FIG>, which shows the frame format of a BlockAck_CW frame <NUM> that can be modulated on RF signal <NUM>. <NUM> of IEEE std <NUM>™-2016specifies a frame format for a BlockAck frame <NUM> that includes a Block Ack (BA) Bitmap subfield in a BA Information field. The Block Ack Bitmap subfield includes <NUM> bits which can indicate the status of up to <NUM> aggregated MPDUs, based on the FCS fields of those MPDUs. In example embodiments, BlockAck_CW frame <NUM> has a similar format to that specified in Sec. <NUM> of IEEE std <NUM>™-2016for a BlockAck frame, however the BA Information field is extended to include CW Bitmap subfields for each of the MPDUs, as described below.

As shown in <FIG>, the frame format for BlockAck_CW frame <NUM> includes the following fields: <NUM> octet "Frame control" field; <NUM> octet "Duration" field; <NUM> octet "receive address (RA)" field; <NUM> octet "transmit address (TA)" field; <NUM> octet "BA control" field; K' octet "BA_CW Information" field (K' ≥ <NUM>) and a <NUM> octet FCS field. In BlockAck_CW frame <NUM>, the respective fields are used as follows: (A) Frame control field: includes Type and Subtype subfields that indicate frame type. (B) Duration field: specifies a duration value for the estimated time for an Ack frame or BlockAck_CW frame plus a SIFS. (C) RA field: address of the station that the BlockAck_CW frame <NUM> is being sent to. (D) TA field: address of the station transmitting the BlockAck_CW frame <NUM>. (E) BA control field: identifies the BlockAck CW frame variant, which in turn species the format used for the BA-CW information. (F) FCS field: specifies an FCS calculated over all of the previous fields (including the BA-CW information field). (G) BA_CW Information Field: includes a <NUM> octet Block Ack Starting Sequence control sub-field and <NUM> octet Block Ack Bitmap sub-field, as well as a CW Bitmap subfield for the codewords of all MPDUs. The Block Ack Starting Sequence control sub-field and Block Ack Bitmap sub-field perform the same function as the specified in Sec. <NUM> of IEEE std <NUM>™-2016for a BlockAck frame. The CW Bitmap subfield includes a CW bitmap that specifies a decoding status for each codeword included in the MPDUs embedded in the received PPDU <NUM>.

Referring again to <FIG>, and in particular to source actions <NUM> performed at source AP-STA <NUM>, after transmitting the PPDU <NUM> the source AP-STA <NUM> is configured to wait for a feedback message <NUM> from the destination STA <NUM> that indicates a decoding status for each of the codewords b<NUM> to bNCW included in the PPDU <NUM>. The feedback message <NUM> may, in various examples, take the form of an Ack frame, HARQ frame 600A, or HARQ frame 600B (with <NUM> octet or K-octet CW Bitmap field length) in the case of a PPDU <NUM> that included a single MPDU <NUM>, or a BlockAck_CW frame <NUM> in the case of a PPDU <NUM> that included multiple aggregated MPDUs <NUM>. As indicated by Action <NUM>, the source AP-STA <NUM> is configured to wait a defined time-out period for the feedback message <NUM>. In example embodiments, if the feedback message <NUM> is not received within the time-out period, the source AP-STA <NUM> determines that the transmission of PPDU <NUM> was a complete failure and returns to Action <NUM> to retransmit the entire PPDU <NUM> over again.

In example embodiments, if the feedback message <NUM> is received before the expiration of the time-out period is an Ack frame (or a HARQ frame indicating a completely successful decoding) no data retransmission is required. Otherwise, the source AP-STA <NUM> is configured to identify, based on CW bitmap(s) included in the feedback message <NUM> which codewords were unsuccessfully decoded at the destination STA <NUM> and then retransmit the unsuccessfully decoded codewords (or versions of the incorrectly codewords) in a new PPDU 300R (Action <NUM>). Retransmission procedures carried out as part of Action <NUM> will now be described in greater detail according to some example embodiments.

In at least some example embodiments, the retransmission procedures performed by the source AP-STA <NUM> to retransmit unsuccessfully decoded codewords and the subsequent decoding procedures performed at destination STA <NUM> are configured to increase the chance of success based on information known from the failed transmission. By way of background, the extent to which LDPC encoding enables transmission errors to be corrected is impacted by the distribution of combinatorial configurations embedded in the parity-check matrix, such as short cycles, stopping sets for binary erasure channel (BEC) and trapping sets for binary symmetric channel (BSC) and additive white Guassian noise (AWGN) channel. Error events at the high SNR region can be related to smaller stopping sets and trapping sets. Stopping sets and trapping sets are determined by the design of a parity-check matrix and its corresponding Tanner graph for an LDPC code. Forward error rate (FER) in an LDPC based system can be improved by: (<NUM>) reducing trapping sets in LDPC code design, (<NUM>) avoiding decoder inputs (error patterns) that could fall into trapping sets, and (<NUM>) improving the reliability of inputs provided to the decoder. Given that LDPC code designs are already well defined in the art, including for example in IEEE std <NUM>™-<NUM>, example embodiments described below are directed to improving FER in retransmitted LDPC codewords by addressing the last two points noted above, namely: (<NUM>) avoiding decoder inputs that could fall into trapping sets, and (<NUM>) improving the reliability of inputs provided to the decoder.

In this regard, for each failed codeword bj, the source AP-STA <NUM> knows the bit order and content of the failed codeword bj and its corresponding source word sj (which as indicated above corresponds to an information block IBj information bits segmented from an input data stream). In order to mitigate against patterns in the codeword bits that could fall into trapping sets, in example embodiments the source AP-STA <NUM> is configured to apply an interleaving procedure to re-order the information bits included in the original information block IBj to generate a revised source word s'j which is then LDPC encoded to generate a revised codeword b'j. The revised codeword b'j can then be transmitted, which in at least some cases may improve the reliability of inputs provided to the decoder <NUM> of the destination STA <NUM>.

In this regard, <FIG> illustrates a MPDU retransmission encoding procedure <NUM> that is performed as part of Action <NUM> at source AP-STA <NUM> in example embodiments. As indicated by Action <NUM>, the unsuccessfully decoded codewords from an MPDU <NUM> included in originally transmitted PPDU <NUM> are identified by source AP-STA <NUM> based on the CW-Bitmap included in feedback message <NUM>. For illustrative purposes, a subset of the original codewords b<NUM> to bNCW , for example codewords bf bj and bq are identified as unsuccessfully decoded for the present explanation. The original information blocks (eg. IBf, IBj and IBq) used for the original source words sf, sj and sq that correspond to the unsuccessfully decoded codewords bf, bj and bq are selected (Action <NUM>) for respective re-encoding procedures. The re-encoding procedure will be described with reference to representative information Block IBj. In particular, in example embodiments, interleaving <NUM> (discussed in detail below) is applied to re-order the information bits included in the original information block IBj to generate a revised source word s'j which is then subjected to LDPC encoding <NUM> to generate a revised codeword b'j. In example embodiments, LDPC encoding <NUM> applied in procedure <NUM> uses the same LDPC codes as were used in LDPC encoding <NUM> of the original encoding procedure <NUM>.

In example embodiments, the revised codeword b'j is then subjected to puncturing/repeating <NUM>. In some example embodiments, the puncturing/repeating <NUM> applied in procedure <NUM> is the same as that performed in the puncturing/repeating <NUM> applied during the original encoding procedure <NUM>. It will be appreciated that using the same puncturing/repeating sequence for the re-transmission as used for the original transmission corresponds to known chase combining (CC) retransmission techniques. In some example embodiments, the puncturing/repeating <NUM> applied in procedure <NUM> is different than that performed in the puncturing/repeating <NUM> applied of the original encoding procedure <NUM>. In particular, fewer or different parity check bits may be punctured in puncturing/repeating <NUM> than in the puncturing/repeating <NUM> applied of the original encoding procedure <NUM>. It will be appreciated that using different puncturing for re-transmission of FEC encoded data than that used for the original transmission corresponds to known incremental redundancy (IR) retransmission techniques.

As shown in <FIG>, the revised codewords b'f, b'j and b'q generated from the respective re-encoding procedures are then combined to provide an MPDU for embedding in a retransmission PPDU 300R.

Interleaving <NUM> is performed by an interleaver implemented by encoder <NUM>. In at least some embodiments, the interleaving procedure used for the retransmission of LDPC codwords is selected based on the specific LDPC code applied by LDPC encoding. For example, different interleaving properties may be applied for LDPC codes with different rates and codeword lengths. According to the invention, the specific interleaving procedure that is applied is selected at least based on the particular retransmission iteration. In this regard, in some examples the MPDU retransmission encoding procedure <NUM> includes a select interleaver action <NUM> that selects an interleaving process to use for interleaving <NUM> based on one or more of: the LDPC code being applied, and the retransmission iteration.

In the invention, interleaving <NUM> can be implemented using a row-column block interleaver in which the information bits from an information block IBj are input into an M by N matrix in a first order (e.g. row-by-row) and then read out in a different order (e.g. column-by-column) to generate revised source word s'j. In this regard, a simplified example of a row-column block interleaver <NUM> is illustrated in <FIG>, showing information bits B1 to B6 of information block IBj = (B1, B2, B3, B4, B5, B6) being written into an M=<NUM> row by N=<NUM> column matrix on a row-by-row-basis. The information bits are read out column-by-column to generate revised source word s'j = (B1, B4, B2, B5, B3, B6).

In example embodiments, the dimensions of the matrix used for row-column block interleaver <NUM> are selected (e.g. during the select interleaver Action <NUM>) based on the LDPC code that will be applied during LDPC encoding <NUM>. By way of example, matrix dimensions that result in optimized interleaving performance may be predetermined for each possible LDPC code rate/source word length(k)/codeword length(n), and the optimized matrix dimensions then used for each LDPC code. In one example embodiment, the matrix used for row-column block interleaver <NUM> has a constant number of columns (for example N=<NUM>), and the number of rows (M) is selected from a set of predetermined values based on the LDPC code. In this regard, <FIG> shows a chart that identifies <NUM> unique LDPC code rate/source word length(k)/codeword length(n) combinations that correspond to different LDPC codes, along with a column <NUM> that specifies the number of matrix rows (M) that are to be used in a N=<NUM> column matrix for the row-column block interleaver <NUM>. Alternative row-column block interleaver configurations can be used that have a total number of matrix entries that is equal to the number source word bits (e.g. N* M=k). Different row-column block interleaver configurations are used for different retransmission iterations. In the present invention, the interleaver selection for a particular retransmission may specify that no interleaving be applied. According to the invention, no interleaving is selected for a first retransmission, a row-column block interleaver configuration based on the chart of <FIG> is selected for a <NUM>nd retransmission, and a further row-column block interleaver configuration is selected for a third retransmission.

In a case that a different interlever is used for each retransmission, a retransmission index may be included in the PHY Header of the PPDU 300R which embeds the retransmitted MPDU or A-MPDU.

In some comparative examples, interleaving <NUM> can be implemented using circular permutation interleaving. By way of example, <FIG> represents a circular permutation interleaver <NUM>. In the example of <FIG>, the output ya (a= <NUM>,<NUM>,<NUM>,. ,k-<NUM>) (i.e. revised source word s'j) of the circular permutation interleaver is a function of the information bits xb(b = <NUM>,<NUM>,<NUM>,. ,k-<NUM>) (information block IBj) and the circular permutation interleaver can be described by the following function: <MAT> where:.

Accordingly, it will be appreciated that, in at least some example embodiments, retransmission encoding procedure <NUM> generates revised versions of the codewords identified in a CW_bitmap of feedback message <NUM> as being unsuccessfully decoded. The revised codewords b' (for example b'f, b'j, b'q from the example of <FIG>) are included in a retransmission PPDU 300R. In the case where feedback message <NUM> is a BlockAck frame <NUM> including a CW-Bitmap in respect of multiple MPDUs, the retransmission encoding procedure <NUM> is carried out corresponding to CW-Bitmap, and PPDU 300R may include an A-MPDU <NUM> for retransmission. Any of the original codewords b<NUM> to bNCW that were successfully decoded following the first transmission are not represented or included in the retransmission PPDU 300R. In some examples, new data may be added to PPDU 300R such that PPDU 300R includes codewords than correspond to revised versions of previously unsuccessfully decoded codewords as well as completely new codewords.

Referring again to <FIG>, the source AP-STA <NUM> is configured to modulate retransmission PPDU 300R onto an RF signal <NUM> for transmission through a channel of wireless medium <NUM>. Destination STA <NUM> is configured to receive and demodulate RF signal <NUM> (Action <NUM>) to recover soft channel bit values for the codewords b'T included in the retransmission PPDU 300R, which are then subjected to a retransmission decoding procedure <NUM>. The actions taken during retransmission decoding procedure <NUM> in respect of a retransmitted codeword b'jT are illustrated in <FIG> in accordance with one example embodiment.

As noted above, in example embodiments the destination STA <NUM> can provide a codeword decoding log that includes decoding results for unsuccessfully decoded codewords bT from the original PPDU transmission. The codeword decoding log (indicated by reference number <NUM> in <FIG>) may for example identify, for each unsuccessfully decoded codeword bjT: the soft channel bit values output by demodulator <NUM> and the LLR values output by LLR calculator <NUM>. In example embodiments, the values included in codeword decoding log <NUM> are available for combining with corresponding values generated in respect of retransmitted codewords to assist in decoding of the retransmitted codewords. In at least some example embodiments where multiple retransmissions occur, the codeword decoding log <NUM> can provide retransmission values as well as the original transmission values associated with codewords.

Accordingly, in the example retransmission decoding procedure <NUM> shown in <FIG>, retransmission decoding <NUM> begins with interleaving the soft channel bit values previously determined for the k information bits from the original codeword bjT (Action <NUM>). The interleaving applied in Action <NUM> is the same as that applied to the information block IBj by the source AP-STA <NUM> to generate revised source word s'j. Thus, Action <NUM> aligns the information bit order for the soft channel bit values of the original codeword bjT with the information bit order of the soft channel bit values retransmitted codeword b'jT. The aligned soft channel bit values for the information bits (e.g. the source word bits) of the retransmitted codeword b'jT and the original codeword bjT are then soft-combined (Action <NUM>). The combined source code bit values are then concatenated with the soft channel values of the parity bits of retransmitted codeword b'jT, resulting in a hybrid codeword bHjT that is made of k information bits that are each soft-combinations of the soft channel values of both the original and retransmitted information bits, together with the soft channel values of the parity bits of retransmitted codeword b'jT. LLR values are then calculated for the bits of the hybrid codeword bHjT (Action <NUM>) and LDPC decoding is performed based on the LLR values (Action <NUM>).

As indicated in <FIG>, in example embodiments if LDPC decoding is not successful and a maximum number of iterations has not been reached, then a different combination of soft channel bit values from the original and retransmitted codewords can be tried. In the particular example of <FIG>, the soft-combined channel values for the source word bits generated in Action <NUM> are de-interleaved to bring the order of the source word bits back into alignment with the bit order of original source word sj, and the soft-combined channel values for the originally received transmitted and currently received source word bits are then concatenated with the soft channel values of the parity bits of original codeword bjT(Action <NUM>). The new hybrid codeword is made of k-information bits that are each soft-combinations of the soft channel values of both the original and retransmitted information bits, together with the soft channel values of the parity bits of original codeword bjT. LLR values are then calculated for the new hybrid codeword (Action <NUM>) and LDPC decoding (Action <NUM>) is carried out again. In example embodiments, different permutations and combinations can be carried out in Action <NUM> in different iterations to create different revised hybrid codewords until successful decoding occurs or a maximum number of iterations is reached.

If successful decoding occurs, an Ack message indicating success can be sent to source AP-STA <NUM>. Such an Ack message could be in the Ack frame format defined in IEEE std <NUM>™-<NUM>, or as noted above, alternatively could be feedback message <NUM> in which the CW-bitmap(s) indicates a successful decoding for each codeword.

As indicated in <FIG>, if successful decoding does not occur, a feedback message <NUM> including CW-bitmap indicating the unsuccessfully decoded codeword(s) can be generated and sent to source AP-STA <NUM> (Action <NUM>). In this regard, as indicated by Action <NUM>, source AP-STA <NUM> is configured to wait for the feedback message <NUM> for a timeout period. Retransmission action <NUM> can be repeated if unsuccessfully decoded codewords remain, and as noted above different interleaving properties or procedures may be applied in respect of further retransmissions.

Referring again to the retransmission decoding procedure <NUM> shown in <FIG>, the combining and concatenating actions can similarly be performed between successive sets of retransmitted codewords.

As noted above, the retransmission decoding procedure <NUM> shown in <FIG> is one example of a number of different possibilities in which information from two different transmissions of the same information bits can be combined to mitigate against error patterns when decoding and improve the quality of inputs to the decoder. In this regard, <FIG> shows an alternative retransmission decoding procedure 418A. Alternative retransmission decoding procedure 418A differs from retransmission decoding procedure <NUM> in that the values that are combined in Action <NUM> are based on calculated LLR values rather than the soft channel bit values.

Example embodiments of a method performed at a destination WLAN station (for example STA <NUM>) are summarized with reference to <FIG>. The method includes: receiving at the station, through wireless medium <NUM>, a first packet (e.g. PPDU <NUM>) that includes a plurality of low density parity check (LDPC) encoded codewords b<NUM> to bNCW (block <NUM>); and transmitting a feedback message (e.g. feedback message <NUM>) that includes a codeword bitmap field (CW Bitmap) containing a decoding status bit for each codeword b<NUM> to bNCW indicating whether the codeword was successfully decoded. (block <NUM>).

In some examples the feedback message <NUM> takes the form of a negative acknowledgment (Nack) frame (for example HARQ frame 600A) that includes, in the following order: a frame control field, a duration field, a codeword bitmap field for the codeword bitmap, and a frame check sequence (FCS) field. In some examples, the feedback message takes the form of a HARQ frame (for example HARQ Fame 600B) that includes, in the following order: a frame control field, a duration field, a receiver address field, a codeword bitmap field and an FCS field.

In some examples, the first packet (e.g. PPDU <NUM>) includes multiple data units that each include a respective plurality of LDPC encoded codewords and the codeword bitmap including a decoding status bit for each of the codewords included in the data units. In such examples, the feedback message <NUM> may take the form of a block acknowledgement (BA) frame that includes, in the following order: a frame control field, a duration field, a receiver address field, a transmitter address field, a BA control field, BA bitmap field that indicates a respective status bit for each of the data units, a codeword bitmap field for the codeword bitmap, and a frame check sequence (FCS) field.

In some example embodiments, the method further includes receiving at the destination station, through the wireless medium <NUM>, a second packet (e.g. PPDU 300R). The second packet includesan LDPC encoded codeword b'j generated at the source station (e.g. AP-STA <NUM>) by interleaving identical information bits (IBj) used to generate a corresponding codeword bj included in the first packet (e.g. PPDU <NUM>) and indicated in the message (e.g. feedback message <NUM>) as having an unsuccessful decoding status (block <NUM>). The LDPC codeword included in the second packet is then decoded (block <NUM>).

In example embodiments, decoding the LDPC codeword included in the second packet includes combing information from LDPC codeword included in the second packet with information from the corresponding codeword included in the first packet. In some examples, combining information includes: soft combining log-likelihood ratio (LLR) values or soft channel values obtained in respect of information bits included in the LDPC codeword included in the second packet with respective LLR values or soft channel values obtained in respect of corresponding information bits included the corresponding codeword included in the first packet. In some examples, combining information includes concatenating the soft combined LLR values or soft channel values for the information bits with values obtained in respect of parity check bits included in the LDPC codeword included in the second packet. In some examples, combining information includes concatenating the soft combined LLR values or soft channel values for the information bits with values obtained in respect of parity check bits included in the LDPC codeword included in the first packet.

Example embodiments of a method performed at a source station (for example AP-STA <NUM>) are summarized with reference to <FIG>. As indicated in <FIG>, the method includes segmenting a group of information bits into a set of information blocks IB<NUM> to IBNcw that each include a respective plurality of the information bits (block <NUM>); encoding, using low density parity check (LDPC) encoding each of the information blocks IB<NUM> to IBNcw to generate corresponding codewords b<NUM> to bNcw (block <NUM>); transmitting the codewords b<NUM> to bNcw to a destination station (e.g. STA <NUM>) (block <NUM>); receiving a feedback message (e.g. feedback message <NUM>) indicating that at least one of the codewords (e.g. codeword bj) has not been successfully decoded by the destination station (block <NUM>); interleaving the information bits of the information block IBj that corresponds to the at least one codeword bj (block <NUM>); encoding, using LDPC encoding, the interleaved information bits to generate an interleaved codeword b'j (block <NUM>); and sending the interleaved codeword b'j to the destination station. (e.g. STA <NUM>) (Block <NUM>). In some examples, the method also includes selecting an interleaver to use for the interleaving (Block <NUM>). In some examples the interleaver is selected based on an LDPC code used for the LDPC encoding. In some examples the interleaver is selected based on a number of times the information bits of the information block that corresponds to the at least one codeword have been previously included in codewords sent to the destination station.

In some examples, interleaving the information bits comprises applying row-column block interleaving to the information bits by writing the information bits into an M row by N column matrix in a first order and reading the information bits out of the matrix in a second order, wherein M* N is equal to the number of information bits. In some examples N = <NUM>, and the information bits are written into the matrix on a row-by-row basis and read out of the matrix on a column-by-column basis.

In some examples, interleaving the information bits comprises applying circular permutation interleaving.

The present disclosure provides certain example algorithms and calculations for implementing examples of the disclosed methods and systems. However, the present disclosure is not bound by any particular algorithm or calculation. Although the present disclosure describes methods and processes with steps in a certain order, one or more steps of the methods and processes may be omitted or altered as appropriate. One or more steps may take place in an order other than that in which they are described, as appropriate.

Claim 1:
A method of transmitting data, comprising:
segmenting (<NUM>) a group of information bits into a set of information blocks that each include a respective plurality of the information bits;
encoding (<NUM>), using low density parity check ,LPDC, encoding, each of the information blocks to generate corresponding codewords;
transmitting (<NUM>) the codewords to a destination station;
receiving (<NUM>) a feedback message indicating that at least one of the codewords has not been successfully decoded by the destination station;
interleaving (<NUM>) the information bits of the information block that corresponds to the at least one of the codewords;
encoding (<NUM>), using low density parity check ,LDPC, encoding, the interleaved information bits to generate an interleaved codeword;
transmitting (<NUM>) the interleaved codeword to the destination station; and
selecting an interleaver to be used for the interleaving at least based on a retransmission iteration;
characterized in that
no interleaving is selected for a first retransmission, a row-column block interleaver configuration is selected for a second retransmission, and a further row-column block interleaver configuration is selected for a third retransmission.