Communications Network Research Institute

Development of a Channel Selection Mechanism in Multi-Radio Multi-Channel WLAN Mesh Networks

Fuhu Deng
PhD Student (November 2009 - present)
Funding Agency: China Scholarship Council


The IEEE 802.11b/g and IEEE 802.11a standards provide for 3 and 12 non-overlapping channels, respectively, which can be used simultaneously within a neighbourhood by assigning non-overlapping channels to radios. This then increases efficient spectrum utilization and maximizes the bandwidth availability of the network.

However, as the wireless interface card is a half-duplex device, it can not transmit and receive packets simultaneously. More importantly, it cannot transmit on two channels at the same time. With the availability of cheap off-the-shelf commodity hardware, multi-radio solutions have become more attractive. Multi-radio means that two or more wireless interface cards on a mesh node can be used. Attempting to implement 3+12=15 wireless interface cards at a node is not really feasible owing to cost and power consumption considerations. Therefore, it is of greater interest to investigate the scenario where the number of radio interfaces per node is smaller than the number of available channels. That means that it becomes necessary to select a suitable channel for each interface card.

Description of Problem

The IEEE 802.11 WLAN standard operates in the ISM bands at 2.4GHz and 5GHz. However, there are many other users that share this spectrum. For example microwave ovens, medical diathermy machines etc. which means that it is necessary to determine the suitability (in terms of bandwidth availability and also the reliability) of a WLAN channel before using selecting it for use in a mesh network.

There are several methods that can be used to determine whether the channel is busy or idle. The first one is CCA (Clear Channel Assessment), and is implemented at the PHY layer. The CCA mechanism uses the Energy Detection (ED) and Carrier Sense (CS) method to indicate whether the medium is busy or idle. But this parameter can only indicate the status of the current operating channel. It is inefficient to turn the interface card to a channel when the utilization of the channel is not known.

The second method is based upon measuring the packet delay and packet loss. Each node periodically transmits probe messages on each channel and then measures the delay and loss for the probe packet. The delay includes the transmission (or retransmission) time and the acknowledgment (ACK) time. If this time is too long it means that the medium is busy. This method has a high overhead due to transmitting the probe messages, which reduces the bandwidth availability to users.

The channel time based method calculates the channel time that is used for frame transmission. It has two components. The first is channel busy time, which corresponds to the time that frames are transmitted on the medium. This can be measured from the frame length and transmitting rate. The other component is the channel idle time, which is the time when there are no transmissions on the medium. The channel idle time can be further divided into a back-off time and an unused or free channel time. The back-off time is the time when the stations are in the back-off state during the collision avoidance stage which cannot be measured directly. The channel free time is the time when there is no packet awaiting transmission on the medium. The station could transmit packets without collision. Because the back-off time can not be used to transmit packets, the free time is the parameter can be used to indicate the capacity of this channel.


The project goal is to implement an efficient channel selection mechanism for wireless mesh networks (WMNs) to increase the bandwidth utilization and the network throughput.

Multichannel testbed
Figure 1: Channel selection experimental test bed.

Figure 1 shows the experimental test bed. It is proposed to implement a channel monitor programme on the multi-radio node (in the centre of the diagram) where one of the two wireless interface cards is configured as a AP, and the other one interface is configured in the Ad-hoc mode. Another two PCs are used as the traffic generator and traffic receiver. There is also some other nodes transmitting on the test channel, these are the background generators.

Multi-radio nodes
Figure 2: Multi radio nodes.

Figure 2 shows the configuration of the multi radio nodes. Each node contains two interfaces. The first interface is configured in the AP mode and has been assigned the IP address 192.168.x.x. The second interface is configured in the Ad-hoc mode and has the IP address 5.x.x.x. The reason for using routing rather than bridge is that the card cannot be turned into the monitor mode without destroying the bridge.

Smart Channel Selection

The smart channel selection mechanism has two parts (see Figure 3). The upper part is the Transmit status where two scripts are running, The first script checks the number of retry frames, the other measures the PER (packet error rate) every second and outputs the results to a smoothing filter to get a smoothed PER value. If this exceeds a predefined threshold value, the sniffer process is started which corresponds to the second part.

