WARP Project Forums - Wireless Open-Access Research Platform

warp_user wrote:

I need to design PCF MAC in WARP radio. I have studied current Mango 802.11 design in terms of usage of callback function in handling and processing events between Low level and High level MAC implementations.
During CFP (Contention Free Period) PCF will be used to access the MAC and once CFP operation is completed then DCF MAC needs to be activated. This will result in implementing alternate cycles of PCF and DCF operation. I understand most of these functions are located in the AP (as PC-Point Coordinator functions). In this respect I would like your advice and guidance in understanding the best way to implement these functions in WARP.

This sounds like an interesting project. I think building the PCF into the 802.11 Reference Design is very feasible. As you noted, the PCF still requires the DCF for the Contention Period, so I think you'll mainly be making changes to the DCF project in CPU_LOW for toggling between CF and CFP as well as the AP project in CPU_HIGH to implement the AP-specific PC behaviors like sending CF-POLL frames, etc.

Out of curiosity, do you need to build a standards-compliant PCF implementation? Or something with behaviors inspired by the PCF but only implemented on WARP so interacting with a commercial Wi-Fi devices isn't critical? The latter scenario would definitely be easier.

One example to take a look at is our application note for a token-passing MAC that serves as a replacement to the DCF. It doesn't adhere to any standard, but it implements a simple scheduled MAC by having an AP cycle through its associated stations issuing them a token that allows them exclusive access to the medium for some period of time. There is a loose analogy here to the way the PCF handles CF polling that might be helpful.

warp_user wrote:

In addition would appreciate if you can provide some leads in designing the following timing functions:
    (1) When PCF operates for the first time how to initiate the access to the medium after PIFS duration (which is shorter than DIFS)?

The DIFS time is settable by software, so you could reduce it during the CFP and return it back to its original state during the CP. The macros used to adjust the DIFS time are wlan_mac_set_DIFS() and wlan_mac_set_TxDIFS() which take arguments in units of 100 nanoseconds. You'll want to reduce both of those to the PIFS timing. Note: TxDIFS is slightly smaller than the normal DIFS time by TX_PHY_DLY_100NSEC. This allows the Tx PHY to start a little before the actual DIFS boundary such that the waveform first hits the air on exactly the DIFS boundary.

warp_user wrote:

(2) Activation of CFP (PC calls the CFP with access to the medium controlled by PC) during the   
             CFP and the prevention of DCF access during that time.
    (3) Implementation of alternate execution cycles of CFP and normal DCF operation.
    (4) Synchronisation between the CFP and the STAs.

These three questions are all related. I think it makes sense for you to build this behavior into the DCF project. poll_tbtt() is the function responsible for sending beacons on TBTT boundaries. It would be straightforward to extend this function such that it executes code to enter the CFP on these same boundaries. During this time, you can disable normal DCF transmissions at the STAs much like the token-passing example I linked to earlier does.

The MAC time of each client STA and the AP are all automatically kept in sync by the periodic beaconing (the Timing Synchronization Function). Our reference design fully supports the TSF. Each device in the BSS (i.e. the AP and all associated STAs) knows when a TBTT is supposed to occur. A natural byproduct of this is that they would know when to enter a CFP based on parameters that you can add to the beacon payloads.