Distributed On Demand Channel Selection in Multi Channel, Multi Interface Wireless Mesh Networks Stefan Bouckaert∗ , Nicolas Letor† , Chris Blondia† , Ingrid Moerman∗ and Piet Demeester∗ ∗ Ghent
University – IBBT – IMEC – Department of Information Technology (INTEC) – IBCN Gaston Crommenlaan 8/201, B-9050 Gent, Belgium – Email:
[email protected] † University of Antwerp – IBBT – Department of Mathematics and Computer Science – PATS Middelheimlaan 1, B-2020 Antwerpen, Belgium – Email:
[email protected]
Abstract—In this paper we present a protocol performing on demand distributed channel selection in multi channel, multi interface wireless mesh networks, based on the exchange of control messages. The link based channel reservation happens almost instantly when data traffic is sent through the network, and does not require long-term traffic profiles or measurements. The protocol is both simulated and implemented using the IEEE 802.11b/g protocol. We show that in a raster topology, the protocol successfully optimizes the local spectrum usage at 87% of the nodes, and that globally, an equal amount of links is allocated to each of the channels used for the transport of data packets.
I. I NTRODUCTION In a Wireless Mesh Network (WMN), two types of nodes can be distinguished [1]. First, there are mesh routers which are especially built to dynamically form a self-configuring wireless backbone mesh network. They are usually equipped with multiple interfaces in order to exploit channel diversity. Some of these routers are gateways, providing the network with additional services such as internet connectivity. Second, mesh clients connect to these mesh routers. In general, mesh clients only have a single network interface. Although mesh clients can also act as a router, there are no gateway functions available at these nodes. Usually, these nodes are highly mobile compared to the backbone mesh routers. In this paper, a novel channel selection protocol called FRESME (FREquency Selection based on Message Exchange) is presented. The algorithms used in the protocol were designed to perform on demand distributed channel selection in mesh networks with multi channel, multi interface mesh routers. Even though mesh routers generally are considered to have low or zero mobility, a lot of scenarios exist in which backbone nodes have to be set up fast in a dynamic environment where routers can appear or disappear at any time. As an example, this is the case in Figure 1. This classic emergency scenario where a communication network is needed at an incident scene is traditionally solved using heterogeneous, single interface ad hoc networks. However, a single interface ad hoc solution may lack robustness or fail to meet the bandwidth requirements that are needed during an intervention. Furthermore, in big disaster areas, e.g. after an earthquake, flood or tsunami, a single interface ad hoc solution
(scaled)
Fig. 1. An emergency scenario. Mesh Routers are installed at the fire trucks. One mesh router forms a gateway towards the fire station or crisis center.
may not be scalable. A possible solution is to place multi interface mesh routers at fire trucks or other intervention vehicles, to which firemen and other emergency services can connect. In this scenario, it is very important that a robust network is set up fast and automatically. In contrast to mesh networks that are used in a static environment, the channel selection in the backbone network cannot use long-term traffic profiles. Another example of a scenario with similar requirements is the installation of a temporary broadband network infrastructure, e.g. at a temporary conference building or during temporary events such as exhibitions or concerts. These networks are only used for a short period of time but still need to be robust. A well designed WMN can provide these qualities. In order to design such robust broadband WMN, channel selection has been explored in the past. The general idea behind performing channel selection at the backbone nodes is that, by using multiple non-interfering channels at the different interfaces of a single node, multiple traffic flows can coexist without interfering. The key challenge here is how channels can be chosen throughout the network in order to get optimal network performance in terms of throughput, delay, or other metric. The decision on which channel to start a session can be done by scanning the environment for interference, or in a closed system, by querying a central machine which holds an overview of the network topology and channel occupation. However, it is difficult to use these types of channel selection procedures under the dynamic circumstances described above: if channel selection decisions have to be made based on measurements during a very short time frame, the measurements are most likely inaccurate. On the other hand, when a network needs to be set up rapidly, we cannot afford to postpone a channel selection decision. Furthermore, measurements
1930-529X/07/$25.00 © 2007 IEEE This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE GLOBECOM 2007 proceedings.
over a prolonged period of time can become meaningless if the backbone topology or traffic patterns change. Finally, a central coordinating machine might not be available. In this paper, we present a simple yet effective scheme performing channel selection in mesh backbone networks, based on the exchange of control messages. It is able to perform channel configuration almost instantly in a fully distributed way and with minimal overhead. The protocol has been simulated and implemented using the IEEE802.11 protocol. The channel selection algorithms are triggered only when regular data packets are sent, and are fully transparent to the networking stack. As a consequence, our channel selection scheme is very scalable and can be used in conjunction with any routing protocol which holds information about the next hop, even if the routing protocol was not designed for use with multiple interfaces. The remainder of this paper continues as follows: Section II discusses related work on channel selection and points out differences with our research. In Section III, our FRESME protocol is explained. It is then evaluated in Section IV. Finally, Section V summarizes our main conclusions. II. R ELATED W ORK Several channel selection mechanisms have been proposed in literature. These techniques can be classified in several ways. One option is to classify the mechanisms based on the input data source: some algorithms make decisions based on measurements (e.g. interference [2], round-trip latency [3]), others make status based decisions, e.g. by monitoring the exchange of control packets [4]. A second classification is based on the amount of different channels and/or network interfaces available. In single interface multi node infrastructure networks with a wired connection at every node, neighboring nodes can be configured to operate on non interfering frequencies [2]. Other researchers explore the use of multiple channels in conjunction with single interface ad hoc or mesh nodes [4], [5]. Still others, like [6], perform channel selection in multi channel multi interface networks. In these categories, some protocols make use of a default control channel. Third, mechanisms can be classified as distributed, e.g. [2], or centralized, e.g. [6]. Part of the work that is done on centralized selection schemes tends to be very theoretical. Some of these algorithms, like [7], presume a complete and perfect knowledge about the network state in terms of topology, transmission power, traffic load or other parameters. Finally, channel selection research can be classified based on the implementation method: as noted above, some works are purely theoretical. Although this type of research is interesting in order to get a better understanding of the impact of certain network parameters on network performance, the resulting solutions are only able to dimension a static network in a controlled wireless environment, while they most probably fail in a real-life dynamic wireless environment. Other authors propose modifications to the 802.11 MAC [4], [8] or implement protocols that fit into the standard network stack [3].
The combination of the characteristics listed above results in a broad range of research options for channel selection. The concepts that are related most to our channel selection protocol are described below, and differences are pointed out. As in [3], our protocol focuses on optimizing the local spectrum usage. Also, their high-level system architecture shows resemblances with our architecture: no changes are required to the 802.11 MAC and the use of multiple network interfaces is hidden from upper layers by using a (de)multiplexer software component. The authors perform intelligent channel selection based on a channel quality metric, which is determined by sending probes on a periodic basis. The channel decisions are then made at a node locally, without the need for agreement between sender and receiver. This is in contrast with the operation of our FRESME protocol, which does not require periodic probing, but only exchanges information between sending and receiving node prior to initializing a new channel reservation. In our protocol the local status is initially built by monitoring control packets. This technique is also found in [4]. In the cited work, channel selection is performed for multi channel single interface networks by modifying the IEEE 802.11 RTS/CTS messages. Our work is also partially inspired by the RTS/CTS mechanism. However, we do not make changes to the 802.11 MAC itself, and we target multi interface nodes. Additional related work and interesting overviews are found in [5] and [6]. III. C HANNEL S ELECTION P ROTOCOL A. Overview The FRESME protocol was designed with following goals in mind. First, we wanted to design a protocol which could be implemented using today’s 802.11 hardware, as we believe that in addition to simulations, testing mesh protocols on actual hardware under real-life situations is important in order to prove the feasibility of an approach. Second, as a lot of research has already been done on routing in mesh and ad hoc networks, we wanted to develop a protocol which could be used with a broad range of routing protocols. Third, as we target the use of mesh networks in a highly dynamic environment such as in the scenarios described above, we cannot make use of long-term traffic profiles or assume complete knowledge of all network parameters at all times. The FRESME protocol is able to perform distributed channel selection in multi-channel multi-interface mesh networks in a fast way. The current version has been developed for use with the IEEE 802.11b/g protocol. Because in 802.11b/g only three non-overlapping channels exist, it was decided to assume an identical and fixed channel assignment at every node and equip every mesh node with 3 interfaces, tuned to channel 1, 6 and 11. In [6], Raniwala et al. correctly argue that working with a fixed channel assignment at every node is a suboptimal approach when assigning channels to wireless links. This is true when working with the 802.11a protocol: the more noninterfering frequencies that can be used, the more traffic can be spread out over the frequency spectrum. The remainder of
1930-529X/07/$25.00 © 2007 IEEE This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE GLOBECOM 2007 proceedings.
Default Network Stack
Cross-Layer Extension Stack
extensions block. It is briefly explained in Section III-C.
Application Layer Transport Layer
Future Modular Cross-Layer Enhancements
B. FRESME core algorithms
Network Layer
FRESME MAC Layer
FRESME core algorithms
Physical Layer – PHY1
Information Database (iDB)
PHY 2
PHY 3 DATA IN
DATA OUT
DATA IN
DATA OUT
Control Traffic
DATA IN
DATA OUT
Fig. 2.
(De) – Multiplexer
FRESME architecture.
the paper describes the simulation and operation of FRESME for 802.11b/g, however, Section III-C will show that the fixed channel assignment scheme can easily be extended to support dynamic channel assignment. In order to get the protocol to work with several routing protocols, the stack architecture from Figure 2 is used. Every node in the network has a single IP address, but has multiple PHY interfaces which are hidden from the upper part of the network stack by a multiplexer/demultiplexer block. The MAC address of PHY2 and PHY3 is configured in such way that it can be deducted from the MAC address of PHY1. Packets which are passed from layer 2 to the physical layer are intercepted at the multiplexer. The multiplexer then gets the next hop MAC address from the packet, and checks the information database (iDB). The iDB holds a table which binds outgoing MAC addresses to outgoing interfaces, thus, channel selection is performed on a per-link basis. The binding process optimizes the local spectrum usage at a node and is described in Section III-B. When sending or receiving a packet, the multiplexer translates the MAC addresses in such way that it seems to the routing protocol as if every packet was sent using a single interface, while in reality the alternative PHYs are used. In order to have a robust mesh network, it is essential that control traffic is delivered in a reliable way. One way to increase the probability of this control traffic being delivered correctly, is to reserve a channel for control traffic specifically, limiting the interference. However, reserving the use of a channel for control traffic is a waste of spectrum. This is why we propose a hybrid approach to this problem: the control interface is exclusively used for control traffic from routing and FRESME protocol, except under following two conditions: (i) a link to a new neighbor needs to be set up and the channel reservation is not yet completed or fails. This includes failed negotiation with nodes which do not run FRESME, thus ensuring backward compatibility with non-FRESME nodes. (ii) the non-control wireless interfaces are heavily loaded. In this case, the control channel is also used as additional data channel, as it does not make sense to receive all control traffic via an almost empty channel, while application traffic is blocked because data channels are fully occupied. A last element from the figure is the future cross-layer
In this paragraph, the core algorithms of FRESME will be explained when working with 802.11b/g hardware, in a setup where every mesh router is FRESME enabled and has exactly three wireless interfaces. A first wireless interface is tuned to channel 1: it will transmit and receive all control traffic, and might also be used as a data carrier under the specific conditions listed above. The second and third interface are respectively tuned to channel 6 and 11. Both interfaces will only be used to transmit and receive data traffic and the corresponding ACKs. All interfaces connect to the network with IBSS ID channel x, x being the channel number of the interface. At this moment, the default routing protocol and addressing mechanisms of the mesh network can start operating using the default interface on channel 1. As stated before, FRESME is an on demand protocol: as long as no traffic other than broadcast traffic –including traffic generated by the routing protocol– is sent, nothing happens. An example using a simple topology can be seen on Figure 3a. When a non-broadcast packet is detected by the multiplexer, the destination MAC is looked up in the iDB. If an entry can be found indicating a corresponding channel, the packet is sent using that channel. If no entry is found, the packet is forwarded over the default interface (interface 1) and subsequently, channel negotiation between sending and receiving node is started as to determine the most appropriate channel for communication between the nodes. As input for the channel selection algorithm, Channel Quality Variables (CQVs) are used. A CQV is a dimensionless variable which acts as an inverse measure to the quality observed by a node at a specific channel: the lower a CQV for a channel, the better it would be to start a new conversation using that channel. Every node holds a vector of CQV values: one CQV for every orthogonal channel the node can tune to. Denote the individual CQV of channel x for node α as CQVαx , and the vector holding CQVα . In our all CQVs of node α as example, CQVA = CQVA1 , CQVA6 , CQVA11 . Channels that are reserved for the transport of data packets are initialized with CQV = 0. The default channel gets an initial penalty and is initialized with a non-zero CQV. When running FRESME without extensions (cf Section III-C), the CQVαx of node α is increased (decreased) in case of following two events: (i) a destination MAC is added to (removed from) channel x in the iDB: +(-)10. (ii) a node interfering on channel x is detected (removed): +(-)4. The choice for these specific values is explained below. In the example of Figure 3, the initialization is as follows: CQVi1 = 7 and CQVi6,11 = 0, i = {A, B, C}. Suppose node A needs to send data packets to B. As no entry of B’s MAC is found in A’s iDB, the channel negotiation procedure is started. In Figure 3b, node A sends a request message indicating that it wants to negotiate with node B in order to make a channel reservation. This message contains the CQVA vector and the
1930-529X/07/$25.00 © 2007 IEEE This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE GLOBECOM 2007 proceedings.
b ting Rou ages s mes
g tin es ou g R ssa e m
Routi mess ng ages
REQ
(B
,0]) ,[8,0
1
broadcast request
[7,0,0]
ACK (B,ch6)
4
broadcast confirmation
[7,0,0]
[7,4,0] 3
REP (A,ch6)
[7,4,0]
[7,8,10] [17,8,10]
a 4
5
b
[7,8,0]
a
[7,0,0]
[7,0,0]
2 broadcast reply
4
[7,0,0]
a
[7,10,8]
[7,10,0]
b
[17,10,8]
3
[7,0,0] (a)
[7,0,0] [7,10,0] (b)
[7,10,0] (c)
a
[7,10,10]
b
[15,10,10]
(d)
Fig. 3. Simple topology illustrating the FRESME protocol. All nodes are within communication range. (a) Starting situation. Routing protocol messages are exchanged, CQV vectors initialized. (b) Node A requests a communication channel from B. B replies with a message containing the chosen channel. The reply message is overheard by C. (c) After sending an ACK message, all traffic between node A and B will be sent on channel 6. (d) The selected channels and impact in CQV vectors after setup, first by selecting a channel for use between C and B, and then additionally between A and C.
intended receiver in the payload, and is sent to the broadcast address using the default interface operating at the lowest data rate. The nodes which are in communication range, i.c. node B and C, receive the request. While it is discarded by node C, the intended receiver B immediately calculates the sum of its own and the received CQV vector, CQVsum = CQVA + CQVB . Node B determines the smallest value in CQVsum and sends out a broadcast reply message, containing the intended receiver A, announcing that the corresponding channel will be selected (i.c., channel 6). Node B also raises its CQVB6 with 10, because traffic will be sent through his interface on channel 6. On a side note: in the current protocol implementation, if a unique smallest variable cannot be found, the first minimum is selected. As will be seen from the simulations in Section IV, this creates an unwanted bias favoring channels with a small channel number. In future versions, a simple random selection will be added. The reply message, announcing the link on channel 6 with node A is received by A. C receives the message as well, learns that it can expect interference on channel 6 and increases its CQVC6 from 0 to 4. Node A in its turn responds to the reply message by sending an extra acknowledgment confirming its connection with node B on channel 6, and raising CQVA6 to 10, cf. Figure 3c. If a node would only be in the communication range of node A and not of node B, that node would still be aware of the fact that traffic was about to start flowing on channel 6. Node C again raises its CQVC6 by 4 after receiving the acknowledgment, as it will suffer interference both from A and B. Figure 3d shows the topology and resulting CQVs after adding extra reservations. A single interface can be used to transmit and receive data to and from multiple nodes. The rationale behind choosing initialization value 7, and increasing by 4 or 10 is the following: suffering interference from one (+4) or two (+4,+4) nearby nodes on a particular channel is considered less harmful than adding an extra flow (+10) to a particular channel on the node itself. In the current configuration, 7 is selected as initialization value for the default channel because, if more than 2 connections with nodes are needed and 3 interfaces are available, the default channel
would still be preferred above a channel that is already in use (+10) on that node. Note that these values can be rescaled in order to allow more granularity when changing the CQVs using protocol extensions. If something goes wrong during the channel agreement procedure, or no traffic is received for a predetermined period of time on a particular channel, for example because of link breaks, a changed topology or termination of an application session, the corresponding reservations are removed from the database and control messages are sent as an announcement. Based on these events and the corresponding messages, the CQVs are decreased accordingly. For clarity, some additional mechanisms and special conditions were left out of the above protocol description. It is however important to note that measures have been taken to prevent a negotiation procedure to start while another negotiation procedure is still in progress. This ensures that no decisions are taken based on outdated information. C. Extending the Scheme The algorithm described above can easily be refined by adding cross-layer protocol extensions to the stack, which impact on the CQV. For example, if the application layer indicates that a link to a certain neighbor needs to have absolute priority, the CQV of the corresponding channel could be raised considerable, making it very unlikely that additional links will be added to the same channel. Also, after the initial configuration which happens very fast, slower measurement techniques can alter the CQVs. This leads to a hybrid approach where initial configuration can happen very fast using a status based method, and is refined afterwards using measurement based methods. Furthermore, one should also be aware that the protocol requires nodes to be within communication range. In order to account for the effect of interfering nodes which are out of the communication range, an agent running in the background can perform noise measurements and carrier sensing. If interference is detected on a certain channel, the responding CQV can be raised.
1930-529X/07/$25.00 © 2007 IEEE This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE GLOBECOM 2007 proceedings.
Finally, we indicate how the FRESME scheme can be extended to support other physical layers such as 802.11a which can make use of more than three non-interfering frequencies. A naive approach would be increasing the number of additional PHY blocks to match the amount of non-interfering channels. However, a more elegant approach is possible, where the number of channels used can be higher than the number of interfaces available. Furthermore, the mesh routers do not need to have the same number of interfaces. Suppose that a certain mesh node has n interfaces and m non-overlapping channels are available. The concept of CQV vectors can still be used, now with a vector of size m: one CQV for every channel the node could tune to. When a new traffic link needs to be configured, a request message can be sent in the same way as described above. However, a second vector of size n should be added to the packet, indicating how many interfaces are already in use at the requesting node, and which channel they are configured to. A zero value might indicate an unused interface. If both sender and receiver still have an unused interface left, the channel with the lowest CQVsum index is selected as a data channel for the data packets after the reservation procedure is completed; The unused interfaces are reconfigured to use the particular channel. If either sender or receiver do not have an unused network interface left, the communication side which has a free interface left can tune an unused interface to the channel that best matches the other side’s needs. The most difficult situation occurs when sending and receiving side both have all data interfaces configured without any matching channels. Two solutions are possible: (i) the default channel can be used. (ii) attempts can be made to reconfigure a wireless interface, e.g. at receiver side, in order to match a channel at the sending side. This can be done by broadcasting a reconfiguration request at the receiver side: the other nodes which already had made channel arrangements with the receiver then can answer this request by telling if still other connections are made using that particular channel. If not, reconfiguration can take place. In the other case, that node can send a reconfiguration message in its turn. IV. P ERFORMANCE ANALYSIS The FRESME protocol has been simulated and implemented using the Click Modular Router [9] software. Click allows programming and modifying networking protocols in a fast and easy way. By using Nsclick [10], Click configurations can be evaluated in the NS-2 [11] network simulator. In order to be able to benefit from the full flexibility offered by the Click platform when simulating our protocol in Nsclick, we have written an ns2 extension called Nsmadwifi. Nsmadwifi supports the wireless features of the Click Modular Router such as rate setting, RTS/CTS and WiFi packet transmission in the ns2 environment. With minor adjustments, the same code can be used both on actual hardware and in the simulator. A. Simulation Results In previous sections, it was shown that the use of FRESME is not limited to a single routing protocol. As the choice of
(a) Data channel configuration. Distance between nodes: 200m
% 45
42.5%
40 35
39.5%
30 25 20 15
18.0%
10 5
(b)
0
ch. 1
ch. 6 ch. 11 (c)
Fig. 4. a. Simple line topology with CBR traffic from node1 to node10. b. 10 x 10 raster topology. The horizontal and vertical distance between the nodes is 200m. The data channel reservation for one of the simulations is displayed. c. Global average distribution of the relative amount of interfering unidirectional reserved links as seen from a node.
routing protocol affects various performance metrics such as throughput or delay, new metrics are defined which focus on the channel distribution only. In our simulations, maximum transmission range was set to 250m. As a routing protocol, OLSR [12], a proactive link state routing protocol was selected, as we already have extensive experience with this protocol from previous work, making it easier to separate channel selection related issues from routing problems. In simple test scenarios such as the 10-node line topology from Figure 4a, the protocol works as expected: routing and control messages are exchanged on channel 1, data is alternately received (sent) using channel 6 or 11. As a first CBR data packet is sent from node 1 to node 10, the FRESME protocol is initiated and the channels to be used are selected. Channel configuration at all nodes is completed soon (i.c., 200ms) after the first data packet has completed its way through the network. If a control packet gets lost or something else goes wrong along the way, some decisions are postponed: e.g., the channel between node 2 and 3 cannot be configured correctly if node 2 is still in negotiation with another node. Therefore, the channel decisions are deliberately postponed for a configurable period τ , set to 2 seconds for testing purposes. Thus, depending on the distance between nodes, the hop count and the data rate, complete channel reservation for a new traffic flow is completed in a time frame starting from a few milliseconds to a maximum of k ∗ τ , where k is the maximum number of times that a certain channel decision along the track is postponed. Note that no packets are lost during that period, as packets are always sent along the default channel as long as the reservation is not completed. In order to measure the efficiency of the FRESME protocol in larger set-ups, simulations were done using the 10x10 raster from Figure 4b. Figures 4c and 5 are average results from 10 simulations, each time with 10 CBR traffic flows with random senders and receivers. In Figure 4c, the global average distribution of the relative amount of interfering unidirectional reserved links as seen from a node is shown. It is calculated as follows: at each node, the number of reserved data paths that either start or
1930-529X/07/$25.00 © 2007 IEEE This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE GLOBECOM 2007 proceedings.
38%
29%
(a)
1% 1% 3% 8%
30%
37% (b)
20%
1% 1% 3% 8%
V. C ONCLUSION
20%
preference: ch. 6 ch. 11 Note: (a) 867 nodes are in statistics unbalance 1: (b) 874 nodes are in statistics unbalance 2: unbalance 3:
reservations are made instantly when initiating a ping from one node to another. If the ping command is stopped, channel reservations are removed after a predefined period.
0 unbalance
Fig. 5. Unbalance statistics. a. Only considering a node’s own reservation choices. b. Also counting interfering links between other nodes. Nodes that did not make any reservations or that are not interfered by any link are excluded from these statistics.
arrive at a node within an interference area of 250m around the node are counted. This includes paths which are used by the node itself, as well as paths between two other nodes which cause interference at the node. Both starting and arriving paths count as 1. Figure 4c shows that a node can expect almost identical interference on both data channels, while only 18% of the reserved data channels that can be seen from a node are configured to the default channel. In this topology, on average, the default channel is loaded with only one-fifth of the data traffic, while the data channels each carry two-fifths of the data traffic. Whether the default channel is used as a reserved data channel or not, the number of connections using channel 6 or 11 should ideally be equal. Figure 4c showed that this is the case when considering a global average. Nevertheless, at the nodes locally, there can be a different number of reserved links using channel 6 or channel 11. This difference is called unbalance. For example, if within 250m of a node, 4 unidirectional links can be seen set to channel 6, and 3 links set to channel 11, there is an unbalance of 1. Note that an uneven unbalance is simply caused by the fact that a choice for one or the other data channel needs to be made and is not a real fault in the channel distribution. Details on the unbalance are found in Figure 5. Figure 5a shows the unbalance statistics when every node only counts its own reserved connections, but interfering connections between neighboring nodes are not counted. From this figure, it can be seen that at 38% of those nodes which did make reservations, there is no unbalance. Additionally, 49% of the nodes only experiences an unbalance 1: 29% sees one extra link on channel 6, while 20% sees an extra link on channel 11: channel 6 will carry slightly more traffic due to the bias effect explained in Section III-B. Only in the remaining 13% the unbalance is higher than 1, thus, locally, interfaces only rarely make a decision which overloads a single interface. In Figure 5b, links which cause interference at a node but are not used by the node itself are also included in the statistics. The results are almost identical: 87% of the nodes experience an unbalance of 0 or 1. B. Real Life Evaluation The FRESME protocol has also been evaluated on a three node testbed. Due to the small size of the testbed, it is hard to formulate any meaningful quantitative results. However, functional tests have been performed and showed a successful implementation on actual hardware. During the tests, channel
In this paper we presented the FRESME protocol which performs on demand distributed channel selection in multi channel, multi interface wireless mesh networks. We have shown that the protocol is able to configure channels on a per link base almost instantly when new wireless links are needed in the network. The protocol does not require longterm traffic profiles nor does it periodically broadcast any control traffic and thus adds very little overhead: if no errors occur during link negotiation, a channel reservation is made using only 3 control packets. Extensions can easily be added to the FRESME protocol by operating on the channel quality variables. We have proven the efficiency and feasibility of the algorithm both by simulation and implementation. It was shown that in a raster topology, globally, the channels reserved for data communication are equally loaded. Locally, at 87% of the nodes, the link to data interface mapping is optimal. ACKNOWLEDGMENT S. Bouckaert thanks the Institute for the Promotion of Innovation through Science and Technology in Flanders (IWTVlaanderen) for funding this research through a grant. This research is also partly funded through the IBBT-Cisco EyeSense project. R EFERENCES [1] I. F. Akyildiz, X. Wang, and W. Wang, “Wireless mesh networks: a survey.” Computer Networks, vol. 47, no. 4, pp. 445–487, 2005. [2] D. J. Leith and P. Clifford, “A self-managed distributed channel selection algorithm for WLANs,” in 4th Intl. Symp. on Modeling and Optimization in Mobile, Ad Hoc and Wireless Networks, Boston, MA, Apr. 2006, pp. 1–9. [3] A. Adya, P. Bahl, J. Padhye, A. Wolman, and L. Zhou, “A multi-radio unification protocol for ieee 802.11 wireless networks,” in Broadnets ’04, Los Alamitos, CA, USA, 2004, pp. 344–354. [4] J. Li, Z. J. Haas, M. Sheng, and Y. Chen, “Performance evaluation of modified IEEE 802.11 MAC for multi-channel multi-hop ad hoc network,” in 17th International Conference on Advanced Information Networking and Applications, Xi’an, China, March 2003, pp. 312–317. [5] P. Porwal and M. Papadopouli, “On-demand channel switching for multichannel wireless mac protocols,” in 12th European Wireless Conference, Athens, Greece, 2006. [6] A. Raniwala, K. Gopalan, and T. cker Chiueh, “Centralized channel assignment and routing algorithms for multi-channel wireless mesh networks,” SIGMOBILE Mobile Computing and Communications Review, vol. 8, no. 2, pp. 50–65, 2004. [7] J. Tang, G. Xue, and W. Zhang, “End-to-end rate allocation in multiradio wireless mesh networks: cross-layer schemes,” in QShine ’06: Proceedings of the 3rd international conference on Quality of service in heterogeneous wired/wireless networks, Waterloo, ON, Canada, 2006. [8] W. Hung, K. Law, and A. Leon-Garcia, “A dynamic multi-channel mac for ad hoc lan,” in Proceedings of the 21st Biennial Symposium on Communications, Kingston, Canada, april 2002. [9] The click modular router project. [Online]. Available: http://pdos.csail.mit.edu/click/ [10] The nsclick simulation environment. [Online]. Available: http://systems.cs.colorado.edu/Networking/nsclick/ [11] The network simulator. [Online]. Available: http://www.isi.edu/nsnam/ns [12] T. Clausen et al., “Optimized link state routing protocol (olsr),” IETF, RFC Experimental 3626, October 2003.
1930-529X/07/$25.00 © 2007 IEEE This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE GLOBECOM 2007 proceedings.
