802.11 Reference Design
- Download
- Changelog
- FAQ
- Architecture
Using the Design...
Benchmarks
- IFS Calibration
- Throughput
- Transmitter Characterization
- Receiver Characterization
- Pkt. Det. Min. Power Characterization
MAC
- PHY
Experiments Framework...
- Packet Flow
- FPGA Architecture
- FPGA Resource Usage
- App Notes
- Other Resources
- License
- Changelog
802.11 Reference Design: Recovery Procedures and Retransmit Limits
An important role of the 802.11 DCF is to detect the presence of transmission failures and properly recover from those errors through the use of a retransmission mechanism. This behavior is subtle and often misunderstood. This document serves two roles:
- To describe the behavior implemented in the Mango 802.11 Reference Design.
- To provide reference to the portions of the 802.11 standard where the behavior is specified.
The organization of this document is a series of examples that build on one another and show corner cases in the behavior. The retransmission mechanism in 802.11 is further complicated by the presence of RTS/CTS medium reservation handshakes prior to the transmission of an MPDU, so examples are broken up into sections depending on whether RTS/CTS is not used (i.e. an MPDU is "short") or RTS/CTS is used (i.e. an MPDU is "long"). Without loss of generality, the examples in this document assume the following parameters:
- dot11ShortRetryLimit = 7
- dot11LongRetryLimit = 4
- aCWmin = 15
- aCWmax = 1023
Overview and Terminology
The figures below are not drawn to scale. The presence of the events shown in the legend above is used to indicate only their existence and not their relative size to one another. Furthermore, the presence of a backoff interval is not shown as increasing in duration with an increasing contention window. In fact, it is important to keep in mind that any given random draw of a backoff can produce a 0-duration backoff. The figure will show this event with the full backoff event regardless.
Term | Definition |
---|---|
SRC | Short Retry Count of MPDU |
LRC | Long Retry Count of MPDU |
SSRC | Station Short Retry Count |
SLRC | Station Long Retry Count |
CW | Contention Window |
The above table summarizes the terms used in the figures below. A station is responsible for maintaining an SRC and LRC for each MPDU it intends to transmit. The SRC and LRC are used for controlling retransmissions of the MPDU in the event of a failure. Additionally, a station maintains an SSRC and SLRC that are global to the station and not tied to any particular MPDU. The SSRC and SLRC are used for controlling the current CW of the station.
Short MPDUs (MPDU length ≤ dot11RTSThreshold)
Example S.1
The above example shows the ideal scenario the transmission of 2 MPDUs. The reception of an ACK after each MPDU transmission keeps all the associated retry counts in the originating station at their minimum along as well as the contention window.
Example S.2
The above example shows a scenario where 2 MPDUs are ultimately successful. However, the first transmission attempt of the first MPDU does not result in the successful reception of an ACK. Instead, a timeout occurs and the originator infers a transmission failure. The illustrated behavior in the originator's retry counts and contention window are described by the following paragraphs in the standard
Excerpt A of Section 9.3.3 of 802.11-2012
Every STA shall maintain a STA short retry count (SSRC) , ... which shall take an initial value of 0. The SSRC shall be incremented when any short retry count (SRC) ... is incremented. ... The CW shall take the next value in the series every time an unsuccessful attempt to transmit an MPDU causes either STA retry counter to increment, until the CW reaches the value of aCWmax.
Excerpt B of Section 9.3.3 of 802.11-2012
The CW shall be reset to aCWmin after every successful attempt to transmit a frame containing all or part of an MSDU or MMPDU, ... .
Excerpt A of Section 9.3.4.4 of 802.11-2012
The SRC ... and the SSRC shall be incremented every time transmission of a MAC frame of length less than or equal to dot11RTSThreshold fails ... . This SRC and the SSRC shall be reset when a MAC frame of length less than or equal to dot11RTSThreshold succeeds ... .
In other words, the SRC increments because of the MPDU transmission failure. The SSRC increments because the SRC increments. The CW increases because the SSRC increments. When an ACK is received in the second attempt of MPDU 1, Section 9.3.4.4 dictates that the success of that MPDU causes the SRC and the SSRC to be reset. Section 9.3.3 dictates that the successful delivery of the MPDU also resets the CW.
Example S.3
The above examples shows a scenario where the no MPDU transmission ever succeeds. As in Example S.2, Excerpt A of Section 9.3.3 of 802.11-2012 dictates that each failure to delivery the transmission causes an increase in the SRC, SSRC, and the CW. The termination of retransmissions is dictated by the following excerpt from the 802.11 standard:
Excerpt B of Section 9.3.4.4 of 802.11-2012
Retries for failed transmission attempts shall continue until the SRC ... is equal to dot11ShortRetryLimit ... . When [this limit] is reached, retry attempts shall cease, and the MPDU ... shall be discarded.
On the 7th failure, the SRC increments from 6 to 7. At this moment, the SRC equals the dot11ShortRetryLimit, causing the MPDU to be discarded. Simultaneously, Excerpt A of Section 9.3.3 of 802.11-2012 from Example S.2 dictates that the SSRC increase from 6 to 7 due to the increment operation of the SRC. At this point in time, the SSRC equals the dot11ShortRetryLimit as well. This event triggers the following behavior:
Excerpt C of Section 9.3.3 of 802.11-2012
The CW shall be reset to aCWmin ... when SSRC reaches dot11ShortRetryLimit.
As such, the 2nd MPDU begins with a fresh CW minimum. However, it is important to note that the SSRC itself is not reset, so the next MPDU begins with an SSRC of 8.
Example S.4
The above example extends Example S.3 to a third MPDU transmission. The main behavior to notice is that, while MPDU 2 began with a minimum contention window (for reasons explained in Example S.3), MPDU 3 begins with a maximum contention window. In general, the contention window does not reset with every new MPDU. In the event of a string of failures, it will only reset when the SSRC exactly equals the dot11ShortRetryLimit.
Long MPDUs (MPDU length > dot11RTSThreshold)
Example L.1
The above example shows the ideal scenario the transmission of 2 MPDUs. Each MPDU transmission is initiated with an RTS control frame. A successful CTS response to that RTS transmission instructs the originator to attempt a transmission of the MPDU. A reception of a successful ACK in response to that MPDU transmission keeps all counts and contention window at station at their minimum values.
Example L.2
This example shows a type of failure that can occur in the attempted transmission of a long MPDU. If an ACK is not received in response to the transmission of the long MPDU, then the following excerpts of the 802.11 standard applies:
Excerpt D of Section 9.3.3 of 802.11-2012
Every STA shall maintain a ... STA long retry count (SLRC), ... which shall take an initial value of 0. ... The SLRC shall be incremented when any long retry count (LRC) ... is incremented. The CW shall take the next value in the series every time an unsuccessful attempt to transmit an MPDU causes either STA retry counter to increment, until the CW reaches the value of aCWmax.
Excerpt C from 9.3.4.4 of 802.11-2012
The LRC for an MPDU ... and the SLRC shall be incremented every time transmission of a MAC frame of length greater than dot11RTSThreshold fails ... . This LRC and the SLRC shall be reset when a MAC frame of length greater than dot11RTSThreshold succeeds ... .
The failure to receive an ACK for the long MPDU causes both the LRC and and the SLRC to increment. The increment operation on the SLRC causes the CW to increase to its next value. When the ACK is received in the second attempt, the CW is reset to its minimum value according to Excerpt B of Section 9.3.3 of 802.11-2012 from Example S.1. The SLRC is also reset to zero, but the reasons behind this involve going deeper than the 2012 publication of the standard. There is actually an acknowledged error in the 2012 publication. Specifically,
Excerpt E of Section 9.3.3 of 802.11-2012
The SSRC shall be reset to 0 when a CTS frame is received in response to an RTS frame, when a BlockAck frame is received in response to a BlockAckReq frame, when an ACK frame is received in response to the transmission of a frame of length greater than dot11RTSThreshold containing all or part of an MSDU or MMPDU, or when a frame with a group address in the Address1 field is transmitted. The SLRC shall be reset to 0 when an ACK frame is received in response to transmission of a frame containing all or part of an MSDU or MMPDU of , or when a frame with a group address in the Address1 field is transmitted.
This passage does not make sense for two reasons. First, it instructs us to reset the short counts for frames that are longer than dot11RTSThreshold. Second, it seems to indicate that the SLRC should be reset when any ACK is received, even if the MPDU being ACKed is less that dot11ShortRetryLimit. This is not intended behavior. In 2013, the standards writers unanimously voted to fix this paragraph to the following:
Excerpt A of doc: IEEE 802.11/13-0691
The SSRC shall be reset to 0 when a CTS frame is received in response to an RTS frame, when a BlockAck frame is received in response to a BlockAckReq frame, when an ACK frame is received in response to the transmission of a frame of length less than or equal to dot11RTSThreshold containing all or part of an MSDU or MMPDU, or when a frame with a group address in the Address1 field is transmitted. The SLRC shall be reset to 0 when an ACK frame is received in response to transmission of a frame containing all or part of an MSDU or MMPDU of length greater than dot11RTSThreshold, or when a frame with a group address in the Address1 field is transmitted.
The above excerpt fixes both errors in the original passage.
Example L.3
This example shows a type of failure that can occur in the attempted transmission of a long MPDU. A failure is inferred if a CTS is not received after the transmission of an RTS.
Excerpt D from 9.3.4.4 of 802.11-2012
After an RTS frame is transmitted, the STA shall perform the CTS procedure, as defined in 9.3.2.6. If the RTS transmission fails, the SRC for the MSDU or MMPDU and the SSRC are incremented.
Furthermore, Excerpt A from 9.3.3 of 802.11-2012' in Example S.1 applies here as well, so the contention window immediately increases to 31 after the post-RTS timeout. The second attempt of the first MPDU begins with a new RTS transmission. When a CTS is received in response to that RTS, the following excerpt instructs our behavior:
Excerpt F from 9.3.3 of 802.11-2012
The SSRC shall be reset to 0 when a CTS frame is received in response to an RTS frame ... .
Note that resetting the SSRC to 0 does not indicate that the contention window shall be reset. As such, the CW remains at 31 during the transmission of the MPDU. Upon the reception of the MPDU's ACK, the CW is reset to its minimum value according to Excerpt B of Section 9.3.3 of 802.11-2012 from Example S.1.
Example L.4
In this example, we see the error introduced in Example L.2 taken to its limit when the maximum retransmission limit is reached. After the 4th failure to transmit the long MPDU, the LRC increments to 4. At this point in time, the following excerpt from the standard binds:
Excerpt E of Section 9.3.4.4 of 802.11-2012
Retries for failed transmission attempts shall continue until the ... LRC for the MPDU ... is equal to dot11LongRetryLimit. When either of these limits is reached, retry attempts shall cease, and the MPDU ... shall be discarded.
As such, the MPDU is discarded since the LRC hit the dot11LongRetryLimit. At the same moment, the SLRC reaches dot11LongRetryLimit as well, thereby enacting the following passage:
Excerpt G from 9.3.3 of 802.11-2012
The CW shall be reset to aCWmin ... when SLRC reaches dot11LongRetryLimit ... .
As such, MPDU 2 begins with a minimum contention window. The SLRC, however, remains at a value of 4 at the beginning of MPDU 2.
Example L.5
In this example, we see the error introduced in Example L.3 taken to its limit when the maximum retransmission limit is reached. Since RTS transmissions count as "short" frames, this example is actually equivalent to Example S.3.
Example L.6
This example mixes the long and short failures introduced respectively in Example L.2 and Example L.3, respectively. In this example, an RTS transmission fails 6 times. On the 7th attempt, however, a CTS is received. According to Excerpt F from 9.3.3 of 802.11-2012 from Example L.3, the SSRC is reset to 0 at this time. Neither that SRC nor the CW are reset at this time. This point in particular is often misunderstood. The reset of an SSRC to 0 due to the successful reception of a CTS does not coincide with the reset of the SRC. Excerpt A of Section 9.3.4.4 of 802.11-2012 from Example S.1 does not apply here. That excerpt very specifically applies to "a frame that requires acknowledgment." This is not true for the RTS that was just successful.
The successful reception of the CTS then causes then MPDU to be transmitted. Failure to receive an ACK for this MPDU causes the LRC and SLRC to increment. The CW would have also increased had it not already been at its maximum value. From this point forward, the behavior of the example matches Example L.2. Notice that having a dot11ShortRetryLimit of 7 and a dot11LongRetryLimit of 4 actually allows for a total of 10 "attempts" to transmit (6 RTS-only transmissions followed by 4 RTS and MPDU transmissions).
Example L.7
This example differs from Example L.6 in one important respect: the 10th RTS transmission fails. At this point in time, the SRC finally increments up to 7. Since this is the dot11ShortRetryLimit, the MPDU is discarded. However, the SSRC increments up to a value of 1 since it had been at 0 because of the prior RTS successes. As such, since the SSRC does not equal dot11ShortRetryLimit, the CW is not reset for the beginning of the second MPDU.
Attachments (12)
- ex_s_3.png (65.6 KB) - added by chunter 9 years ago.
- ex_s_2.png (28.4 KB) - added by chunter 9 years ago.
- ex_s_1.png (22.8 KB) - added by chunter 9 years ago.
- ex_l_1.png (31.4 KB) - added by chunter 9 years ago.
- ex_l_2.png (39.5 KB) - added by chunter 9 years ago.
- ex_l_3.png (37.0 KB) - added by chunter 9 years ago.
- ex_l_4.png (69.1 KB) - added by chunter 9 years ago.
- ex_l_5.png (64.7 KB) - added by chunter 9 years ago.
- ex_l_6.png (97.5 KB) - added by chunter 9 years ago.
- ex_l_7.png (90.2 KB) - added by chunter 9 years ago.
- ex_s_4.png (101.3 KB) - added by chunter 9 years ago.
- legend.png (40.1 KB) - added by chunter 9 years ago.
Download all attachments as: .zip