Changes between Initial Version and Version 1 of 802.11/app_notes/FDD-NoMAC


Ignore:
Timestamp:
Feb 13, 2017, 2:17:01 PM (7 years ago)
Author:
murphpo
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • 802.11/app_notes/FDD-NoMAC

    v1 v1  
     1[[TracNav(802.11/TOC)]]
     2
     3= 802.11 Reference Design App Note: FDD NoMAC  =
     4
     5This application note presents an extension of the 802.11 Reference Design to support frequency-division duplexing. This extension supports the AP and STA applications for CPU High and a custom FDD-capable NoMAC in CPU Low (note 1). The design uses both RF interfaces on two WARP v3 nodes. The RF A and B interfaces are tuned to different channels, and traffic flows in different directions at each interface, as illustrated below.
     6
     7{{{
     8----------                 -----------
     9    RF A | >-- 2.4 GHz --> | RF A
     10AP       |                 |       STA
     11    RF B | <--  5 GHz  --< | RF B
     12----------                 -----------
     13}}}
     14
     15== C Code Changes ==
     16
     17Extending the 802.11 Reference Design to support FDD requires only C code changes. There are 3 stages of code modifications required:
     18 1. Update the high MAC (AP & STA) to use different RF interfaces for Tx and Rx
     19 1. Update the lower MAC framework to:
     20  * Tune the RF A and B interfaces to different channels
     21  * Disable logic paths that block simultaneous Tx/Rx PHY events
     22 1. Update the NoMAC application to handle simultaneous Tx/Rx
     23
     24=== AP & STA Changes ===
     25
     26The upper and lower MAC frameworks already support setting different antennas for Tx and Rx. By default each high MAC application sets the Tx and Rx antennas at boot using the selections defined in the top-level macros named {{{WLAN_DEFAULT_TX_ANTENNA}}} and {{{WLAN_DEFAULT_RX_ANTENNA}}}. For this 2-node FDD link we must update the AP and STA to use opposite antennas for Tx and Rx.
     27
     28At the top of {{{wlan_mac_ap.c}}} and {{{wlan_mac_sta.c}}}, modify the existing macros to:
     29
     30'''AP''':
     31{{{#!c
     32// Tx on RF A, Rx on RF B
     33#define  WLAN_DEFAULT_TX_ANTENNA  TX_ANTMODE_SISO_ANTA
     34#define  WLAN_DEFAULT_RX_ANTENNA  RX_ANTMODE_SISO_ANTB
     35}}}
     36
     37'''STA''':
     38{{{#!c
     39// Rx on RF A, Tx on RF B
     40#define  WLAN_DEFAULT_TX_ANTENNA  TX_ANTMODE_SISO_ANTB
     41#define  WLAN_DEFAULT_RX_ANTENNA  RX_ANTMODE_SISO_ANTA
     42}}}
     43
     44
     45----
     46
     47(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.