US20210345169A1

US20210345169A1 - Retransmission of wireless data

Info

Publication number: US20210345169A1
Application number: US17/237,510
Authority: US
Inventors: Huizhao Wang; Abhishek Kumar AGRAWAL; Peiman Amini; Sigurd Schelstraete; Debashis Dash
Original assignee: Semiconductor Components Industries LLC
Current assignee: MaxLinear Inc
Priority date: 2020-05-01
Filing date: 2021-04-22
Publication date: 2021-11-04
Also published as: US20210345217A1; US20210344465A1; US20230239764A1; US20210344388A1; US11647444B2; US20210344472A1; US11368896B2; US20220279418A1; US11758461B2

Abstract

A method includes receiving a message indicative of a block of frames that were sent to the receiver. The method includes determining that a particular frame associated with the block of frames was not received. The method further includes sending a feedback message to a transmitter with a bitmap indicating that the particular frame was not received by the receiver. The method also includes receiving the particular frame from the transmitter.

Description

FIELD

The implementations discussed herein relate to retransmission of wireless data.

BACKGROUND

Unless otherwise indicated in the present disclosure, the materials described in the present disclosure are not prior art to the claims in the present application and are not admitted to be prior art by inclusion in this section.
Some wireless communication standards, such as some Wi-Fi standards, implement acknowledgement schemes to ensure that transmitted data is received by the intended recipient.
The subject matter claimed in the present disclosure is not limited to implementations that solve any disadvantages or that operate only in environments such as those described above. Rather, this background is only provided to illustrate one example technology area where some implementations described in the present disclosure may be practiced.

SUMMARY

In an implementation, a method includes receiving a message indicative of a block of frames that were sent to the receiver. The method includes determining that a particular frame associated with the block of frames was not received. The method further includes sending a feedback message to a transmitter with a bitmap indicating that the particular frame was not received by the receiver. The method also includes receiving the particular frame from the transmitter.
In another implementation, a transmitter for wireless communication with a receiver in a wireless network includes a memory and a processor coupled to the memory, the processor to perform or control performance of operations The operations include sending wireless data to the receiver. The operations include receiving a feedback message from the receiver with a bitmap that identifies a subset of the wireless data that the receiver failed to receive. The operations include constructing retransmission wireless data that includes the subset of the wireless data in view of the bitmap. The operations include sending the retransmission wireless data to the receiver.
In another implementation, a receiver for wireless communication with a transmitter in a wireless network includes a memory and a processor coupled to the memory, the processor to perform or control performance of operations. The operations include receiving a message indicative of a block of frames that were sent to the receiver. The operations include determining that a particular frame associated with the block of frames was not received. The operations include sending a feedback message to a transmitter with a bitmap indicating that the particular frame was not received by the receiver. The operations include receiving the particular frame from the transmitter.

BRIEF DESCRIPTION OF THE DRAWINGS

Example implementations will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:

FIG. 1 is a block diagram of an example wireless local area network (WLAN) in which a negative acknowledgement scheme for wireless data may be implemented;

FIGS. 2A-2C illustrate example feedback messages;

FIGS. 3A and 3B illustrate example NACK bitmaps;

FIG. 4 illustrates an example sequence diagram for wireless data communication between a transmitter and a receiver;

FIGS. 5-6 illustrate flow diagrams of example methods related to wireless communication; and

FIG. 7 illustrates a block diagram of an example computing system that may be used to perform or direct performance of one or more operations described according to at least one implementation of the present disclosure.

DETAILED DESCRIPTION

