Changes between Version 5 and Version 6 of 802.11/wlan_exp/app_notes/tutorial_token_mac/characterization

Timestamp:

Jul 14, 2015, 2:09:21 PM (9 years ago)

Author:

chunter

Comment:

--

802.11/wlan_exp/app_notes/tutorial_token_mac/characterization

@@ -15 +15 @@
 
 1. In the first 20 seconds, the AP node starts a backlogged traffic source directed to the STA node.
-2. In the second 20 seconds, the STA node starts a backlogged traffic source directed at the AP. During this time, the AP's existing traffic flow is left on, so both the AP and the STA are contending for the medium.
-3. In the final 20 seconds, the STA node disables its traffic source and only the AP continues to contend for the medium.
+1. In the second 20 seconds, the STA node starts a backlogged traffic source directed at the AP. During this time, the AP's existing traffic flow is left on, so both the AP and the STA are contending for the medium.
+1. In the final 20 seconds, the STA node disables its traffic source and only the AP continues to contend for the medium.
 
 For comparison sake, we will run this experiment for both the standard 802.11 unmodified design as well as our custom TokenMAC design. Both experiments use the 18 Mbps PHY rate.
@@ -51 +51 @@
 === Analyzing the traffic using Wireshark ===
 
+TokenMAC is, by design, not compliant with the 802.11 Standard. That said, TokenMAC does use the Mango 802.11 Reference Design's PHY to generate 802.11g-compliant OFDM waveforms. As such, standard commercial Wi-Fi devices are capable of decoding every transmission from our TokenMAC implementation (including the custom token offer and token response frames). Using [https://www.wireshark.org Wireshark] on a laptop capable of [https://en.wikipedia.org/wiki/Monitor_mode monitor mode], we have captured the traffic from the above experiment.
+
 ||  [[Image(wiki:802.11/wlan_exp/app_notes/tutorial_token_mac/figs:wireshark.png, width=1200)]]  ||
 ||  '''Wireshark Capture'''  ||
 
+The above figure shows a small slice of the capture from Wireshark. It shows the end of a reservation period of the AP followed by the token offer and token response handshake. Because these frames are not standard, Wireshark does not natively know how to extract any information from these frames. Instead, it displays the subtype of "17" for the token offer and "18" for the token response. Recall from [wiki:802.11/wlan_exp/app_notes/tutorial_token_mac/CPU_LOW#NoMAC the CPU_LOW alteration] section the following definitions:
+
+{{{
+#!c
+
+#define MAC_FRAME_CTRL1_SUBTYPE_TOKEN_OFFER     (MAC_FRAME_CTRL1_TYPE_CTRL | 0x10)
+#define MAC_FRAME_CTRL1_SUBTYPE_TOKEN_RESPONSE  (MAC_FRAME_CTRL1_TYPE_CTRL | 0x20)
+}}}
+
+Wireshark computes the "Type/Subtype" value as an 8 bit value, where the 4 LSB is the Type (Control = 0x1) and the 4 MSB is the Subtype (Token Offer = 0x10). This is why these types show up as "17" and "18" in Wireshark.
+
+You can download the Wireshark PCAP file from this experiment here: [http://warpproject.org/dl/app-notes/tokenmac_capture.zip tokenmac_capture.zip (1.7 MB)]