TRASS is implemented on the Linux driver registers multiple virtual interfaces to upper layers for the infrastructure BSS and the mesh networks to the Linux kernel.
Moreover, the multi-channel transmission is completed above all and then the behaviors of the power-saving and the HCCA are implemented at the WLAN driver.
Finally, the TRASS algorithm is implemented in a switching timer which controls radio switching and the whole behaviors.
4.1 System architecture of implementations
Figure 6 System architecture of implementation on RTL8186
To verify the feasibility of TRASS, the implementation was realized on the RTL8186 AP system of the company Realtek. RTL8186 is a commercial product which is a highly integrated System-on-a-Chip with embedded Linux supporting IEEE 802.11a/b/g and RTL8186 equips with a single radio. Moreover, the project of Realtek-NCTU Joint Research Center is developed the mesh networking on RTL8186 and follows the IEEE 802.11s draft revision 1.0. Therefore, RTL8186 can play the
role of an STA, an AP, an MP and an MAP. The architecture of our implementation on RTL8186 is shown in Figure 6. We purely implemented TRASS at the driver level because channel switching is a monotonous, recursive and frequent behavior.
From abstract view, the mesh network interface and the infrastructure BSS interface of a MAP should be separated. because individual interface provided to the upper layers and the applications is more modular and flexible. Afterwards, a Linux timer is registered to control radios switching among channels. The handler of the switching timer being the core of TRASS manages the behaviors of the TRASS mechanisms and embeds the TRASS algorithm in itself. Thereafter, we have to complete the multi-channel transmission by modifying the data path of the original IEEE 802.11 driver. In a single-channel scenario, the driver immediately transmits or forwards data to current channel if the medium is available. On the other hand, in a multi-channel scenario, it needs to know which channel the destination stays in and it has to switch to the channel before transmitting. However, the multicast data and the broadcast data results in more channel switching overhead because it needs to switch to multiple channels for transmitting each frame. Therefore, we supply a sending queue for each channel and dispatch a frame into the sending queue of the corresponding channel if the current channel does not correspond. Furthermore, the multicast data and the broadcast data are cloned as multiple frames and are queued up into the corresponding sending queues of these channels. When the switch node stays in some channels, it processes the frames in the sending queue of the channel and then transmits them if the medium is available.
4.2 TRASS mechanisms compatibles with IEEE 802.11
Because the HCCA and the power-saving were not implemented on our platform, our works include implementation of the TRASS mechanisms on the platform.
However, TRASS only requires their behaviors to notify its neighbors and buffer for the switch node. Therefore, the necessary frames for notification and the handler for receiving these frames are implemented but the actual internal processing for the power-saving and the HCCA such as power consumption and the quality of service are not implemented.
First, the notification frames and their handlers are implemented. However, most platforms issue the Beacon frame and the control frames by the hardware. We cannot set our information elements into those frames easily. Thus, the driver is modified to provide a software Beacon frame to carry the necessary information elements for the HCCA and the power-saving and to trigger the hardware to send a CF-End frame.
Moreover, a flag to indicate whether this node is in the CFP or the power-saving mode is added and the corresponding handler sets or clears the flag while a STA or a MP has received the frames which is described in chapter 3. Second, STAs should buffer the data in the CFP until they are polled by the AP or return to the CP. Thus, each STA need a sending queue for buffering data in the CFP. On the other hand, MPs should buffer the data for all neighbor MPs which are in their power-saving mode. Thus, each MP needs the number of sending queues as many as the number of its neighbor MPs. We implement the sending queue to record the pointer of each incomplete frame and modify the transmission data path to queue up frames. The buffered frames will be processed while the flag is modified by the corresponding handler of the Beacon frame with the power management bit set and the CF-End frame.
4.3 TRASS algorithm
The time ratio aware channel switching algorithm is implemented in the switching timer handler which is registered by the driver. It decides which channel to
stay in and computes the length of the period to stay in. First, we have to log the necessary parameters for our algorithm. Because the WLAN driver can capture all the frames in current , we record the duration filed and data length of the frames
i
channel
iin
channel
to getT
SN( ) i,j
,T
Other( ) i,j
andD
Done( ) i,j
. On the receiving side, theframes , we accu
switch node filters the frames according to the address 1 field and BSSID. If the need to be handled by the switch node mulate the duration filed to
( ) i,j
T
SN and accumulate the packet length toD
Done( ) i,j
. Otherwise, we accumulate the duration filed toT
Other( ) i,j
. On the transmitting side, we check whether the destination node of the frame stays in current channel before transmitting. If the destination node is in the other channel, the frame is queued up and accumulates theduration filed to
T
SN( ) i,j
. In addition, ipacket length to
D
Not Yet( ) i,j
. Otherwise, the frame is transmitted and accumulate theα
,β , and MinTime
i e experiencevalues and given at compile-time. We observe the maximum channel utilization of current channel to adjust i
are th