A transmitter may send wireless data, such as a wireless frame, to a receiver. In response, the receiver may send an acknowledgement message (ACK) message to the transmitter to acknowledge receipt of the frame. If the transmitter does not receive an acknowledgement message from the receiver within a period of time, (such as within a frame gap called a short interframe spacing (SIFS)), then the transmitter may assume the frame is lost, and then will start retransmission. Under this scheme, the transmitter may continue to attempt to send the frame indefinitely until the transmitter positively receives the acknowledgement frame, or the transmitter may retry until a number of retries exceeds a threshold after which the transmitter will give up and then discard this frame.
The IEEE 802.11 set of standards defines one type of wireless frame as a MAC protocol data unit (MPDU). For ease in explanation, the terms “frame” and “MPDU” may be used interchangeably with the understanding that the present disclosure may be used with any type of frame and is not limited to MPDUs.
Multiple MPDUs may be aggregated to an A-MPDU. Previously, the same acknowledgement scheme as described above has been used for MPDU and A-MPDUs.
For A-MPDUs, the transmitter may expect to receive a particular acknowledgement, such as a block ACK. A block ACK may function as an ACK for the multiple MPDUs that are aggregated in the A-MPDU. The block ACK may, for each individual MPDU in the A-MPDU (or for each frame in the MPDUs), include a bitmap position to indicate that each individual MPDU is successfully received or not. For example, 16 MPDUs may be aggregated in an A-MPDU and sent to the receiver. The transmitter expects a corresponding block ACK to include a bitmap of 16 bits to indicate whether each of the 16 MPDUs are successfully received or not. Successful receipt of each MPDU may be indicated by a corresponding bit position in the bitmap set to 1. For MPDUs that were not successfully received, their positioning may be indicated by a “0” in the corresponding bit position in the bitmap.
Recently, the number of MPDUs aggregated in an A-MPDU has increased significantly. For example, a large amount of MPDUs may be aggregated in a single A-MPDU. In some schemes, 256 MPDUs may be aggregated in an A-MPDU, which would result in a 256-bit block ACK. In other schemes, 1024 MPDUs may be aggregated, which would result in a 1024-bit block ACK. In yet other schemes, 4096 MPDUs (4k) may be aggregated, which would result in a 4096-bit block ACK. For example, a system that uses 320 megahertz or 4k QAM may send 4096 MPDUs in a single aggregation. Using conventional techniques that require positive acknowledgement of receipt, an A-MPDU with 4096 MPDUs would mean a 4096 bit block ACK bitmap, which is 512 bytes in size. With these increasing A-MPDU sizes, the amount of data needed just to acknowledge receipt may be proportionally large and inefficient. As A-MPDUs continue to include increasingly more MDPUs, this problem of large acknowledgment message sizes grows.
To remedy these and other shortcomings, a receiver in the proposed system may send negative acknowledgements “NACKs” to identify wireless data that the receiver is missing. A NACK may identify, for example, one or more MPDUs. By including the missing MPDUs without including the received MPDUs, the bitmap size may be reduced. As a comparison, for a 4k A-MPDU where the receiver does not receive one of the MPDUs, the conventional approach would use a 4k bit bitmap to request the one missing MPDU. In contrast, the present disclosure may use a NACK with a SEQ number of the missing MPDU that may be 1 bit in size, which is significantly smaller than a 4k-bit ACK that would be used under conventional systems. Under the present disclosure, the receiver may not positively acknowledge receipt of every MPDU, so long as the receiver has enough information to let the transmitter know what the receiver has missed and/or what the receiver is expecting to receive.
As another benefit, the present disclosure may reduce a number of transmissions as well as reduce an amount of data being communicated between a receiver and transmitter. For example, the receiver may use the NACK for flow control. For example, the receiver may adjust a window parameter, such as a RX window size, or any other RX window parameter to influence the transmitter. In response to the adjusted window parameter, the transmitter may increase or decrease an amount of data that is sent to the receiver.
These and other implementations of the present disclosure will be explained with reference to the accompanying figures. It is to be understood that the figures are diagrammatic and schematic representations of such example implementations, and are not limiting, nor are they necessarily drawn to scale. In the figures, features with like numbers indicate like structure and function unless described otherwise.
FIG. 1 is a block diagram of an example wireless local area network (WLAN) 100 in which a negative acknowledgement scheme for wireless data may be implemented. The WLAN 100 includes multiple wireless nodes, a transmitter 102 and a receiver 104. In general, the wireless nodes 102, 104 may be configured to communicate wirelessly with each other, including sending and receiving wireless data, e.g. in the form of packets. The wireless data may include one or more frames (e.g., MPDUs) and/or one or more A-MPDUs.
Each of the wireless nodes 102, 104 may be considered a transmitter or sender node when sending data or a receiver node when receiving data. In various examples described herein, for instance, the transmitter 102 may transmit and retransmit data to the receiver 104 and the receiver 104 may receive data and request retransmission of at least some of the data from the transmitter 102.
As illustrated, the transmitter 102 is implemented as an access point (AP) and the receiver 104 is implemented as a wireless client device or station (STA). For example, the transmitter 102 may include a gateway, a repeater, a mesh node, and/or other suitable AP for wireless stations or devices. The transmitter 102 may connect to the Internet and/or a core network via a bridge, a backhaul link, a base station, and/or other suitable devices or connections.
The receiver 104 may include a desktop computer, a laptop computer, a tablet computer, a mobile phone, a smartphone, a printer, a smart television, a digital video disc (DVD) player, a security camera, a smart device, or any other device configured for wireless communication.
In these and other implementations, each of the wireless nodes 102, 104 may implement one or more of the IEEE 802.11 protocols which are contention-based protocols to handle communications among multiple competing devices for a shared wireless communication medium on a selected one of multiple communication channels. The frequency range of each communication channel is specified in the corresponding one of the IEEE 802.11 protocols being implemented, e.g. “a”, “b”, “g”, “n”, “ac”, “ad”, “ax”, “be”, and any future version.
As illustrated in FIG. 1, the transmitter 102 includes a host processor 106 coupled to a network interface 108. The network interface 108 includes a medium access control (MAC) layer that includes a MAC processor 110 with or coupled to a MAC buffer 112 (e.g., a MAC-level transmit (TX) and/or receive (RX) buffer), and a physical (PHY) layer that includes a PHY processor unit 114. The PHY processor unit 114 includes one or more transceivers 116 a-116 n (collectively transceivers 116), and the transceivers 116 are coupled to one or more antennas 118 a-118 n (collectively antennas 118). The PHY processor unit 114 includes or is coupled to a PHY buffer 120 (e.g., a PHY-level TX and/or RX buffer). Although two transceivers 116 and two antennas 118 are illustrated in FIG. 1, the transmitter 102 can include different numbers (e.g., 1, 2, 4, 5, etc.) of transceivers 116 and antennas 118 in other implementations.
As illustrated, the receiver 104 includes a host processor 122 coupled to a network interface 124. Similar to the network interface 108, the network interface 124 may include both a MAC layer and a PHY layer. In particular, the network interface 124 includes a MAC processor unit 126 with or coupled to a MAC buffer 128 and a PHY processor unit 130 with or coupled to a PHY buffer 132. The PHY processor unit 130 includes one or more transceivers 134 a-134 n (collectively transceivers 134A), and the transceivers 134 are coupled to one or more antennas 136A-136N (collectively antennas 136). Although two transceivers 134 and two antennas 136 are illustrated in FIG. 1, the receiver 104 can include different numbers (e.g., 1, 2, 4, 5, etc.) of transceivers 134 and antennas 136 in other implementations.
In the WLAN 100, wireless data is sent from the transmitter 102 to the receiver 104, such as via antennas 118 a and 136 a. If the receiver 104 fails to correctly receive some or all of the wireless data, retransmission wireless data that includes some or all of the wireless data may be sent by the transmitter 102 to the receiver 104. In some embodiments, the receiver 104 may specify specific portions of the wireless data that failed to receive correctly to request that generally only those portions of the wireless data be included in the retransmission packet.
In more detail, the transmitter 102 prepares data for transmission as MAC protocol data units (MPDUs) in an aggregate MPDU (A-MPDU) at the MAC (e.g., at the MAC processor unit 110) which A-MPDU can be transmitted as wireless data, e.g., in a wireless packet, to the receiver 104. The A-MPDU may be transmitted with a header that identifies a sequence number (SEQ) for each MPDU in the A-MPDU. Additionally or alternatively, the header may identify a sequence number (SEQ) for each frame (e.g., MPDU) in the A-MPDU. The frames may be buffered in the MAC buffer 112, e.g., for MPDU-level retransmissions.
In at least one embodiment, the transmitter 102 may send a set of multiple A-MPDUs as wireless data to the receiver 104. The multiple A-MPDUs may be transmitted with a header that identifies a SEQ for each MPDU in the set of multiple A-MPDUs.
The receiver 104 receives the wireless data and the MAC processor unit 126 may inspect the header that identifies each MPDU in the A-MPDU to determine whether each MPDU in the A-MPDU (or set of A-MPDUs) was received by the receiver 104. The receiver 104 may also error check the MPDUs for MPDU-level errors and may identify one or more MPDU-level errors (e.g., undecodable or incorrectly decoded MPDUs) and/or one or more correctly received MPDUs (e.g., successfully decoded MPDUs). The MAC processor unit 126 may buffer one or more MPDUs in the MAC buffer 128.
The receiver 104 may then generate feedback based on any MPDU that was not received, and/or based on the error checking. The feedback may identify one or more missing MPDUs, and/or MPDU-level errors. Example feedback may include a negative acknowledgement (NACK) that indicates and/or identifies at least one of failed MPDUs or received MPDUs.
When the feedback includes MPDU-level feedback, a selective NACK message may be used to inform the transmitter 102 of any MPDUs to retransmit to the receiver 104. For example, each MPDU in the A-MPDU may be associated with a sequence identifier (SEQ) and the feedback may include SEQs numbers for each missing MPDU. The receiver may determine a next expected SEQ and may release any stored frames with SEQ numbers below the next expected SEQ.
The transmitter 102 receives the feedback from the receiver 104 and may send a retransmission of the wireless data based on the feedback. For example, where the feedback identifies failed MPDUs and/or requests retransmission of the failed MPDUs, the transmitter 102, may resend the failed MPDUs. Alternatively, the transmitter 102, (e.g., the PHY layer and/or the MAC layer of the transmitter 102) may construct retransmission wireless data, e.g., in the form of one or more retransmission packets, that may include retransmission MPDUs that correspond to the failed MPDUs. The retransmissions can be sent to the receiver without new data. In at least one embodiment, the transmitter 102 and receiver 104 may engage in an iterative session in which retransmissions and feedback are exchanged between the transmitter 102 and the receiver 104 until all the wireless data is received correctly or until a timeout is reached. Alternatively, the retransmission wireless data may be sent to the receiver 104 together with new wireless data.
In at least one embodiment, the receiver 104 may reduce the frequency of sending the feedback. For example, the feedback (e.g., a selective NACK) can be sent after being solicited by the transmitter 102, or after the receiver side has detected a missing MPDU.
In at least one embodiment, a RX window scheme may be used to track and handle missing wireless data. For example, the RX window may initially include each MPDU in a particular A-MPDU or in a set of multiple A-MPDUs. Starting at the beginning of the window, the receiver 104 may determine whether each MPDU in the window has been received. If the receiver 104 identifies an MPDU that has not been received, any MPDUs that have been received may be released such that the missing MPDU may be at the beginning of the window. If the window stays the same size, additional MPDUs may be added to the end of the window. The receiver 104 may send the feedback, e.g., a NACK, that indicates a receive window parameter that at least one of: a SEQ of the frame at the head of the RX window (Win_start_seq), a size of the RX window (Win_size), and a SEQ of the frame at the end of the RX window (Win_end_seq). Example feedback messages (e.g., selective NACK frame structures) are illustrated in FIGS. 2A and 2B.
In at least one embodiment, the receiver 104 may communicate with the transmitter 102 in view of local constraints at the receiver 104 or any other constraint identified by the receiver 104. For example, the receiver 104 may have a local constraint of not having sufficient room in a buffer (e.g., buffer 128, buffer 132) to receive a particular amount of data from the transmitter 102. In response to a determination that receiver 104 may not have sufficient room in a buffer, the receiver can adjust the RX window size. For example, for an initial 4k RX window size, the receiver 104 may only be able to receive a subset of the 4k data because of local memory constraints. The receiver 104 may adjust the RX window size to inform the transmitter 102 to not send more than what the receiver 104 can handle. The RX window size may be adjusted to any size that is smaller than the initial RX window size. For example, the RX window size may be adjusted to 1 to receive the data at the beginning of the RX window size. In another example, the RX window size may be adjusted to 16, such that the transmitter 102 may retransmit 16 frames (or MPDUs) to the receiver 104. Any size adjustment to the RX window size is contemplated. The transmitter 102 can adjust the next transmission to be a retransmission of those MPDU which are missing. In at least one embodiment, the transmitter 102 may transmit a number of MPDUs that the receiver 104 can handle. In at least one embodiment, in the event that the retransmission results in missing wireless data, the RX window size may be further decreased (such as to less than 16 as in the previous example). In this manner, the receiver 104 may use the RX receive window size as a mechanism to provide flow control to the transmitter 102. In another example, the receiver 104 may identify any type of constraint, such as a local hardware or software constraint, network congestion, or any other constraint that may affect an ability of the receiver 104 to receive wireless data from the transmitter 102. The RX window size may be adjusted to any number and may be adjusted based on any constraint, including the constraints described.
In at least one embodiment, the receiver 104 can influence the transmitter 102 throughput control by adjusting the RX window size. For a 4K window size, if the receiver 104 has an unlimited amount of memory (or an amount of memory that is unlikely to be fully used), then the receiver 104 may set the RX window size at or near the memory size. In the event that the receiver 104 momentarily experiences some kind of constraint on the memory, for example, the receiver 104 can reduce the RX window size to any number of window size that the local memory of the receiver 104 can handle. The RX window size may be changed anytime. For example, the RX window size may be dynamically changed every time receiver sends a selective NACK.
In another example of how the receiver 104 may influence data flow control of the transmitter 102, in response to the receiver 104 identifying a constraint, the receiver 104 can reduce the RX window size to any number, even to zero, which informs the transmitter 102 to stop transmission of data to the receiver 104 until the transmitter 102 receives another acknowledgement from the receiver with a RX window size that is non-zero.
In at least one embodiment, to reduce data being transferred with the NACK, the NACK bitmap may include one bit, which is for a first frame in the RX window. The bitmap length could one byte for the first frame.
In at least one embodiment, the receiver 104 may add or append the feedback message to a management frame or to any other message which may even further reduce the amount of data that is sent by the receiver 104 to the transmitter 102. The feedback message, for example, may be appended, combined, concatenated, encapsulated, or otherwise included with any other message.
FIG. 2A illustrates an example feedback message 200. The receiver 104 of FIG. 1 may be configured to generate feedback according to the feedback message 200. In at least one embodiment, the feedback message 200 may be referred to as a selective NACK frame 200.
The feedback message 200 may include any number of fields, such as a frame control (FC) field 202, a duration/ID 204, a receiver address (RA) 206, a bitmap length 208, a start SEQ 210, a NACK bitmap 212, an expected next SEQ (e.g., next frame or MPDU in a sequence) 214, a RX window size 216, and a last field (FCS) 218.
The FC field 202 and the duration/ID 204 may include any number of bits and may be used, for example, for virtual carrier sense, power management, to indicate a contention-free period, etc.
The RA 206 may include a MAC address of the intended recipient of the feedback frame (e.g., the transmitter 102 of FIG. 1). The bitmap length 208 may be used to indicate a bitmap size for the NACK bitmap, which may be variable in size. The bitmap length 208 may be sized such that the number of bits in the bitmap falls on a byte boundary, where one byte has 8 bits. In at least one embodiment, the number of bits in the bitmap may be any number in multiples of 8. The bitmap length 208 may be set to any number.
The RX window size 216 may include any window size, such as any size between 1 and 4069 according to the IEEE 802.11be standard. For example, for a 1k window size (e.g., 1024), then transmitter can, without receiving an ACK or a NACK, continue to transmit up to 1k frames to the receiver 104. The expected next SEQ 214 may indicate a next SEQ that is outside of the window or inside the window. For the 1k window size in the above example, the next expected SEQ may be 1025, which is 1024+1.
In an example where wireless data associated with SEQ=1 is missing, the bitmap length 208 may be set to 1 byte (8 bits), the start SEQ 210 may be set to “0”, the NACK bitmap 212 may be a binary bitmap with the 8 bits indicated by the bitmap length 208, and the RX window size may be set to “1” which may indicate to the transmitter 102 to send one frame (e.g., MPDU), because the RX window is full due to the loss of the frame with SEQ=1. In this example, the NACK bitmap may=10111111, where the bit[1] location is set to “0” to indicate that the SEQ=1 frame has not been received by the receiver 104. In this example, 300 frames have been received (SEQs=0-299). The expected next SEQ may be set to “300”, which may indicate to the transmitter 102 that the next frame to send after retransmitting SEQ=1, is a frame with SEQ=300. The RX window size may be increased and the transmitter 102 may continue to send wireless data to the receiver 104.
In another example where the bitmap length 208 may be set to 1 byte (8 bits), the receiver 104 may determine that the frame with SEQ=2 is missing. The receiver 104 may generate the feedback message with the start SEQ=0, because SEQ=2 would be included in a bitmap that started at SEQ=0 and also would fall on a byte boundary. The resulting NACK bitmap 212 would be 11011111, which may indicate to the transmitter 102 that SEQ=2 missing and to send the wireless data that corresponds to SEQ=2.
Continuing the above example, the receiver 104 may determine that a second frame is missing, such as a frame that corresponds to SEQ=100. As in the above example, receiver 104 has lost SEQ=2, but instead of using a large bitmap to cover 0-100, the bitmap length 208 may still be set to 1, as in the above example, which results in an 8-bit bitmap that covers SEQ=2. To indicate that the frame that corresponds to SEQ=100 is missing, the next expected SEQ 214 may be set to “100”. In response to receiving such feedback, the transmitter 102 may send two at least two frames, including the frames that correspond to SEQ=2 and SEQ=100. In this manner, the receiver 104 may request more than one missing frame without creating a relatively large bitmap.
As an alternative to the above example, in the event that the receiver 104 determines that it is missing more than one frame that would fall on the same bitmap, a single bitmap may be used without adjusting the next expected SEQ 214 field. For example, the receiver 104 may determine that the frames with SEQ=2 and SEQ=7 are missing. The resulting NACK bitmap 212 may be 11011110, where bit[2] and bit[7] have been set to “0” to indicate that the frames with SEQ=2 and SEQ=7 are missing. In response to receiving this bitmap, the transmitter 102 may send the wireless data that corresponds to SEQ=2 and SEQ=7. In this manner, the receiver 104 may indicate up to 8 missing frames in a single 8-bit bitmap by setting any of the bits to 0 to indicate a missing SEQ. This feedback scheme also provides a benefit of being able to request multiple missing frames while minimizing the size of the feedback message.
In a different example, where the missing SEQ numbers are 2 and 11, the bitmap length 208 may be set to 2 which may encompass bit positions 0 through 15. Bit[2] and bit[11] may be set to “0” to indicate that SEQ numbers 2 and 11 are missing. The resulting bitmap may, for example, be 1101111111101111 and may be 2 bytes in size.
FIG. 2B illustrates another example feedback message 230. The feedback message 230 may be similar to the feedback message 200 and may include any number of fields, such as the FC field 202, the duration/ID 204, the RA 206, an expected next SEQ 214, the RX window size 216, and the FCS 218.
The feedback message 230 may be used to identify multiple missing frames that may not be within a close SEQ range of each other (such as within a same byte boundary), while also minimizing the size of the feedback message. For example, for a 1k window size, and where the receiver 104 determines that frames corresponding to SEQ numbers 2, 100, 700, 705, and 750 are missing, rather than using a single bitmap that covers the range of SEQs 0-750, which would result in a relatively large feedback message, the receiver 104 may generate a feedback message that includes multiple, smaller bitmaps.
To provide the feedback message that includes multiple, smaller bitmaps, the feedback message 230 may include a bitmap field count 240 and multiple bitmap group fields 250. Any number of bitmap group fields 250 may be included, as illustrated by bitmap group fields 250 a-250 n. The bitmap field count 240 may indicate how many bitmap group fields 250 are included in the feedback message.
Each bitmap group field 250 may include a bitmap length 252 (which may be similar to the bitmap length 208 of FIG. 2), a start SEQ 254 (which may be similar to the start SEQ 210 of FIG. 2), and a NACK bitmap 256 (which may be similar to the NACK bitmap 212 of FIG. 2).
The receiver 104 of FIG. 1 may be configured to generate feedback according to the feedback message 230. The receiver 104 may use the feedback message 230 to generate a feedback message to indicate multiple missing frames that span multiple byte boundaries. As in the above example, where the receiver 104 determined that frames corresponding to SEQ numbers 2, 100, 700, 705, and 750 are missing, the feedback may include a relatively small bitmap for at least some of the missing SEQ numbers 2, 100, 700, 705, and 750. As in this example, the bitmap field count 240 may be set to “3” to indicate that three bitmap group fields 250 are included in the feedback message.
For SEQ=2, the bitmap length 252 a may be set to “1”, the start SEQ 254 a may be set to “0”, and the NACK bitmap 256 a may have bit[2] set to “0” to indicate that SEQ=2 is missing, as in “11011111”.
For SEQ=100, the bitmap length 252 b may be set to “1”, the start SEQ 254 b may be set to “96”, and the NACK bitmap 256 b may have bit[4] set to “0” to indicate that SEQ=100 is missing, as in “11110111”.
For SEQ=700 and SEQ=705, the bitmap length 252 n may be set to “2”, the start SEQ 254 n may be set to “696”, and the NACK bitmap 256 n may have bit[4] set to “0” to indicate that SEQ=700 is missing and bit[9] set to “0” to indicate that SEQ=705 is missing, as in “1111011110111111”.
For SEQ=750, the expected next SEQ 214 may be set to 750. In this manner, the receiver 104 may indicate to the transmitter 102 that SEQ numbers 2, 100, 700, 705, and 750 are missing using a relatively low size feedback message rather than using a single bitmap that covers the range of SEQs 0-750. The bitmap or set or bitmaps may include fewer total bits than the total number of frames in the RX window. In response, the transmitter 102 can send SEQ numbers 2, 100, 700, 705, and 750 to the receiver 104.
FIG. 2C illustrates another example feedback message 270. The feedback message 270 may be similar to the feedback messages 200, 230 and may include any number of fields, such as the FC field 202, the duration/ID 204, the RA 206, an expected next SEQ 214, the RX window size 216, the FCS 218, and the bitmap field count 240.
As compared to the feedback message 230 of FIG. 2B, the feedback message 270 may have the bitmap field count set to “0”, which may indicate to the transmitter 102 that no bitmap fields are included in the feedback message 270. Additionally or alternatively, the feedback message 270 may not include the bitmap field count 240 when no bitmaps are present in the feedback message 270. This type of feedback message 270 may be used by the receiver 104 to adjust the receive window size and, in some embodiments, the expected next SEQ 214. In an example usage of the feedback message 230, the receiver 104 may have initially closed its RX window in a previous NACK feedback message, such as by setting the RX window size 216 (as in FIG. 2A) to “0”. The transmitter 102 may send any number of retransmission wireless data to the receiver 104 and no new wireless data in view of the RX window size being set to “0”. The receiver 104 may receive all of the retransmitted frames successfully, and in response to receiving all of the retransmitted frames successfully, the receiver 104 may release all of the received frames. The receiver 104 may then send the feedback message 270 without any bitmap fields to reopen the RX window (e.g., by setting the RX window size to any non-zero number) and to indicate the expected next SEQ 214 to the transmitter 102.
FIGS. 3A and 3B illustrate example NACK bitmaps 300, 350, respectively. The NACK bitmaps 300, 350 may be embodiments of the NACK bitmap 212 of FIG. 2.
The NACK bitmap 300 may be a Tx/Rx sliding window bitmap. The NACK bitmap 300 may include any number of bits. For example, the NACK bitmap 300 may include a first bit, bit[0], that may represent a start position of the Tx/Rx sliding window (win_start_seq). For a NACK bitmap 300 that includes “n” bits, the “nth” bit may indicate the end position of the Tx/Rx sliding window (win_end_seq). Bits in-between bit[0] and bit[n] may indicate the other bits in the bitmap, where bit[n−1] may represent the win_start_seq+n−1 position.
In at least one embodiment, the RX window may be a sliding window. For example, for a 1K window with 1024 bits, the starting sequence number may be 100 (which may be indicated in Start SEQ 210 of FIG. 2) and the ending sequence number in that receive window may be the 100 plus 1023. The receiver 102 may receive everything within this window, for example, except the frame sequence number equal to 100 and the frame sequence number equal to 1023+100. In other words, those two frames may be missing. To handle this situation, it may not be efficient or productive for the receiver 104 to send a NACK bitmap that is 1K in size. Instead, the receiver 104 may send a bitmap with a length equal to one, which is one byte in size. In such a bitmap bit[0] may indicate “1” and the other bits may indicate “0”, which indicates that the wireless data that corresponds to bit[0] is missing. Continuing with the above example, this bitmap indicates to the transmitter 102 that the receiver 104 is missing SEQ number 100. The transmitter 102 can send the wireless data that corresponds to SEQ number 100 to the receiver 104. In at least one embodiment, the NACK may also indicate an expected next SEQ, such as in the expected next SEQ 216 field in the NACK frame 200 of FIG. 2), which may be the 1023+100 frame. The NACK frame 200 may include any number of fields that are similar to the expected next SEQ 216 field where the receiver 104 may indicate missing frames to the transmitter 102. Using the NACK, the transmitter 102 may determine what frames to send to the receiver 104.
In at least one embodiment, the because the NACK includes both the start SEQ and the RX window size, the last frame of the window may be implied. The transmitter 102 may retransmit the last frame of the window as well, which result in the entire sliding window being filled. With the entire sliding window being filled, the receiver 104 may release all of the frames in the sliding window. The receiver 104 may update the sliding window with the next SEQ number.
In the event that a frame in the middle of the window is not received, such as frame 600 in the above example with a 1K window, frames 1-599 may be released and the sliding window may be updated to have a start SEQ of 600. The NACK may include the starting SEQ number of 600.
FIG. 4 illustrates an example sequence diagram 400 for wireless data communication between a transmitter 102 and a receiver 104. At 402, the transmitter 102 may send wireless data to the receiver 104. The wireless data may include a header that indicates that wireless data that is in the transmission. At 404, the receiver 104 may determine if any frames were not received, such as by inspecting the header to determine what wireless data to expect and comparing the received wireless data to the expected wireless data. At 406, the receiver 104 may send a NACK that identifies the missing wireless data to the transmitter 102. At 408, the transmitter 102 may retransmit the missing wireless data to the receiver. At 410, the receiver 104 may release wireless data that is successfully received.
FIGS. 5-6 illustrate flow diagrams of example methods related to wireless communication. The methods may be performed by processing logic that may include hardware (circuitry, dedicated logic, etc.), software (such as is run on a computer system) which processing logic may be included in any transmitter 102 or receiver 104, or another computer system or device. However, another system, or combination of systems, may be used to perform the methods. For simplicity of explanation, methods described herein are depicted and described as a series of acts. However, acts in accordance with this disclosure may occur in various orders and/or concurrently, and with other acts not presented and described herein. Further, not all illustrated acts may be used to implement the methods in accordance with the disclosed subject matter. In addition, those skilled in the art will understand and appreciate that the methods may alternatively be represented as a series of interrelated states via a state diagram or events. Additionally, the methods disclosed in this specification are capable of being stored on an article of manufacture, such as a non-transitory computer-readable medium, to facilitate transporting and transferring such methods to computing devices. The term article of manufacture, as used herein, is intended to encompass a computer program accessible from any computer-readable device or storage media. Although illustrated as discrete blocks, various blocks may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation.
FIG. 5 illustrates a flowchart of an example method 500 to direct wireless communication at a transmitter. The method 500 may be performed by any suitable system, apparatus, or device. For example, one or more of the wireless nodes 102, 104 of FIG. 1 may perform or direct performance of one or more of the operations associated with the method 500. For purposes of discussion, the method 500 may be discussed as being performed by the transmitter 102 of FIG. 1. The method 500 may begin at block 505 where processing logic may aggregate wireless data frames into a block of frames. In at least one embodiment, the processing logic may aggregate multiple MPDUs into an A-MPDU or multiple A-MPDUs. At block 510, the processing logic may send the block of frames to a receiver (e.g., the receiver 104 of FIG. 1). At block 515 the processing logic may receiver a message indicating that a frame in block of frames was not received by the receiver. The message may include a feedback message which may be structured according to the feedback message structures 200 or 250. At block 520, the processing logic may send the missing frame to the receiver.
FIG. 6 illustrates a flowchart of an example method 600 to direct wireless communication at a receiver. The method 600 may be performed by any suitable system, apparatus, or device. For example, the receiver 104 of FIG. 1 may perform or direct performance of one or more of the operations associated with the method 600.
The method 600 may begin at block 605 where processing logic may receive a message indicative of a block of frames. At block 610, the processing logic may determine that a particular frame was not received. At block 615 the processing logic may determine a sequence number for the particular frame that was not received. At block 620, the processing logic may adjust a receive window parameter.
At block 625 the processing logic may send a message to a transmitter indicative of the particular frame. At block 630, the processing logic may receive the particular frame.
At block 635 the processing logic may determine whether there are more missing frames in the block of frames. In response to a determination that there are more missing frames in the block of frames (“Yes” at block 635), the processing logic may proceed to any of block 615, block 620, or block 625. In response to a determination that there are no more missing frames in the block of frames (“No” at block 635), the processing logic may proceed to block 640 where the processing logic may release at least one frame in the block of frames. At block 645 the processing logic may reset the receive window parameter.
The subject technology of the present disclosure is illustrated, for example, according to various aspects described below. Various examples of aspects of the subject technology are described as numbered examples (1, 2, 3, etc.) for convenience. These are provided as examples and do not limit the subject technology. The aspects of the various implementations described herein may be omitted, substituted for aspects of other implementations, or combined with aspects of other implementations unless context dictates otherwise. For example, one or more aspects of example 1 below may be omitted, substituted for one or more aspects of another example or examples (e.g., example 2), or combined with aspects of another example. The following is a non-limiting summary of some example implementations presented herein.
Example 1. A method, including receiving a message indicative of a block of frames that were sent to the receiver, determining that a particular frame associated with the block of frames was not received, sending a feedback message to the transmitter with a bitmap indicating that the particular frame was not received by the receiver, and receiving the particular frame from the transmitter.
Example 2. A transmitter for wireless communication with a receiver in a wireless network includes a memory and a processor coupled to the memory, the processor to perform or control performance of operations The operations include sending wireless data to the receiver. The operations include receiving a feedback message from the receiver with a bitmap that identifies a subset of the wireless data that the receiver failed to receive. The operations include constructing retransmission wireless data that includes the subset of the wireless data in view of the bitmap. The operations include sending the retransmission wireless data to the receiver.
Example 3. A receiver for wireless communication with a transmitter in a wireless network includes a memory and a processor coupled to the memory, the processor to perform or control performance of operations. The operations include receiving a message indicative of a block of frames that were sent to the receiver. The operations include determining that a particular frame associated with the block of frames was not received. The operations include sending a feedback message to the transmitter with a bitmap indicating that the particular frame was not received by the receiver. The operations include receiving the particular frame from the transmitter.
FIG. 7 illustrates a block diagram of an example computing system 2002 that may be used to perform or direct performance of one or more operations described according to at least one implementation of the present disclosure. The computing system 2002 may include a processor 2050, a memory 2052, and a data storage 2054. The processor 2050, the memory 2052, and the data storage 2054 may be communicatively coupled.
In general, the processor 2050 may include any suitable special-purpose or general-purpose computer, computing entity, or processing device including various computer hardware or software modules and may be configured to execute instructions stored on any applicable computer-readable storage media. For example, the processor 2050 may include a microprocessor, a microcontroller, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a Field-Programmable Gate Array (FPGA), or any other digital or analog circuitry configured to interpret and/or to execute computer-executable instructions and/or to process data. Although illustrated as a single processor, the processor 2050 may include any number of processors configured to, individually or collectively, perform or direct performance of any number of operations described in the present disclosure.
In some implementations, the processor 2050 may be configured to interpret and/or execute computer-executable instructions and/or process data stored in the memory 2052, the data storage 2054, or the memory 2052 and the data storage 2054. In some implementations, the processor 2050 may fetch computer-executable instructions from the data storage 2054 and load the computer-executable instructions in the memory 2052. After the computer-executable instructions are loaded into memory 2052, the processor 2050 may execute the computer-executable instructions.
The memory 2052 and the data storage 2054 may include computer-readable storage media for carrying or having computer-executable instructions or data structures stored thereon. Such computer-readable storage media may include any available media that may be accessed by a general-purpose or special-purpose computer, such as the processor 2050. By way of example, and not limitation, such computer-readable storage media may include tangible or non-transitory computer-readable storage media including Random Access Memory (RAM), Read-Only Memory (ROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Compact Disc Read-Only Memory (CD-ROM) or other optical disk storage, magnetic disk storage or other magnetic storage devices, flash memory devices (e.g., solid state memory devices), or any other storage medium which may be used to carry or store particular program code in the form of computer-executable instructions or data structures and which may be accessed by a general-purpose or special-purpose computer. Combinations of the above may also be included within the scope of computer-readable storage media. Computer-executable instructions may include, for example, instructions and data configured to cause the processor 2050 to perform a certain operation or group of operations.
Some portions of the detailed description refer to different modules configured to perform operations. One or more of the modules may include code and routines configured to enable a computing system to perform one or more of the operations described therewith. Additionally or alternatively, one or more of the modules may be implemented using hardware including any number of processors, microprocessors (e.g., to perform or control performance of one or more operations), DSPs, FPGAs, ASICs or any suitable combination of two or more thereof. Alternatively or additionally, one or more of the modules may be implemented using a combination of hardware and software. In the present disclosure, operations described as being performed by a particular module may include operations that the particular module may direct a corresponding system (e.g., a corresponding computing system) to perform. Further, the delineating between the different modules is to facilitate explanation of concepts described in the present disclosure and is not limiting. Further, one or more of the modules may be configured to perform more, fewer, and/or different operations than those described such that the modules may be combined or delineated differently than as described.
Some portions of the detailed description are presented in terms of algorithms and symbolic representations of operations within a computer. These algorithmic descriptions and symbolic representations are the means used by those skilled in the data processing arts to convey the essence of their innovations to others skilled in the art. An algorithm is a series of configured operations leading to a desired end state or result. In example implementations, the operations carried out require physical manipulations of tangible quantities for achieving a tangible result.
Unless specifically stated otherwise, as apparent from the discussion, it is appreciated that throughout the description, discussions utilizing terms such as detecting, determining, analyzing, identifying, scanning or the like, can include the actions and processes of a computer system or other information processing device that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system's memories or registers or other information storage, transmission or display devices.
Example implementations may also relate to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may include one or more general-purpose computers selectively activated or reconfigured by one or more computer programs. Such computer programs may be stored in a computer readable medium, such as a computer-readable storage medium or a computer-readable signal medium. Computer-executable instructions may include, for example, instructions and data which cause a general-purpose computer, special-purpose computer, or special-purpose processing device (e.g., one or more processors) to perform or control performance of a certain function or group of functions.
Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter configured in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.
An example apparatus can include a Wireless Access Point (WAP) or a station and incorporating a VLSI processor and program code to support. An example transceiver couples via an integral modem to one of a cable, fiber or digital subscriber backbone connection to the Internet to support wireless communications, e.g. IEEE 802.11 compliant communications, on a Wireless Local Area Network (WLAN). The WiFi stage includes a baseband stage, and the analog front end (AFE) and Radio Frequency (RF) stages. In the baseband portion wireless communications transmitted to or received from each user/client/station are processed. The AFE and RF portion handles the upconversion on each of transmit paths of wireless transmissions initiated in the baseband. The RF portion also handles the downconversion of the signals received on the receive paths and passes them for further processing to the baseband.
An example apparatus can be a multiple-input multiple-output (MIMO) apparatus supporting as many as N×N discrete communication streams over N antennas. In an example the MIMO apparatus signal processing units can be implemented as N×N. In various implementations, the value of N can be 4, 6, 8, 12, 16, etc. Extended MIMO operation enables the use of up to 2N antennae in communication with another similarly equipped wireless system. It should be noted that extended MIMO systems can communicate with other wireless systems even if the systems do not have the same number of antennae, but some of the antennae of one of the stations might not be utilized, reducing optimal performance.
Channel State Information (CSI) from any of the devices described herein can be extracted independent of changes related to channel state parameters and used for spatial diagnosis services of the network such as motion detection, proximity detection, and localization which can be utilized in, for example, WLAN diagnosis, home security, health care monitoring, smart home utility control, elder care, automotive tracking and monitoring, home or mobile entertainment, automotive infotainment, and the like.
Unless specific arrangements described herein are mutually exclusive with one another, the various implementations described herein can be combined in whole or in part to enhance system functionality and/or to produce complementary functions. Likewise, aspects of the implementations may be implemented in standalone arrangements. Thus, the above description has been given by way of example only and modification in detail may be made within the scope of the present invention.
With respect to the use of substantially any plural or singular terms herein, those having skill in the art can translate from the plural to the singular or from the singular to the plural as is appropriate to the context or application. The various singular/plural permutations may be expressly set forth herein for sake of clarity. A reference to an element in the singular is not intended to mean “one and only one” unless specifically stated, but rather “one or more.” Moreover, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the above description.
In general, terms used herein, and especially in the appended claims (e.g., bodies of the appended claims) are generally intended as “open” terms (e.g., the term “including” should be interpreted as “including but not limited to,” the term “having” should be interpreted as “having at least,” the term “includes” should be interpreted as “includes but is not limited to,” etc.). Furthermore, in those instances where a convention analogous to “at least one of A, B, and C, etc.” is used, in general, such a construction is intended in the sense one having skill in the art would understand the convention (e.g., “a system having at least one of A, B, and C” would include but not be limited to systems that include A alone, B alone, C alone, A and B together, A and C together, B and C together, or A, B, and C together, etc.). Also, a phrase presenting two or more alternative terms, whether in the description, claims, or drawings, should be understood to include one of the terms, either of the terms, or both terms. For example, the phrase “A or B” will be understood to include the possibilities of “A” or “B” or “A and B.”
Additionally, the use of the terms “first,” “second,” “third,” etc., are not necessarily used herein to connote a specific order or number of elements. Generally, the terms “first,” “second,” “third,” etc., are used to distinguish between different elements as generic identifiers. Absence a showing that the terms “first,” “second,” “third,” etc., connote a specific order, these terms should not be understood to connote a specific order. Furthermore, absence a showing that the terms first,” “second,” “third,” etc., connote a specific number of elements, these terms should not be understood to connote a specific number of elements.
The present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described implementations are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.

Claims

What is claimed is:

1. A method, comprising:

receiving a message indicative of a block of frames that were sent to the receiver;

determining that a particular frame associated with the block of frames was not received;

sending a feedback message to a transmitter with a bitmap indicating that the particular frame was not received by the receiver; and

receiving the particular frame from the transmitter.

2. The method of claim 1, wherein the bitmap has fewer than 17 bits.

3. The method of claim 1, wherein the bitmap has fewer total bits than a total number of frames in a receive window parameter.

4. The method of claim 1, wherein the particular frame is associated with a particular sequence number, the bitmap including the particular sequence number.

5. The method of claim 4 further comprising determining the sequence number for the particular frame that was not received.

6. The method of claim 1 further comprising adjusting a receive window parameter, wherein the feedback message to the transmitter is generated based on the adjusted receive window parameter.

7. The method of claim 6, wherein the receive window parameter includes at least one of: a window size, a window start sequence number, or a window end sequence number.

8. The method of claim 6, wherein the receive window parameter is adjusted to reduce a quantity of data transmitted by the transmitter to the receiver.

9. The method of claim 6, wherein the receive window parameter is adjusted based on a constraint of at least one of: the transmitter, a network between the transmitter and the receiver, or the receiver.

10. The method of claim 9, wherein the constraint of the receiver includes an available local memory at the receiver.

11. The method of claim 1, wherein the bitmap indicates a second frame that was not received by the receiver.

12. The method of claim 11 further comprising:

identifying, in the block of frames, the second frame that has not been received by the receiver; and

updating the bitmap to include a second sequence number of the second frame that has not been received.

13. The method of claim 11, wherein the bitmap includes a first bitmap to indicate the particular frame and a second bitmap to indicate the second frame.

14. The method of claim 1, wherein sending the feedback message to the transmitter includes sending the feedback message with another message.

15. A transmitter for wireless communication with a receiver in a wireless network, the transmitter comprising:

a memory; and

a processor coupled to the memory, the processor to perform or control performance of operations comprising:

send wireless data to the receiver;

receive a feedback message from the receiver with a bitmap that identifies a subset of the wireless data that the receiver failed to receive;

construct retransmission wireless data that includes the subset of the wireless data in view of the bitmap; and

send the retransmission wireless data to the receiver.

16. The transmitter of claim 15, wherein the bitmap has fewer total bits than a total number of frames in a receive window parameter.

17. The transmitter of claim 15, wherein constructing the retransmission wireless data includes inspecting the bitmap to identify a first sequence number associated with a first data frame and a second sequence number associated with a second data frame, wherein the retransmission wireless data includes the first data frame and the second data frame.

18. The transmitter of claim 15, wherein the feedback message from the receiver includes data indicative of a receive window size of zero, wherein the transmitter is to wait to send the retransmission wireless data responsive to identifying the receive window size of zero, wherein the transmitter is to resume to send the retransmission wireless data responsive to identifying a subsequent receive window size of that is greater than zero.

19. A receiver for wireless communication with a transmitter in a wireless network, the receiver comprising:

a memory; and

receive a message indicative of a block of frames that were sent to the receiver;

determine that a particular frame associated with the block of frames was not received;

send a feedback message to the transmitter with a bitmap indicating that the particular frame was not received by the receiver; and

receive the particular frame from the transmitter.

20. The receiver of claim 19, wherein the feedback message from the receiver includes data indicative of a receive window size of zero.