Version 1 (modified by murphpo, 5 years ago) (diff)


802.11 Reference Design App Note: FDD NoMAC

This 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.

----------                 -----------
    RF A | >-- 2.4 GHz --> | RF A
AP       |                 |       STA
    RF B | <--  5 GHz  --< | RF B
----------                 -----------

C Code Changes

Extending the 802.11 Reference Design to support FDD requires only C code changes. There are 3 stages of code modifications required:

  1. Update the high MAC (AP & STA) to use different RF interfaces for Tx and Rx
  2. Update the lower MAC framework to:
    • Tune the RF A and B interfaces to different channels
    • Disable logic paths that block simultaneous Tx/Rx PHY events
  3. Update the NoMAC application to handle simultaneous Tx/Rx

AP & STA Changes

The 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.

At the top of wlan_mac_ap.c and wlan_mac_sta.c, modify the existing macros to:


// Tx on RF A, Rx on RF B


// Rx on RF A, Tx on RF B

(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.

Attachments (1)

Download all attachments as: .zip