Tutorial: A Custom Hopping MAC

based on Ref. Des. v1.3

Slow Hopping Approach

Among many other enhancements, the 2003 802.11h amendment added the "Channel Switch Announcement" as an optional tagged parameter in management frames (e.g. beacons). Section of 802.11-2012 describes the element. It contains a "New Channel Number" field that describes, as you might expect, the new channel that associated stations should tune to. Additionally, it contains a "Channel Switch Count" which tells STAs when they should tune to the new channel. A value of 0 informs them that they should tune immediately while any value N for N > 0 informs them they should tune immediately before the beacon Nth Target Beacon Transmission Time (TBTT). Since beacons are multicast and have no error recovery, a large value of N increases the reliability of client stations tuning to the new channel since they only need to overhear one of the N beacons to properly schedule the retuning event. Of course, the counterpoint to a large value of N is that the speed with which the network hops frequencies can be quite slow. For this reason, we call this technique for frequency hopping the "Slow Hopping Approach."

Changes to the 802.11 Reference Design

To implement the behavior of the Channel Switch Announcement, we only need to make changes to the AP and STA high-level designs. Since this behavior is standard in modern Wi-Fi devices, however, we will not bother altering our STA design to be compatible with the changes to the AP. Instead, we'll test our new frequency hopping AP by connecting associating a commercial Wi-Fi device. Modifying the STA to also honor the Channel Switch Announcement is a good exercise for the reader.

Access Point (AP)

Changes should be made to wlan_mac_ap.c in the project SDK workspace zip.

First, we should add a global variable to the top of the AP code to determine whether or not the AP should be hopping. We will tie this variable to a push button interrupt on the board so we can enable or disable frequency hopping at runtime. At the very top of the AP code, add the following code snippet:

// 0 - No hop
// 1 - Slow hop

The HOP_INTERVAL_NUM_TBTT definition will determine how many beacon intervals pass before the AP hops to a new frequency. Next, we need to set the HOP_MODE variable in main(). We will default to no frequency hopping. Before the main while(1) loop, add the following line:


Finally, we will use the existing up_button() callback to toggle frequency hopping on and off whenever we press the top button in the User I/O section of the WARP v3 hardware. Replace the existing up_button() function with the following:

void up_button(){
    HOP_MODE = (HOP_MODE+1)%2;

Finally, we need to include the Channel Switch Announcement inside our beacon transmissions and actually hop to a different center frequency at the appropriate time. We can accomplish both of these actions with modifications to the existing beacon_transmit() function. First, we need to define a few new variables at the top of the function:

    mgmt_tag_template*  mgmt_tag_ptr;

    static u8 channel_switch_count = HOP_INTERVAL_NUM_TBTT;
    static u8 next_chan = 1;

The static keyword prior to the declaration of a variable means that the variable will keep its value between invocations of the function. Next, find the part of beacon_transmit() that calls wlan_create_beacon_frame(). This function creates a beacon frame and includes some mandatory tagged parameters. In addition to these tags, we want our beacons to contain a Channel Switch Announcement if HOP_MODE = 1. Add the following snippet of code after the call to wlan_create_beacon_frame():

        if(HOP_MODE == 1){

            if(channel_switch_count == HOP_INTERVAL_NUM_TBTT){
                mac_param_chan = next_chan;
                my_bss_info->chan = mac_param_chan;
                wlan_mac_high_set_channel( mac_param_chan );

                next_chan = (rand()%11)+1; // Valid channels are in the range [1, 11]

            mgmt_tag_ptr = (mgmt_tag_template*) ( ((u8*)(curr_tx_queue_buffer->frame)) + (tx_length - WLAN_PHY_FCS_NBYTES) );
            mgmt_tag_ptr->header.tag_element_id = MGMT_TAG_CHANNEL_SWITCH_ANNOUNCEMENT;
            mgmt_tag_ptr->header.tag_length = 3;

            mgmt_tag_ptr->data[0] = 0; //Channel Switch Mode - 0: No restrictions on Tx, 1: Stations should wait until switch
            mgmt_tag_ptr->data[1] =  next_chan; //New Channel Number
            mgmt_tag_ptr->data[2] =  channel_switch_count; //Channel Switch Count

            mgmt_tag_ptr = (void*)mgmt_tag_ptr + ( mgmt_tag_ptr->header.tag_length + sizeof(mgmt_tag_header) ); //Advance tag template forward

            tx_length = ((u8*)mgmt_tag_ptr - (u8*)((curr_tx_queue_buffer->frame))) + WLAN_PHY_FCS_NBYTES;

            if(channel_switch_count > 1){
            } else {
                channel_switch_count = HOP_INTERVAL_NUM_TBTT;


This short chunk of code does everything we need. It will tune to a new channel on every "lap" of HOP_INTERVAL_NUM_TBTT beacon intervals. It will also include the next_chan inside every beacon along with the channel_switch_count to let each STA know where and when it should retune.


Without also modifying the STA design to honor the Channel Switch Announcement, we cannot test the new AP design with a WARP-based STA. We can, however, associate a commercial Wi-Fi device to the WARP AP and then press the top button in the User I/O section of the WARP v3 hardware to start the frequency hopping.

In this experiment, we have associated a Wi-Fi-equipped laptop to the WARP AP and saturated the wireless link with a UDP stream via the iperf2 tool. We can see the channel hopping behavior with the Wi-Spy spectrum analyzer.

Standard 802.11
Slow Frequency Hopping 802.11

The above spectrograms compare the behavior of the 802.11 design when HOP_MODE = 0 to the 802.11 design when HOP_MODE = 1. With frequency hopping disabled, the design sits on channel 1 on the far left of the spectrogram. When frequncy hopping is enabled, we can see that each hop occurs roughly every 10 seconds. This is due to the definition of HOP_INTERVAL_NUM_TBTT being 100 beacon intervals (where each beacon interval is 102.4 ms).

The UDP stream continues across frequency hops without interruption because the Wi-Fi client knows and honors the Channel Switch Announcement. Because of the lossy nature of multicast beacons, we are not able to dramatically speed up the hopping rate with this architecture and still expect the STA to reliably track the frequency hopping changes of the AP.

A 10 second dwell on a single frequency is very slow. As a rough comparison, Bluetooth performs a hop every 625 µs. While we could reduce the value of HOP_INTERVAL_NUM_TBTT to speed our hop rate up, we would do so at the cost of reliability since a STA needs to properly decode a beacon to know where and when it should hop. In the next section, the Fast Hopping Approach, we will take a radically different approach to the problem and break compatibility with commercial Wi-Fi devices to enable much faster frequency hopping.

Last modified 7 years ago Last modified on Aug 4, 2015, 3:20:19 PM