| 28 | | * |
| | 27 | 1. In the first 20 second period (annotated as "A" in the TokenMAC figure), a standard 802.11 MAC implementation is able to achieve slightly more than 14 Mbps while our TokenMAC implementation could only achieve about 8 Mbps. |
| | 28 | 1. In the second 20 second period (annotated as "B" in the TokenMAC figure), a standard 802.11 MAC implementation achieves a sum throughput of slightly less than 14 Mbps while our TokenMAC implementation can achieve nearly 16 Mbps. |
| | 29 | 1. In the same second 20 second period, we can see that the 16 Mbps throughput achieved by TokenMAC is due to a nearly even split of the medium between the "AP -> STA" and "STA -> AP" flow. However, it is clear that the AP's flow has a slight advantage of the STA's flow. |
| | 30 | |
| | 31 | In the following sections, we will dig deeper into each of these three observations and explain them within the context of the TokenMAC protocol. |
| | 32 | |
| | 33 | === 1. Section A: The Zero-Contention Case === |
| | 34 | |
| | 35 | In the above figures, we can see that TokenMAC suffers a fairly severe throughput penalty as compared to standard 802.11 in the case that only one flow is using the medium. Using the standard Tx and Rx log files from each node, we have generated a new visualization to show a timeline of events within a short 500 ms window in this regime. |
| | 36 | |
| | 37 | || [[Image(wiki:802.11/wlan_exp/app_notes/tutorial_token_mac/figs:token_A.png, width=1200)]] || |
| | 38 | || ''TokenMAC: Section A Timeline''' || |
| | 39 | |
| | 40 | The above visualization shows transmissions as vertical bars that extend above the horizontal black line. It shows receptions as vertical bars the extend below the horizontal black line. It is immediately clear why TokenMAC's performance is so poor -- roughly half of the 500 ms period is idle. This is because our TokenMAC implementation still gives the STA a dedicated token reservation period even though it is not using it. In [wiki:802.11/wlan_exp/app_notes/tutorial_token_mac/extensions the extension] section of this tutorial, we will explore a modification to TokenMAC that addresses this weakness. |
| | 41 | |
| | 42 | === 2. Section B: The Heavy-Contention Case === |
| | 43 | |
| | 44 | When both flows are active, the above throughput results indicate the TokenMAC exceeds the sum network throughput of standard 802.11. We now use the same log visualization we used in the previous section to see why this is the case: |
| | 45 | |
| | 46 | || [[Image(wiki:802.11/wlan_exp/app_notes/tutorial_token_mac/figs:token_B.png, width=1200)]] || |
| | 47 | || ''TokenMAC: Section B Timeline''' || |
| | 48 | |
| | 49 | Now that both flows are active, we can see that TokenMAC is no longer "wasting" the medium like it was in the previous zero-contention case. Instead, TokenMAC alternates between the AP and the STA and allows them to send as many packets as they can during that time. Furthermore, because we lack the backoff and ACK overhead of standard 802.11, we are actually able to exceed the standard's sum throughput by a fairly wide margin (16 Mbps vs. 14 Mbps). |
| | 50 | |
| | 51 | === 3. Section B: Fairness among the AP and STA === |
| | 52 | |
| | 53 | We noted above that the AP's flow appears to be able to achieve slightly more than 50% of the sum network throughput while the the STA's flow appears to be able to achieve slightly less than 50%. Recall in our design modifications that prior to entering a token reservation period, a STA must complete the handshake of the token offer with its own token response. However, when the AP enters a token reservation period, no handshake is needed because it is the AP and already knows that it is now authorized to transmit. Example this extreme not-to-scale visualization: |
| | 54 | |
| | 55 | |
