Changes between Version 22 and Version 23 of 802.11/app_notes/FDD-NoMAC

Timestamp:

Feb 15, 2017, 12:30:01 PM (8 years ago)

Author:

murphpo

Comment:

--

802.11/app_notes/FDD-NoMAC

@@ -382 +382 @@
 === 4. Evaluation with Experiments Framework ===
 
-To evaluate the FDD design, we can use any of the [wiki:802.11/wlan_exp/examples Experiments Framework examples] or Ethernet bridging. For example, running {{{log_capture_two_node_two_flow.py}}} followed by visualizing those logs with {{{log_process_throughput_vs_time.py}}} produces the following result:
+The FDD extension can be characterized using the standard [wiki:802.11/wlan_exp/examples experiment framework example scripts]. For example, running {{{log_capture_two_node_two_flow.py}}} and analyzing the resulting log files with {{{log_process_throughput_vs_time.py}}} produces the following throughput-vs-time plot:
 
 [[Image(Two_Node_Througput_vs_Time.png, width=600)]]
 
-This evaluation took place with RF cabling + 50 dB of attenuation connecting the RFA on the AP to RFA on the STA as well all RFB on the AP to RFB on the STA. Because there is no underlying random access MAC, this FDD implementation is sensitive to interference present in the 2.4GHz and 5GHz channels. Testing over a wire eliminates this interference for the purpose of this study.
+For this example we connected the nodes with two RF cables (RF A<->RF A and RF B<->RF B) with 50dB series attenuation on both links. Because NoMAC implements no actual medium access protocol, this FDD implementation is sensitive to interference from other devices in the 2.4GHz and 5GHz bands. Testing with cables connections eliminates this interference for the purpose of this study.
 
 Recall from [wiki:802.11/wlan_exp/examples/txrx_log_capture the Dual-Node Log Capture Example] that the traffic pattern starts off with a constant bit rate LTG flow from AP to STA. In the middle third of the experiment, another constant bit rate LTG flow from STA to AP is enabled. [wiki:802.11/wlan_exp/examples/txrx_log_analysis#LogProcessThroughputvsTime Normally with the DCF], this second flow splits the sum throughput roughly evenly between the two nodes while the overall sum throughput slightly decreases due to unavoidable wireless collisions. With the FDD design, however, we can see that the presence of the second flow has no impact on the original flow and the sum throughput doubles.