Changes between Version 15 and Version 16 of 802.11/app_notes/FDD-NoMAC

Timestamp:

Feb 15, 2017, 12:16:00 PM (7 years ago)

Author:

chunter

Comment:

--

802.11/app_notes/FDD-NoMAC

@@ -289 +289 @@
 }}}
 
-Note that {{{frame_receive()}}} now returns {{{FRAME_RX_RET_SKIP_RX_STARTED_RESET}}}. This flag informs the MAC framework that the application is not finishes processing the current Rx event and that the framework should not reset the Rx state, ensuring the {{{finish_frame_receive()}}} below has the opportunity to process the reception once it completes.
+Note that {{{frame_receive()}}} now returns {{{FRAME_RX_RET_SKIP_RX_STARTED_RESET}}}. This flag informs the MAC framework that the application is not finished processing the current Rx event and that the framework should not reset the Rx state, ensuring the {{{finish_frame_receive()}}} below has the opportunity to process the reception once it completes.
 
 Next add a new function to handle the "finish" step for Rx processing. Add the following function to {{{wlan_mac_nomac.c}}} and add the function's declaration to {{{include/wlan_mac_nomac.h}}}:
@@ -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:
+
+[[Image(Two_Node_Througput_vs_Time.png, width=600)]]
+
+Recall from [wiki:802.11/wlan_exp/examples/txrx_log_capture the Dual-Node Log Capture Example] that the traffic pattern applied starts off with a constant bit rate LTG flow from AP to STA. In the middle third of the experiment, anotehr constant bit rate LTG flow from STA to AP is enabled. Normally with the DCF, this second flow [wiki:802.11/wlan_exp/examples/txrx_log_analysis#LogProcessThroughputvsTime splits the total available 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.
 ----
 
 (1) This app note intentionally does not use the DCF application in CPU Low. The 802.11 DCF is designed explicitly for TDD operation. The DCF assumes all nodes transmit and receive on a common channel and that nodes cannot transmit while receiving. Further it seeks to achieve transmission by 1 node at a time with well-defined rules for when nodes are allowed to transmit following activity on the common channel. All these properties are incompatible with FDD. Building a random-access MAC for an FDD system would be an interesting project but is far beyond the scope of this app note.
+(2) The evaluation took place with RF cabling + attenuators 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.