Channel Selection Mechanism
Figure 3: Channel Selection Mechanism.

The lower part is the Monitor status where a script is running that will compare the channel information and selects the channel with the highest capacity. Currently, the channel with the highest free time and lowest retry rate will be selected to transmit after the sniffer process.

MadWifi is one of the most advanced WLAN drivers available for Linux today. It is stable and has an established user base. The driver itself is open source but depends on the proprietary Hardware Abstraction Layer (HAL) that is available in binary form only. Madwifi use a struct called descriptor to record the information of each frame. When the PHY layer has successfully transmitted a frame, it will report some information to the driver, i.e. number of retry, transmitting time etc. The Madwifi driver also outputs this information into the file /proc/net/dev. In the first script, this file will be read and a filtered PER value will be calculated.

Informing the neighbour nodes

After a channel is selected, the node needs to inform the neighbour nodes that the channel will change after a TBTT beacon duration (102.4 ms) (see Figure 4, Step 2). TBTT is the variable used in the Madwifi driver to indicate the number at least how many beacon frames with channel switch information element the receiver should receive before it follow this change. Figure 4 shows the channel switch process. In Step 1, Node A and Node B both transmit on the same channel. They can receive each others beacon frames. When Node A learns that this channel is no longer capable of reliable communication and channel 2 can provide this reliability with low bandwidth utilization. In step 2, Node A will transmit a special beacon frame to inform Node B that it will change to channel 2. Node B will switch to channel 2 when it received this beacon frame. In step 3, Node A will change channel when it sends out a TBTT beacon frames. After that, Node A and Node B will communicate with each other on the channel 2.

This progress takes about 400 milliseconds to inform neighbour nodes to follow the channel switch if the TBTT was configured as 3.

Channel Switch Process
Figure 4: Channel Switch Process.

The difference between normal beacon frame and channel switch beacon frame is that the channel switch beacon frame includes the Channel Switch Information Element (see figure 5). The length of this element is only 5 bytes. So this modification has little impact on the current network load.

The Madwifi driver was modified as follows. When the iwconfig command was first used to change the channel, the driver does not actually change the operating channel immediately. It will add the channel switch information element into the beacon frames. After a few number (This number should greater than TBTT) beacon interval, the iwconfig command is used to change channel again, this time the channel will immediately switch to the new channel.

Figure 5: Channel Switch Information Element
Figure 5: Channel Switch Information Element.

Figure 5 show the Information Element for the channel switch. The Madwifi implements this element ID as 37, and not use the Mode part (show in Figure 5) at present. The default TBTT is 3. This means that the receiver will change channel after it receives 3 channel switch beacon frames.

The Wireshark network protocol analyzer was used to capture the beacon frames (see upper figure of Figure 6). Compared with the beacon frames without channel switch information element (see bottom figure of Figure 6) and the beacon frame without channel switch information element, the difference is the channel switch information element which informs the receiver that the channel will be changed. Currently Madwifi does not use this information element in the Ad-hoc mode. At the receiver, this part was modified, so that the receiver will change the channel after TBTT beacon intervals.

Figure 6: Beacon frames 1 captured with Wireshark

Figure 6: Beacon frames 2 captured with Wireshark
Figure 6: Beacon frames captured with Wireshark.

Switching Cost

When a node switches to monitor mode, it cannot transmit packets to other nodes. So this switching results in a throughput decrease. Figure 7 show this switching cost. Before 56 s, the node operates on a channel with low capacity. Then the smart channel selection mechanism decides to switch channel, this mechanism use about 3 seconds to monitor several channels and select a channel with higher capacity. After the beacon change process described above, both the sender and receiver switch to the new channel, and restart the transmission again and realise a higher throughput. Because of the switching cost, this switch process should not be triggered frequently. This consideration of switching cost should also could help the smart channel select mechanism to decide whether this node should switch channel or not.

Figure 7: Switching cost
Figure 7: Switching cost.

This consideration of switching cost should also could help the smart channel select mechanism to decide whether this node should switch channel or not.