- Email: [email protected]
Link-state routing without broadcast storming for multichannel mesh networks
Computer Networks 54 (2010) 330–340
Contents lists available at ScienceDirect
Computer Networks journal homepage: www.elsevier.com/locate/comnet
Link-state routing without broadcast storming for multichannel mesh networks q,qq Cheolgi Kim *, Young-Bae Ko, Nitin H. Vaidya Coordinated Science Laboratory, University of Illinois, 1308 W Main St., Urbana, IL 61801, United States
a r t i c l e
i n f o
Article history: Available online 16 September 2009 Keywords: Wireless mesh networks Link-state routing Multichannel wireless networks
a b s t r a c t A link-state routing protocol tailored for multichannel mesh networks is proposed. One drawback of using multichannel communications is the high overhead involved in broadcast operations: a transmitter should transmit a broadcast packet to all channels that may be occupied by receivers. This makes certain broadcast-intensive mechanisms, such as link-state routing, difficult to implement. The link-state routing protocol proposed in this paper is tailored for multichannel mesh networks by minimizing the broadcast overheads. This is achieved by a special set of nodes, called cluster-heads. We have implemented our protocol on a multichannel mesh network test bed and compared its performance with an AODV-like reactive routing protocol, also tailored for multichannel mesh networks. The measurements show that the proposed link-state routing protocol provides transient communications with comparable or better performance. Ways to improve the performance of the proposed routing with infrastructure access is also discussed. Ó 2009 Elsevier B.V. All rights reserved.
1. Introduction Wireless networks have been successful in both commercial and residential deployments. While last-mile, single-hop wireless networks, such as wireless local area networks and cellular networks, have achieved significant popularity, mobile ad-hoc (MANET) and multihop networks have gained little practical attention despite significant academic contributions in the area. This is due mainly to two reasons: (1) purely ad-hoc networks without connectivity to the Internet do not have much practical application and (2) data in an ad-hoc network may have to be routed through vulnerable intermediate nodes, making it less attractive for commercial deployments. Wireless mesh networks overcome these difficulties by allowing
q A preliminary version of this paper was presented in IEEE MILCOM 2008. qq The work in this paper was funded by The Boeing Company. * Corresponding author. Tel.: +1 217 636 4177. E-mail addresses: [email protected] (C. Kim), [email protected] (Y.-B. Ko), [email protected] (N.H. Vaidya).
1389-1286/$ - see front matter Ó 2009 Elsevier B.V. All rights reserved. doi:10.1016/j.comnet.2009.09.002
for a gateway node that has connectivity to the Internet. Furthermore, relay nodes (different from client nodes) deployed by the operators provide reliable multihop connections between client nodes and gateway nodes. In their seminal paper [1], Gupta and Kumar derived the capacity bounds of a wireless ad-hoc network and showed that placing additional relay nodes in the network helps to achieve significant capacity gains. Additionally, in [2], Kyasanur and Vaidya have analyzed the capacity bounds of a wireless network when multiple channels are used. Accordingly, though there are no asymptotic capacity benefits with multiple channels (rather than a single channel), in practical networks they have several advantages. This is because multichannel networks encourage more transmissions in the network, as the amount of contention per channel is significantly reduced. Much of the existing literature on multichannel networks proposes use of multiple interfaces (or wireless radios) to provide simpler multichannel operation [2–4]. The main challenges in a multichannel wireless network lie in developing protocols for exploiting the flexibility offered by using all the channels available for operation.
C. Kim et al. / Computer Networks 54 (2010) 330–340
Due to the difficulties involved in coordinating the nodes in a multichannel network, each of which may operate on a different channel, traditional protocols designed for single-channel networks may not directly apply in a multichannel setting. In this paper, we discuss a link-state routing mechanism, called MCLSR (Multi-Channel Link-State Routing), tailored for a multichannel mesh network. Link-state routing has been a popular routing methodology in wired networks. In this approach, each node maintains the link-state information of the entire network and makes route decisions based on this information. To keep link-states fresh, each node periodically announces its link-state to all the other nodes. Although link-state routing has relatively high control overheads due to the associated link-state information exchange, it provides quicker route discoveries without additional route discovery packets. Moreover, because the routes are constructed using a global knowledge of the network, they are highly optimized. While link-state routing has been less popular in MANETs because of the associated topology dynamics caused by node mobility,1 it has recently been reconsidered for mesh networks due to their relatively stable topology compared to MANETs. Moreover, the optimized routing achievable using a link-state routing protocol is more attractive for a multichannel environment, as routing decisions can be based not just on the channel quality of each link but also on the sequence of the channels to be used in a route. This can significantly affect end-to-end throughput [3]. Most of the existing designs of wireless link-state routing protocols exploit the broadcast nature of the wireless medium for propagating the link-state information [5]. However, since the broadcast overheads in a multichannel network are much higher than in a single-channel environment, the existing implementations of the link-state routing protocols are best not directly applied to multichannel networks. Notice that in a multichannel network, a transmitter should transmit a broadcast packet on all channels that might be occupied by a receiver, thereby increasing the overhead involved. To minimize broadcast overheads, we propose a set of cluster-head nodes, elected dynamically for exchanging the link-state information over the network. The cluster-head nodes collect the link-state information from their dependent nodes and share it with other cluster-heads. The receiving cluster-heads rebroadcast the shared link-state information to their dependents to propagate the link-states over the entire network. We discuss the procedure involved in more detail in Section 4. We have implemented our protocol on a real multichannel mesh network test bed with two IEEE 802.11a interfaces per node. We discuss the implementation issues and the experimental results in Section 5. Our results show that the link-state routing mechanism provides transient communication with comparable or better performance. The mechanisms for improving the performance of the proposed routing approach using infrastructure access are discussed in Section 6. Section 7 concludes the paper.
1 When the topology changes dynamically, the link-states have to be frequently distributed, which may cause intensive control overheads.
331
2. Related work Since the concept of a mobile ad-hoc network (MANET) emerged, several variants of the original link-state routing protocol tailored for the networks have been proposed. Jacquet et al. proposed the Optimized Link State Routing Protocol (OLSR) [5]. In this protocol, each node selects a set of multipoint relay nodes, and link-state broadcast is performed only by this selected set of nodes. This, in turn, reduces the nunber of broadcast messages in the network. Furthermore, the link-states of only a subset of links are globally managed. OSPF-MANET (Open Shortest Path First for MANET) is a link-state routing protocol proposed by the IETF OSPF working group [6]. OSPF-MANET extends OSPF, which is widely used in wired networks, to wireless networks. It also allows only subset of nodes for broadcast flooding. When a subset of link-states is propagated, control overhead is reduced. Meanwhile, discovered routes are likely to be suboptimal. In multichannel mesh networks, end-to-end throughput can be significantly degraded by selecting a suboptimal sequence of channels in a route. Sivakumar et al. proposed CEDAR (Core-Extraction Distributed Ad Hoc Routing) [7], a link-state routing mechanism designed for real-time applications. In CEDAR, Selected core nodes perform unicasts between them to propagate link-states, as in our approach. However, its design does not reflect the multichannel characteristic of wireless networks. Draves et al. proposed WCETT (Weighted Cumulative Expected Transmission Time) as a multichannel, multi-interface routing metric and a linkstate routing protocol, LQSR (Link-Quality Source Routing) [3]. LQSR is a source-routed, link-state protocol derived from DSR. The routing protocol was implemented on a test bed and the performance between routing metrics was compated. Kyasanur and Vaidya proposed a multi-radio wireless network architecture, Net-X, and a routing metric [2]. They also proposed a reactive routing protocol, and implemented them on a test bed [8]. The Net-X architecture is used as an implementation base in this paper. Intelligent channel allocation is often viewed as a way to improve the performance of a multichannel wireless network. Most channel allocation algorithms proposed in the literature can be classified into two categories: centralized and distributed. Centralized approaches are designed to globally optimize potential interferences regarding the full topology of networks [9–12]. Distributed approaches locally optimize the channel distribution in heuristics [2,13]. To the best of our knowledge, no approach has been proposed to assign channels dynamically with regard to traffic patterns and routes, which we address in Section 6.
3. Network model A wireless mesh network consists of two kinds of nodes: mesh nodes and client nodes. The mesh nodes form a backbone network, which provides network connectivity to the client nodes. Every client node associates itself with a mesh node, which performs packet forwarding through the rest of the backbone network. A wireless routing protocol, such
332
C. Kim et al. / Computer Networks 54 (2010) 330–340
as the one discussed in this paper, is used for forwarding packets within the backbone network. The multichannel mesh network considered in this paper is based on the Net-X architecture [8]. Before proceeding further, we first provide a brief overview of the Net-X architecture. 3.1. Net-X Overview The multichannel mesh network consists of a set of wireless nodes, each of which is equipped with two wireless interfaces. One of the two interfaces remains fixed on a channel; this is called the ‘fixed’ interface. The other interface is capable of switching across channels whenever required and hence is called the ‘switchable’ interface. We call the channel in which the fixed interface of a node operates the ‘fixed channel’ of that node. Only the fixed interface is used for receiving data. The fixed interface can also be used for transmitting data on the fixed channel. Transmissions on the other channels are handled by the switchable interface. Packet transmission between two nodes on two different fixed channels is handled by switching the channel on the switchable interface of the transmit node to the fixed channel of the receive node. For instance, suppose a node u has a packet for a node, v that is on a different fixed channel. The switchable interface of u is tuned (switched) to the fixed channel of v, and the packet is transmitted on that channel. If both nodes u and v were on the same fixed channel, then node u’s fixed interface would be used for the transmission (no channel switch is required). If a node has a broadcast packet, it sends the packet on all the channels, as every single channel may be in use by a neighbor. For this purpose, the switchable interface performs round-robin channelswitching through all channels except the fixed channel. Observe that every node has to be assigned a fixed channel for packet receptions. Furthermore, every node must be aware of the fixed channels assigned to its neighbors in order to communicate with them. Due to the Net-X architecture of the backbone network, each fully capable client node is supposed to have dual interfaces as well. Let G ¼ ðV; EÞ denote the backbone network, where V is the set of dual interface nodes in the network and E is the set of links between the nodes. A link ðu; vÞ 2 E exists between two nodes u; v 2 V if they are within communication range of each other. Let C denote the set of channels to be assigned to the nodes and ~ qðu; vÞ represent the unidirectional link quality of a link ðu; vÞ 2 E. The bidirectional link quality qðu; vÞ is defined by a function of the pair of qðu; vÞ; unidirectional link qualities such that qðu; vÞ ¼ gð~ ~ qðv; uÞÞ. In our implementations it is simply defined as:
qðu; vÞ ¼ gð~ qðu; vÞ; ~ qðv; uÞÞ ¼ ~ qðu; vÞ ~ qðv; uÞ: A subset of nodes in V are destined to be the ‘clusterhead’ nodes, and we denote this subset as V C . We will explain more about the cluster-head nodes later. Additionally, we assume that every node in the network has two types of neighbor sets, namely tight neighbors ðN t Þ and loose neighbors ðN l Þ, depending on the quality of the link with the neighboring nodes. In general, every node maintains two common link threshold values, Thl and Tht , such that Thl < Tht . N l and N t are defined by Thl and Tht such that
Nl ðv 2 VÞ ¼ fuju 2 Vandqðu; vÞ > Thl g Nt ðv 2 VÞ ¼ fuju 2 Vandqðu; vÞ > Tht g: Note that N t N l because Thl < Tht should be satisfied. Due to transient link conditions, N l ðvÞ and N t ðvÞ change over time. These sets are used in cluster-head selection (see Section 4). 4. Multi-Channel Link-State Routing protocol MCLSR is a modified link-state routing protocol for multichannel mesh networks tailored to minimize broadcast overhead due to link-state propagation. For immediate response of a network to end users, all nodes keep the link.state information of a network. In typical implementations of wireless link-state routing mechanisms, such as OLSR and OSPF-MANET, this is achieved using broadcast flooding. In our network model, the overhead of broadcast is jCj times larger than in a single-channel network, where jCj is the number of channels used in the network. Minimizing the broadcast overhead, therefore, is one of the primary goals of our protocol. In MCLSR, nodes are classified into two disjoint categories: cluster-heads and dependents. Once a node is chosen as a cluster-head, some of the other nodes that are within one hop of this node become its dependents. Each dependent can have multiple neighboring cluster-heads. but one and only one of them is identified as its master cluster-head. A cluster-head cannot have another cluster-head as its tight neighbor (N t ), as a rule.2 A cluster-head along with its dependents form a cluster. A cluster-head is responsible for gathering and distributing the link-state information to its dependents. Fig. 1a shows an example of a network using MCLSR. Shaded nodes are cluster-heads, and non-shaded nodes are dependent nodes. A cluster-head and its dependents are connected by solid lines, and the other neighboring pairs of nodes are connected by dotted lines. Each dependent node is in only one cluster. The cluster has only one cluster-head node, which is master cluster-head of the cluster. Any other neighboring cluster-head node is considered to be a generic neighbor to a dependent node. Sometimes, a cluster may contain only one node (a cluster-head), such as node K in the figure. Fig. 1b shows how the link-states are propagated from a cluster node to the entire network. Link states of the cluster members are delivered to cluster-head C through ‘hello messages.’ Cluster-head C constructs a ‘cluster link-state’ that contains all the link-states of its cluster members. The link-state of an individual node is called the ‘node link-state’. Each cluster-head periodically distributes the cluster link-states to other cluster-heads through intercluster-head unicasts, which is presented by dashed arrows in Fig. 1b. The delivered cluster link-state is broadcast to its own cluster members. Hello messages and inter-cluster-head messages are the only control messages in MCLSR. The message formats of 2 If a pair of cluster-heads indicate that they are tight neighbors of each other, one of them will lose the privilege of being a cluster-head according to the protocol.
C. Kim et al. / Computer Networks 54 (2010) 330–340
333
contains the link qualities. Node information consists of a sequence number, which is incremented for every hello message, a cluster-head indicator (CI) bit, which indicates whether this node is a cluster-head, and the fixed channel used by the fixed interface. The CI bit in the link information helps in cluster-head discoveries. The link information, on the other hand, contains the directional link quality, which is measured from incoming hello messages. Notice that the total link quality, which is used by the routing protocol as a metric, is a function of a pair of directional link qualities (outgoing and incoming). Because each node can only measure the link quality in the incoming direction, the link quality field of a node link-state contains that directional link quality, which is ~ qðu; vÞ, where u is the outgoing node and v is the incoming node. The other directional link quality is collected from the node link-state of the node at the opposite side of the link. Then, the total link quality is calculated from the pair of directional link qualities. In our protocol implementation, directional link quality is the proportion of successful hello message deliveries. The total link quality of a link is given by ð~ qðu; vÞ ~ qðv; uÞÞ. 4.3. Cluster link-state
Fig. 1. Example topology of MCLSR.
the hello messages and the inter-cluster-head messages are discussed in the next section. 4.1. Node link-state and cluster link-state Node link-state and cluster link-state are the internal control information units distributed by control messages, such as hello messages and inter-cluster-head unicast messages. Fig. 2 depicts their internal structure.
Cluster link-state message consists of the link-states of all the cluster members. It is formed by concatenating the link-state structure of each of the cluster members as shown in Fig. 2. 4.4. Control messages 4.4.1. Hello message The purpose of the hello message in MCLSR is as follows: 1. Distribution of up-to-date node link-states 2. Periodic link quality measurement on the receiver side, and 3. Distribution of cluster link-states from a master-cluster-head to its dependents.
4.2. Node link-state The node link-state is the basic data structure in both the hello message and the inter-cluster-head message. A node link-state consists of node information that contains the state of the node, and a set of link information that
Fig. 2. Link-state information structure.
A dependent node periodically transmits a hello message containing its node link-state. Every dependent node, upon receiving a hello message sent by another node in the neighborhood, updates its link-state database. Additionally, it measures the directional quality of the link, ~ qðu; vÞ, where v is the receiving node, from each of its neighbors, u, based on the received hello messages. For measurement accuracy, the size of hello message is fixed to 1024 bytes. Hello messages are zero padded, if required, to satisfy this fixed size criterion. Fig. 3a describes the structure of a hello message sent by a dependent node. As seen in the figure, a dependent node prepares a hello message by attaching the address of its master cluster-head to the node link-state information. The acknowledged master cluster-head includes the received node link-state to its cluster link-state. A cluster-head node sends a hello message to its cluster members to update them with the link-state information of other clusters in the network. Every cluster-head that has received one or more cluster link-state unicast messages
334
C. Kim et al. / Computer Networks 54 (2010) 330–340
tions, Eq. (1) ensures that every node is within a one-hop neighborhood of a cluster-head, and Eq. (2) minimizes the density of cluster-heads by ensuring that no two cluster-heads are tight neighbors of each other. In fact, to manage N l and N t separately seems to just make the protocol complicated. These two set of neighbors can be defined to be identical and can be called just ‘neighbors,’ which makes the protocol much simpler and easier to understand. However, we distinguish N l and N t to reduce control overhead caused by frequent cluster-head re-selection. Semantically, Eq. (1) is the condition to promote a cluster-head, and Eq. (2) is the condition to demote a cluster-head. N l ðvÞ in Eq. (1) makes promotion harder. But once a node is promoted to cluster-head, it will not be easily demoted because the demotion is based on N t ðvÞ. This prevents frequent change of network configuration, which can make the network unstable. Fig. 3. Control message structures.
from other cluster-heads broadcasts them to its dependents through the hello message along with its own node link-state information. The message format of the hello message sent by a cluster-head node is shown in Fig. 3a. As we mentioned earlier, cluster link-state is periodically propagated over the network. It is supposed to be less frequent than a hello message. In MCLSR, the rate of hello message is t c times the rate of cluster link-state propagation. Thus, tc hello messages are sent by the time a cluster link-state is issued by a cluster-head. An extended hello message is also issued for every t c hello messages. The structure of extended hello message is also shown in Fig. 3a. In an extended hello message, there is an additional field called the cluster-head list, where the master-clusterhead includes a list of known cluster-heads. This helps cluster-head discovery, as explained later.
Algorithm 1. Decision to be a cluster-head for node v Require Collected link-state information Ensure Decision to be a cluster-head 1: if v 2 V C then 3: NðvÞ ( N t ðvÞ 4: else 5: NðvÞ ( N l ðvÞ 6: end if 7: if NðvÞ \ V C ¼ £ then 8: return TRUE 9: else 10: if 8u 2 NðvÞ \ V C ; idðvÞ > idðuÞ then 11: return TRUE 11: else 12: return FALSE 13: end if 14: end if
4.5. Inter-cluster-head unicast message For every t c hello messages, an inter-cluster-head unicast message is sent to other cluster-head nodes indicating the cluster link-state. The structure of this message is described in Fig. 3b. It consists of the cluster link.state along with the list of known cluster-heads, like an extended hello message. Optionally, a dependent node also can send out an inter-cluster-head message to another cluster-head for cluster-head discovery. In this case, the dependent nodes slice a inter-cluster-head message out of the extended hello message received from its master-cluster-head. The details are described in Section 4.7. 4.6. Cluster-head selection procedure The cluster-head selection is performed based on the following rule:
8v 2 V; 9n 2 V C ; such that n 2 Nl ðvÞ 8m; n 2 V C ; m R Nt ðnÞ
Algorithm 1 describes the cluster-head selection procedure. It is run by each node independently, just before the hello message is issued. Here, idðvÞ is the unique identifier of a node v, which can be the node’s IP address (used in our implementation). How to assign a unique id (or IP address) is beyond the scope of this paper, but a recommended id assignment policy is discussed in Section 6. According to Algorithm 1, each node checks whether there is clusterhead in its neighborhood (Eq. (1)). If not, the node itself becomes a cluster-head and generates a unique cluster-head id. If a cluster-head is a tight neighbor of another clusterhead, then the cluster-head with the smaller id is demoted to dependent (according to Eq. (2)). By performing these decisions, no node is left without a cluster-head, and no pair of cluster-heads become tight neighbors in the steady state. Additionally, if a node sees multiple cluster-heads in its neighborhood, then it chooses the one to which link quality is the strongest as its master-cluster-head.
ð1Þ ð2Þ
where N l and N t denote the loose and tight neighbors of a node, respectively (see Section 3). Among the two equa-
4.7. Cluster-head discovery Once a cluster-head is elected, it has to discover the other cluster-heads in the network for propagating the
C. Kim et al. / Computer Networks 54 (2010) 330–340
cluster link-state information via unicast messages. Notice that a cluster link-state is delivered to designated nodes, which are the cluster-head’s dependents (via hello message) and other cluster-heads (via inter-cluster-head message), whichever the master-cluster-head is aware of. If a designated node knows more cluster-heads than the master-cluster-head, it forwards the cluster link-state to those cluster-heads. As a result, a cluster link-state is propagated farther than expected. This may result in discovery of an unknown cluster-head receiving the forwarded link.states. In this section, we explain how cluster link-state is forwarded farther. We call such a cluster link-state ‘cluster-head discovery’, as it aides in the discovery of a new cluster-head. Cluster-head discovery is performed in two phases: (1) neighbor-cluster-head discovery and (2) non-neighbor-cluster-head discovery. The following lemma supports the discovery algorithm. Suppose that the network does not change its topology while the discovery algorithm is running (the network is in a steady state). In accordance with the lemma, every cluster-head must discover all the other cluster-heads by the algorithm as long as the network is connected. Notice that the notion that ‘The network is connected’ means that the network is not partitioned; in other words, a path between any pair of nodes is available. 4.7.1. Neighbor-cluster-head discovery Lemma 1. If a graph GC ¼ ðV C ; EC Þ is the graph that connects every pair of cluster-heads in three-hops, the following is satisfied: GC is a connected graph if and only if G is a connected graph. If GC is connected then G is connected for sure because cluster-heads are all connected and their dependents are connected to cluster-heads. Suppose that G is connected but GC is not connected as a contradiction. It means that GC is partitioned. Suppose that GC has two disconnected groups of cluster-heads, then they are at least four hop distant. Then, there should be a node which is not a cluster-head and at least two-hop distant from any cluster-head. Then, that node cannot have a neighbor-cluster-head, but should be a dependent. It is against the protocol. Lemma is proven. From Lemma 1, we have that a network is connected if cluster-heads are connected in GC . A pair of cluster-heads, u and v, are called neighbor-cluster-heads when ðu; vÞ 2 EC . If they are at one-hop of each other, the discovery is trivial, as the nodes come to know each other through their respective hello messages. If they are at a two-hop distance, then there exists a node w, such that w 2 N l ðuÞ and w 2 N l ðvÞ. Thus, the nodes u and v can listen to w’s hello
Fig. 4. Three-hop cluster-head discovery.
335
message, which contains the link-states of ðw; uÞ and ðw; vÞ. As shown in Fig. 2, the link information of this hello message contains a ‘cluster-head indicator’ that indicates whether the node on the other side of a link is a clusterhead. Thus, nodes u and v can learn about each other through w’s hello message. Discovering a three-hop cluster-head is a little tricky. Fig. 4 shows an example of a three-hop cluster-head discovery. According to this figure, nodes u and v are cluster-heads, and nodes w and x are dependent nodes that lie between u and v. Let us assume that the cluster-heads u and v do not know about each other to start with. As mentioned before, node u periodically sends out an extended hello message containing cluster link-state information and the list of known cluster-heads to all it dependents. Incidentally, node w becomes aware of the presence of node v within its two-hop neighborhood through hello messages sent by node x. Thus, upon receiving the extended hello message from u, node w compares the list of cluster-heads (contained in the extended hello message) with the list of cluster-heads known to it through hello messages. If there is a mismatch between these two lists (which will be the case here, as the list sent by u will not contain v), the node w prepares an inter-cluster-head message from the extended hello message by retaining the self cluster link-state information and the cluster-head list fields (and chopping off the rest of the fields). It sends this message to the cluster-heads that are missing in the list sent by u. Thus, node w will send the inter-cluster-head message to node v. This way, node v can discover that u is a cluster-head (from the self cluster link-state information). Similarly, node u can learn about node v through an inter-cluster-head message from node x or through a subsequent inter-cluster-head message from node v. Because neighbor cluster-heads are cluster-heads in three-hops, all neighbor cluster-heads discover each other.
4.7.2. Non-neighbor-cluster-head discovery The procedure for non-neighbor-cluster-head discovery is performed similarly to that of neighbor-cluster-head discovery. Once a cluster-head receives an inter-cluster-head unicast message, it parses the cluster-head list to look for any known cluster-heads that are not contained in the received list. If it finds any, it forwards the received inter-cluster-head message to the missing cluster-heads immediately. The missing cluster-heads in turn can learn about the original cluster-head that sent the intercluster-head message. The procedure for forwarding the inter-cluster-head message to the missing cluster-heads is discussed in Algorithm 2. Once each undiscovered pair of cluster-heads exchange their cluster link-states, they will be aware of each other; discovery is done. By neighbor-cluster-head discovery, all neighbor-cluster-heads are discovered. By non-neighbor-cluster-head discovery, link-states are forwarded to unknown clusterheads, which results in cluster-head discovery for the receiver of the forwarded link-state. As a result, in a connected network, all cluster-heads are discovered through the link-state forwarding procedure by Lemma 1.
336
C. Kim et al. / Computer Networks 54 (2010) 330–340
1
Algorithm 2. Basic link-state propagation to undiscovered cluster-heads Ensure Decision to be a cluster-head Require Inter-cluster-head message M is arrived. h i ðmsgÞ 1: M :¼ L; V C 2: L: delivered cluster link-state ðmsgÞ
3: V C 4: 5:
: Cluster-head list in inter-coord. msg.
ðrxÞ V C : known cluster-heads of the receiver ðuncoveredÞ ðmsgÞ ðrxÞ ðuncoveredÞ VC ( VC n V C 6: if V C –
£
then 7:
h i ðrxÞ ðuncoveredÞ M new ( L; V C [ V C ðuncoveredÞ
8: send M new to the nodes 2 V C 9: end if
by unicast
CDF
0.8 0.6 0.4 MCLSR Reactive
0.2 0 0
1000
2000 3000 4000 initial round trip time (ms)
5000
Fig. 6. CDF of packet turnaround time to measure route discovery time for MCLSR and reactive routing.
set and are controlled by the Madwifi driver. The wireless drivers are modified to obtain shorter channel-switching time. More details on the software architecture can be found in [14].
5. MCLSR implementation
5.2. Performance measurements
5.1. Test bed platform
5.2.1. Route discovery time Time required for a route discovery is an important metric in wireless mesh networks for transient response to end users. We have measured route discovery time of MCLSR and the reactive protocol. To measure route discovery time, fifteen Soekris boxes were deployed on the fourth floor of Coordinated Science Laboratory building of the University of Illinois. Each box had two Atheros 802.11a interfaces as the fixed and switchable interfaces. Fig. 5 depicts our monitoring program, which displays 15 running nodes in the building. In the measurements, node 6 in Fig. 5, located at the top-right corner, played the role of gateway node, making
We implemented our MCLSR protocol over the IEEE 802.11a MAC protocol. IEEE 802.11a proposes 12 orthogonal channels in the 5 GHz band. In practice, however, only five to six channels can be concurrently used with off-theshelf devices due to adjacent channel interference, as shown by measurements [14]. The protocol is implemented on the Linux 2.4.26 kernel. The main MCLSR protocol runs as a service daemon, and system-oriented parts, such as network packet hooks and radio interface bonding (for multi-radio operation), are implemented as kernel modules. The wireless cards are based on the Atheros chip-
Fig. 5. Node deployment for experiments.
337
C. Kim et al. / Computer Networks 54 (2010) 330–340
1.2 Per-flow goodput (Mbps)
down-link routes to all the other nodes. By measuring packet turnaround times from the gateway to each destination node, one by one, we captured the cumulative distribution function of route discovery time3 in Fig. 6. The result presented in the figure is obvious. MCLSR has much shorter route discovery time than reactive routing. Because reactive routing has to discover a route using broadcast flooding, it requires a certain amount of delay for the destination node to gather enough information for a route with performance. However, MCLSR is ready for transmitting a packet to any destination beforehand.
1 0.8 0.6 0.4
MCLSR: 0.8Mbps Reactive: 0.8Mbps MCLSR: 1.6Mbps Reactive: 1.6Mbps
0.2 0
5.2.2. Goodput comparison We also measured average end-to-end goodput in a random communication scenario. At this time, 23 nodes were deployed in a building, eight more than the previous experiment in a configuration similar to Fig. 5. Three communication channels were selected and used for the measurement. In this experiment, every node initiated UDP traffic at a random time to a random destination to realize a random communication scenario for average end-to-end goodput measurements. The details of the experiment are as follows: Before the start of experiment, every node randomly chose a communication starting time between 0 and 90 s. Additionally, the nodes randomly selected a target node uniformly among all the other nodes. Traffic was generated from the chosen starting time to the selected target. Traffic from a source node was sustained only for a given duration, called communication duration. Communication duration was set constant within a run but varied, run by run, from 2 to 10 s. The data rate per flow also varied, run by run, either 0.8 or 1.6 Mbps in our experiment. UDP packet size was 1024 bytes. Every experiment used the same trace of a packet-generation pattern to make the comparison fair. The experiment ran with either reactive routing or MCLSR. The goodput was measured as follows: The target node sent an acknowledgment packet for the last 20 packets of the traffic; this packet contained the amount of the delivered data. The source node was able to capture some of the acknowledgments, and the last received acknowledgment was used to calculate the goodput. The goodput was given by the delivered data from the acknowledgment packet divided by the time from the first packet transmission to the last acknowledgment reception. Fig. 7 shows average per-route goodput with respect to communication duration. For each combination of measurements, five runs were performed, and the performance was averaged. Results showed that when communication duration is tuned to be short, MCLSR performs better with obvious margin because of the route discovery overhead in reactive routing. As communication duration gets longer, the performance gap between MCLSR and the reactive routing closes. Notice that many Internet applications are timesensitive and bursty. The result shows that link-state routing such as MCLSR is more suitable for wireless mesh networks. 3 Strictly speaking, it includes route discovery time plus packet turnaround delivery time.
0
2 4 6 8 Communication duation per flow (s)
10
Fig. 7. Average per-route goodput for MCLSR and reactive routing with respect to communication duration per flow.
6. Discussions 6.1. Role assignment strategy in MCLSR with infrastructure access For network stability and performance, it is important to assign the role of cluster-head or dependent appropriately. ‘Mesh nodes are obviously preferable to client nodes to serve as cluster-heads because of their stability; client nodes can move or disappear at any time. However, gateway nodes are not recommended as cluster-heads, even though they are also a sort of mesh node. Cluster-heads are expected to have higher control overheads than dependent nodes. If a gateway node is selected as a cluster-head, it will be overloaded by control packets as well as data packets. 6.2. Routing metrics and dynamic channel assignment in MCLSR MCLSR can be used with any multichannel routing metric. In our implementations, we use two routing metrics, case-by-case, in terms of traffic load per route. This dual routing metric approach was tailored to be used with a dynamic channel assignment scheme. The detail of dual metrics and dynamic channel assignment is described in the following paragraphs. 6.2.1. Hot routes and cold routes Suppose that a route is heavily loaded, and packets will be delivered back-to-back. In addition, two adjacent links share the same fixed channel. These two links cannot be active simultaneously because of interference between them. The maximum throughput of the route will be reduced because of this selective activation of the links. This is called self-interference. Due to self-interference, performance is affected not only by the quality of individual links but also by the channel sequence of a route [2,4]. Therefore, the routing metrics for multichannel mesh networks do well to include a self-interference mitigating strategy, as in MCETT [2] and WCETT [3].
C. Kim et al. / Computer Networks 54 (2010) 330–340
If a route is not heavily loaded, packets do not need to be delivered densely. Here a simple routing metric based on link quality may work well and consume fewer network resources than a complex metric when it comes to selfinterference.4 The saved network resources can be used for other routes. Thus, we propose to use different routing strategies for hot routes, which have heavy traffic, and cold routes, which have light traffic. The basic cost cðu; vÞ of a link ðu; vÞ is defined by the inverse of the link quality qðu; vÞ as:
cðu; vÞ ¼
1 : qðu; vÞ
ð3Þ
For a cold route, Eq. (3) defines the cost of each link, and the shortest path is selected for a route. If a route is hot, routing strategy is changed. In our implementation, the route is declared to be hot if there are more than 20 packets transmitted to the route in two seconds at the source node. Once a route becomes hot, the cost function of a link is changed, such that
^cðu; vÞ ¼
cðu; vÞ
iff ðuÞ – f ðvÞ
pcðu; vÞ iff ðuÞ ¼ f ðvÞ
ð4Þ
where f ðvÞ is the fixed channel of node v, and p is the penalty factor. In our implementation, p is set to 1.5. Eq. (4) gives some penalty cost to a link between a pair of nodes with the same fixed channel. For a consistent view of the hotness of a route, source routing is applied for hot routes. The routing table is announced from the source node for a hot route, while a cold route is managed in conventional link-state routing manner with hop-by-hop routing decisions. The shortest path is also selected for a hot route, but it is based on the cost function of Eq. (4). 6.2.2. Dynamic channel assignment Even though the metric used for hot routes penalizes links with the same fixed channel on both sides, consecutive fixed channels in a route cannot be totally avoided. For instance, a route with consecutive fixed channels may be the only available route. By adopting dynamic channel assignment, this problem can be significantly mitigated. To the best of our knowledge, this is the first work of dynamic channel assignment based on traffic pattern in multichannel wireless networks. In our proposed scheme, if a source node of a route detects that the route is hot and has adjacent nodes in the same channel within a route, it forces one of the nodes to change its fixed channel. If a node involved in multiple hot routes receives conflicting orders for channel reassignments from multiple sources, it applies only one of them and dismisses the others. Because these channel flipping enforcements happen only in hot routes. excessive channel flipping can be alleviated. The performance of the dynamic channel assignment scheme with MCLSR was measured by the deployed test bed. The performance of dynamic channel assignment was compared with routing without dynamic channel 4 By considering self-interference, a routing protocol can select less optimized route in terms of cost.
assignment. First, we measured the benefit of dynamic channel assignment from a simple example topology given in Fig. 8a. Flow 1 did not make self-interference by consecutive channels in a route, while flow 2 did. Nodes C and A were assigned the same channel 1 in advance. Without dynamic channel assignment, the self-interference between them could not be resolved. Then we ran flow 1 and 2 in 5 Mbps separately and measured their throughput with and without dynamic channel assignment. The results are given in Fig. 8b. Without dynamic channel assignment, flow 2 had significantly degraded performance due to unavoidable self-interference. Meanwhile, dynamic channel assignment resolved self-interference by assigning node C a new fixed channel. Thus, full performance was achieved. Even though Fig. 8b shows significant improvement when dynamic channel assignment is applied, its use must be carefully considered. If all channels have the same channel characteristics, dynamic channel assignment works fine. However, the conditions of wireless channels on different spectrums vary in reality. Notice that the example of Fig. 8b is a scenario intentionally tuned to show the potential of dynamic channel assignment. In practice, before assigning a channel dynamically, the new channel must be monitored and checked properly in advance. 6.3. Multicast tree for link-state propagations As shown in Fig. 1, inter-cluster-head messages are exchanged between the source of the message and the other cluster-heads through direct unicast. If we use a multicast tree for link-state propagations, control traffic can be further reduced, though this has not been implemented in our MCLSR implementation yet. The idea is as follows:
6 throughput (Mbps)
338
4 2 0
With dyn. chan. Without dyn. chan. 1
2 flow
Fig. 8. Dynamic channel assignment experiment; in the topology diagram, the number on the right-bottom corner of each node indicates the fixed channel. 5 Mbps UDP traffic was flown through the path 1 and 2, separately in time.
C. Kim et al. / Computer Networks 54 (2010) 330–340
Fig. 9. Link-state propagation via a multicast tree; shaded large circle represents cluster-heads. The node lists in boxes are cluster-head lists delivered with inter-cluster-head message.
Fig. 9 shows an example of multicast-tree propagation. The large shaded circles represent the cluster-heads. Suppose that all cluster-heads are already discovered. The node lists in boxes are cluster-head lists delivered with inter-cluster-head messages. Notice that node A delivers its cluster link-state with a cluster-head list of fA; Bg even though A knows the existence of all the cluster-heads. This shortened cluster-head list is intentional to force node B to deliver the cluster link-state to nodes C; D, E; F and G. Because these nodes are missed in the message, node B forwards the link-state to these nodes according to Algorithm 2. When B forwards the message to C, it also misses node D in the cluster-head list, in order to make node C forward the message to node D. The same thing happens on node E. Once an originator builds a multicast tree, it transmits the inter-cluster-head message only to child nodes of the tree. At this time, all descedents of each child are missed in the cluster-head list in the message. Then, by Algorithm 2, the child node has to be in charge of forwarding the message to all of its descedents. The multicast tree trick is recursively applied for the child, too.
339
[2] P. Kyasanur, N.H. Vaidya, Routing and link-layer protocols for multichannel multi-interface ad hoc wireless networks, SIGMOBILE MC2R 10 (1) (2006). [3] R. Draves, J. Padhye, B. Zill, Routing in multi-radio, multi-hop wireless mesh networks, in: Proceedings of ACM MobiCom, 2004, pp. 114–128. [4] Y. Yang, J. Wang, R. Kravets, Designing routing metrics for mesh networks, in: Proceedings of IEEE WiMesh, 2005. ˜ hlethaler, T. Clausen, A. Laouiti, A. Qayyum, L. [5] P. Jacquet, P. Mu Viennot, Optimized link state routing protocol for ad hoc networks, in: Proceedings of IEEE INMIC, 2001, pp. 62–68. [6] P.A. Spagnolo, T.R. Handerson, Comparison of proposed OSPF MANET extensions, in: Proceedings of MILCOM, 2006, pp. 1–7. [7] R. Sivakumar, P. Sinha, V. Bharghavan, CEDAR: a core-extraction distributed ad hoc routing algorithm, IEEE Journal On Selected Areas in Communications 17 (8) (1999) 1454–1465. [8] C. Chereddi, P. Kyasanur, N.H. Vaidya, Net-x: a multichannel multiinterface wireless mesh implementation, in: Proceedings of ACM REALMAN, 2006. [9] A. Raniwala, K. Gopalan, T.-C. Chiueh, Centralized channel allocation and routing algorithms for multi-channel wireless mesh networks, ACM SIGMOBILE MC2R (2004) 50–65. [10] A. Subramanian, H. Gupta, S. Das, Minimum interference channel assignment in multiradio wireless mesh networks, IEEE Transactions on Mobile Computing 7 (12) (2008) 1233–1536. [11] A. Das, R. Vijayakumar, S. Roy, Static channel assignment in multi-radio multi-channel 802.11 wireless mesh networks: issues, metrics and algorithms, in: Proceedings of IEEE GLOBECOM, 2006, pp. 1–6. [12] A. Raniwala, T.-C. Chiueh, Architecture and algorithms for an IEEE 802.11-based multi-channel wireless mesh network, in: Proceedings of IEEE INFOCOM, 2005, pp. 2223–2234. [13] B.-J. Ko, V. Misra, J. Padhye, D. Rubenstein, Distributed channel assignment in multi-radio 802.11 mesh networks, in: Proceedings of IEEE WCNC, 2007, pp. 3978–3983. [14] C. Chereddi, System architecture for multichannel multi-interface wireless networks, Master’s thesis, University of Illinois, 2006.
Cheolgi Kim received a B.S. (1996) degree in computer science, followed by M.S. (1998) and Ph.D. degrees (2005) in Dept. of Computer Science at Korea Advanced Institute of Science and Technology (KAIST). He has been working as a postdoctoral research associate at University of Illinois since September 2006. His research interests include safety-critical systems, cyber-physical systems, formal method applying for system integration, wireless mesh networks and mission-critical wireless networks.
7. Conclusion Due to the dynamics involved in a MANET, reactive routing schemes are usually preferred for multi-hop routing protocols. However, multichannel mesh networks have highly distinguished properties from MANET. Due to their relatively stable nature, static routing protocols are to be preferred in mesh networks. In this paper, we propose the Multi-Channel Link-State Routing (MCLSR) protocol tailored for multichannel mesh networks. We use the concept of cluster-heads to minimize the broadcast overhead in multichannel networks. The protocol was implemented on a IEEE 802.11a based multichannel test bed. The performance results show that MCLSR provides transient route discovery time and lower packet drop rate. Additionally, some improvements to MCLSR are discussed. References [1] P. Gupta, P.R. Kumar, The capacity of wireless networks, IEEE Transactions on Information Theory 46 (2) (2000).
Young-Bae Ko is an Associate Professor in School of Information and Computer Engineering at Ajou University, Korea, leading the Ubiquitous Networked Systems (UbiNeS) Lab. He was also a visiting professor of Coordinated Science Lab in University of Illinois at Urbana Champaign (UIUC) for the 2008–2009 academic year. Prior to joining Ajou University, Dr. Ko was with IBM T.J. Watson Research Center (New York) as a research staff member in the department of Ubiquitous Networking and Security. He received his Ph.D. degree in computer science from Texas A&M University, USA, and B.S and M.B.A from Ajou University, Korea. His research interests are in the areas of mobile computing and wireless networking. In particular, Dr. Ko is actively working on mobile ad hoc networks, wireless mesh networks, ubiquitous sensor networks, and tactical networks. Also, he is an expert on various wireless access technologies like WLAN, WPAN, and WMAN. He is one of the BEST PAPER award recipients from the ACM MobiCom (in 1998). He has served on the program committees of several conferences and workshops such as IEEE Infocom, SECON and ICC. See http:// www.uns.ajou for further details.
340
C. Kim et al. / Computer Networks 54 (2010) 330–340
Nitin Vaidya received the Ph.D. from the University of Massachusetts at Amherst. He is a Professor of Electrical and Computer Engineering at the University of Illinois at Urbana-Champaign (UIUC). He previously served as the Director of the Illinois Center for Wireless Systems at UIUC. He has held visiting positions at the Indian Institute of Technology-Bombay, Microsoft Research, and Sun Microsystems, as well as a faculty position at the Texas A&M University. He co-authored papers that received awards at the 1998 ACM MobiCom, 2007 ACM MobiHoc, and 2003 Personal Wireless Communications (PWC) conferences. Nitin Vaidya is a recipient of a CAREER award
from the US National Science Foundation. He has served as Editor-inChief for the IEEE Transactions on Mobile Computing, Editor-in-Chief for ACM SIGMOBILE publication MC2R, program co-chair for 2003 ACM MobiCom, and General Chair for 2001 ACM MobiHoc. For more information, please visit http://www.users.crhc.illinois.edu/nhv/.
Contents lists available at ScienceDirect
Computer Networks journal homepage: www.elsevier.com/locate/comnet
Link-state routing without broadcast storming for multichannel mesh networks q,qq Cheolgi Kim *, Young-Bae Ko, Nitin H. Vaidya Coordinated Science Laboratory, University of Illinois, 1308 W Main St., Urbana, IL 61801, United States
a r t i c l e
i n f o
Article history: Available online 16 September 2009 Keywords: Wireless mesh networks Link-state routing Multichannel wireless networks
a b s t r a c t A link-state routing protocol tailored for multichannel mesh networks is proposed. One drawback of using multichannel communications is the high overhead involved in broadcast operations: a transmitter should transmit a broadcast packet to all channels that may be occupied by receivers. This makes certain broadcast-intensive mechanisms, such as link-state routing, difficult to implement. The link-state routing protocol proposed in this paper is tailored for multichannel mesh networks by minimizing the broadcast overheads. This is achieved by a special set of nodes, called cluster-heads. We have implemented our protocol on a multichannel mesh network test bed and compared its performance with an AODV-like reactive routing protocol, also tailored for multichannel mesh networks. The measurements show that the proposed link-state routing protocol provides transient communications with comparable or better performance. Ways to improve the performance of the proposed routing with infrastructure access is also discussed. Ó 2009 Elsevier B.V. All rights reserved.
1. Introduction Wireless networks have been successful in both commercial and residential deployments. While last-mile, single-hop wireless networks, such as wireless local area networks and cellular networks, have achieved significant popularity, mobile ad-hoc (MANET) and multihop networks have gained little practical attention despite significant academic contributions in the area. This is due mainly to two reasons: (1) purely ad-hoc networks without connectivity to the Internet do not have much practical application and (2) data in an ad-hoc network may have to be routed through vulnerable intermediate nodes, making it less attractive for commercial deployments. Wireless mesh networks overcome these difficulties by allowing
q A preliminary version of this paper was presented in IEEE MILCOM 2008. qq The work in this paper was funded by The Boeing Company. * Corresponding author. Tel.: +1 217 636 4177. E-mail addresses: [email protected] (C. Kim), [email protected] (Y.-B. Ko), [email protected] (N.H. Vaidya).
1389-1286/$ - see front matter Ó 2009 Elsevier B.V. All rights reserved. doi:10.1016/j.comnet.2009.09.002
for a gateway node that has connectivity to the Internet. Furthermore, relay nodes (different from client nodes) deployed by the operators provide reliable multihop connections between client nodes and gateway nodes. In their seminal paper [1], Gupta and Kumar derived the capacity bounds of a wireless ad-hoc network and showed that placing additional relay nodes in the network helps to achieve significant capacity gains. Additionally, in [2], Kyasanur and Vaidya have analyzed the capacity bounds of a wireless network when multiple channels are used. Accordingly, though there are no asymptotic capacity benefits with multiple channels (rather than a single channel), in practical networks they have several advantages. This is because multichannel networks encourage more transmissions in the network, as the amount of contention per channel is significantly reduced. Much of the existing literature on multichannel networks proposes use of multiple interfaces (or wireless radios) to provide simpler multichannel operation [2–4]. The main challenges in a multichannel wireless network lie in developing protocols for exploiting the flexibility offered by using all the channels available for operation.
C. Kim et al. / Computer Networks 54 (2010) 330–340
Due to the difficulties involved in coordinating the nodes in a multichannel network, each of which may operate on a different channel, traditional protocols designed for single-channel networks may not directly apply in a multichannel setting. In this paper, we discuss a link-state routing mechanism, called MCLSR (Multi-Channel Link-State Routing), tailored for a multichannel mesh network. Link-state routing has been a popular routing methodology in wired networks. In this approach, each node maintains the link-state information of the entire network and makes route decisions based on this information. To keep link-states fresh, each node periodically announces its link-state to all the other nodes. Although link-state routing has relatively high control overheads due to the associated link-state information exchange, it provides quicker route discoveries without additional route discovery packets. Moreover, because the routes are constructed using a global knowledge of the network, they are highly optimized. While link-state routing has been less popular in MANETs because of the associated topology dynamics caused by node mobility,1 it has recently been reconsidered for mesh networks due to their relatively stable topology compared to MANETs. Moreover, the optimized routing achievable using a link-state routing protocol is more attractive for a multichannel environment, as routing decisions can be based not just on the channel quality of each link but also on the sequence of the channels to be used in a route. This can significantly affect end-to-end throughput [3]. Most of the existing designs of wireless link-state routing protocols exploit the broadcast nature of the wireless medium for propagating the link-state information [5]. However, since the broadcast overheads in a multichannel network are much higher than in a single-channel environment, the existing implementations of the link-state routing protocols are best not directly applied to multichannel networks. Notice that in a multichannel network, a transmitter should transmit a broadcast packet on all channels that might be occupied by a receiver, thereby increasing the overhead involved. To minimize broadcast overheads, we propose a set of cluster-head nodes, elected dynamically for exchanging the link-state information over the network. The cluster-head nodes collect the link-state information from their dependent nodes and share it with other cluster-heads. The receiving cluster-heads rebroadcast the shared link-state information to their dependents to propagate the link-states over the entire network. We discuss the procedure involved in more detail in Section 4. We have implemented our protocol on a real multichannel mesh network test bed with two IEEE 802.11a interfaces per node. We discuss the implementation issues and the experimental results in Section 5. Our results show that the link-state routing mechanism provides transient communication with comparable or better performance. The mechanisms for improving the performance of the proposed routing approach using infrastructure access are discussed in Section 6. Section 7 concludes the paper.
1 When the topology changes dynamically, the link-states have to be frequently distributed, which may cause intensive control overheads.
331
2. Related work Since the concept of a mobile ad-hoc network (MANET) emerged, several variants of the original link-state routing protocol tailored for the networks have been proposed. Jacquet et al. proposed the Optimized Link State Routing Protocol (OLSR) [5]. In this protocol, each node selects a set of multipoint relay nodes, and link-state broadcast is performed only by this selected set of nodes. This, in turn, reduces the nunber of broadcast messages in the network. Furthermore, the link-states of only a subset of links are globally managed. OSPF-MANET (Open Shortest Path First for MANET) is a link-state routing protocol proposed by the IETF OSPF working group [6]. OSPF-MANET extends OSPF, which is widely used in wired networks, to wireless networks. It also allows only subset of nodes for broadcast flooding. When a subset of link-states is propagated, control overhead is reduced. Meanwhile, discovered routes are likely to be suboptimal. In multichannel mesh networks, end-to-end throughput can be significantly degraded by selecting a suboptimal sequence of channels in a route. Sivakumar et al. proposed CEDAR (Core-Extraction Distributed Ad Hoc Routing) [7], a link-state routing mechanism designed for real-time applications. In CEDAR, Selected core nodes perform unicasts between them to propagate link-states, as in our approach. However, its design does not reflect the multichannel characteristic of wireless networks. Draves et al. proposed WCETT (Weighted Cumulative Expected Transmission Time) as a multichannel, multi-interface routing metric and a linkstate routing protocol, LQSR (Link-Quality Source Routing) [3]. LQSR is a source-routed, link-state protocol derived from DSR. The routing protocol was implemented on a test bed and the performance between routing metrics was compated. Kyasanur and Vaidya proposed a multi-radio wireless network architecture, Net-X, and a routing metric [2]. They also proposed a reactive routing protocol, and implemented them on a test bed [8]. The Net-X architecture is used as an implementation base in this paper. Intelligent channel allocation is often viewed as a way to improve the performance of a multichannel wireless network. Most channel allocation algorithms proposed in the literature can be classified into two categories: centralized and distributed. Centralized approaches are designed to globally optimize potential interferences regarding the full topology of networks [9–12]. Distributed approaches locally optimize the channel distribution in heuristics [2,13]. To the best of our knowledge, no approach has been proposed to assign channels dynamically with regard to traffic patterns and routes, which we address in Section 6.
3. Network model A wireless mesh network consists of two kinds of nodes: mesh nodes and client nodes. The mesh nodes form a backbone network, which provides network connectivity to the client nodes. Every client node associates itself with a mesh node, which performs packet forwarding through the rest of the backbone network. A wireless routing protocol, such
332
C. Kim et al. / Computer Networks 54 (2010) 330–340
as the one discussed in this paper, is used for forwarding packets within the backbone network. The multichannel mesh network considered in this paper is based on the Net-X architecture [8]. Before proceeding further, we first provide a brief overview of the Net-X architecture. 3.1. Net-X Overview The multichannel mesh network consists of a set of wireless nodes, each of which is equipped with two wireless interfaces. One of the two interfaces remains fixed on a channel; this is called the ‘fixed’ interface. The other interface is capable of switching across channels whenever required and hence is called the ‘switchable’ interface. We call the channel in which the fixed interface of a node operates the ‘fixed channel’ of that node. Only the fixed interface is used for receiving data. The fixed interface can also be used for transmitting data on the fixed channel. Transmissions on the other channels are handled by the switchable interface. Packet transmission between two nodes on two different fixed channels is handled by switching the channel on the switchable interface of the transmit node to the fixed channel of the receive node. For instance, suppose a node u has a packet for a node, v that is on a different fixed channel. The switchable interface of u is tuned (switched) to the fixed channel of v, and the packet is transmitted on that channel. If both nodes u and v were on the same fixed channel, then node u’s fixed interface would be used for the transmission (no channel switch is required). If a node has a broadcast packet, it sends the packet on all the channels, as every single channel may be in use by a neighbor. For this purpose, the switchable interface performs round-robin channelswitching through all channels except the fixed channel. Observe that every node has to be assigned a fixed channel for packet receptions. Furthermore, every node must be aware of the fixed channels assigned to its neighbors in order to communicate with them. Due to the Net-X architecture of the backbone network, each fully capable client node is supposed to have dual interfaces as well. Let G ¼ ðV; EÞ denote the backbone network, where V is the set of dual interface nodes in the network and E is the set of links between the nodes. A link ðu; vÞ 2 E exists between two nodes u; v 2 V if they are within communication range of each other. Let C denote the set of channels to be assigned to the nodes and ~ qðu; vÞ represent the unidirectional link quality of a link ðu; vÞ 2 E. The bidirectional link quality qðu; vÞ is defined by a function of the pair of qðu; vÞ; unidirectional link qualities such that qðu; vÞ ¼ gð~ ~ qðv; uÞÞ. In our implementations it is simply defined as:
qðu; vÞ ¼ gð~ qðu; vÞ; ~ qðv; uÞÞ ¼ ~ qðu; vÞ ~ qðv; uÞ: A subset of nodes in V are destined to be the ‘clusterhead’ nodes, and we denote this subset as V C . We will explain more about the cluster-head nodes later. Additionally, we assume that every node in the network has two types of neighbor sets, namely tight neighbors ðN t Þ and loose neighbors ðN l Þ, depending on the quality of the link with the neighboring nodes. In general, every node maintains two common link threshold values, Thl and Tht , such that Thl < Tht . N l and N t are defined by Thl and Tht such that
Nl ðv 2 VÞ ¼ fuju 2 Vandqðu; vÞ > Thl g Nt ðv 2 VÞ ¼ fuju 2 Vandqðu; vÞ > Tht g: Note that N t N l because Thl < Tht should be satisfied. Due to transient link conditions, N l ðvÞ and N t ðvÞ change over time. These sets are used in cluster-head selection (see Section 4). 4. Multi-Channel Link-State Routing protocol MCLSR is a modified link-state routing protocol for multichannel mesh networks tailored to minimize broadcast overhead due to link-state propagation. For immediate response of a network to end users, all nodes keep the link.state information of a network. In typical implementations of wireless link-state routing mechanisms, such as OLSR and OSPF-MANET, this is achieved using broadcast flooding. In our network model, the overhead of broadcast is jCj times larger than in a single-channel network, where jCj is the number of channels used in the network. Minimizing the broadcast overhead, therefore, is one of the primary goals of our protocol. In MCLSR, nodes are classified into two disjoint categories: cluster-heads and dependents. Once a node is chosen as a cluster-head, some of the other nodes that are within one hop of this node become its dependents. Each dependent can have multiple neighboring cluster-heads. but one and only one of them is identified as its master cluster-head. A cluster-head cannot have another cluster-head as its tight neighbor (N t ), as a rule.2 A cluster-head along with its dependents form a cluster. A cluster-head is responsible for gathering and distributing the link-state information to its dependents. Fig. 1a shows an example of a network using MCLSR. Shaded nodes are cluster-heads, and non-shaded nodes are dependent nodes. A cluster-head and its dependents are connected by solid lines, and the other neighboring pairs of nodes are connected by dotted lines. Each dependent node is in only one cluster. The cluster has only one cluster-head node, which is master cluster-head of the cluster. Any other neighboring cluster-head node is considered to be a generic neighbor to a dependent node. Sometimes, a cluster may contain only one node (a cluster-head), such as node K in the figure. Fig. 1b shows how the link-states are propagated from a cluster node to the entire network. Link states of the cluster members are delivered to cluster-head C through ‘hello messages.’ Cluster-head C constructs a ‘cluster link-state’ that contains all the link-states of its cluster members. The link-state of an individual node is called the ‘node link-state’. Each cluster-head periodically distributes the cluster link-states to other cluster-heads through intercluster-head unicasts, which is presented by dashed arrows in Fig. 1b. The delivered cluster link-state is broadcast to its own cluster members. Hello messages and inter-cluster-head messages are the only control messages in MCLSR. The message formats of 2 If a pair of cluster-heads indicate that they are tight neighbors of each other, one of them will lose the privilege of being a cluster-head according to the protocol.
C. Kim et al. / Computer Networks 54 (2010) 330–340
333
contains the link qualities. Node information consists of a sequence number, which is incremented for every hello message, a cluster-head indicator (CI) bit, which indicates whether this node is a cluster-head, and the fixed channel used by the fixed interface. The CI bit in the link information helps in cluster-head discoveries. The link information, on the other hand, contains the directional link quality, which is measured from incoming hello messages. Notice that the total link quality, which is used by the routing protocol as a metric, is a function of a pair of directional link qualities (outgoing and incoming). Because each node can only measure the link quality in the incoming direction, the link quality field of a node link-state contains that directional link quality, which is ~ qðu; vÞ, where u is the outgoing node and v is the incoming node. The other directional link quality is collected from the node link-state of the node at the opposite side of the link. Then, the total link quality is calculated from the pair of directional link qualities. In our protocol implementation, directional link quality is the proportion of successful hello message deliveries. The total link quality of a link is given by ð~ qðu; vÞ ~ qðv; uÞÞ. 4.3. Cluster link-state
Fig. 1. Example topology of MCLSR.
the hello messages and the inter-cluster-head messages are discussed in the next section. 4.1. Node link-state and cluster link-state Node link-state and cluster link-state are the internal control information units distributed by control messages, such as hello messages and inter-cluster-head unicast messages. Fig. 2 depicts their internal structure.
Cluster link-state message consists of the link-states of all the cluster members. It is formed by concatenating the link-state structure of each of the cluster members as shown in Fig. 2. 4.4. Control messages 4.4.1. Hello message The purpose of the hello message in MCLSR is as follows: 1. Distribution of up-to-date node link-states 2. Periodic link quality measurement on the receiver side, and 3. Distribution of cluster link-states from a master-cluster-head to its dependents.
4.2. Node link-state The node link-state is the basic data structure in both the hello message and the inter-cluster-head message. A node link-state consists of node information that contains the state of the node, and a set of link information that
Fig. 2. Link-state information structure.
A dependent node periodically transmits a hello message containing its node link-state. Every dependent node, upon receiving a hello message sent by another node in the neighborhood, updates its link-state database. Additionally, it measures the directional quality of the link, ~ qðu; vÞ, where v is the receiving node, from each of its neighbors, u, based on the received hello messages. For measurement accuracy, the size of hello message is fixed to 1024 bytes. Hello messages are zero padded, if required, to satisfy this fixed size criterion. Fig. 3a describes the structure of a hello message sent by a dependent node. As seen in the figure, a dependent node prepares a hello message by attaching the address of its master cluster-head to the node link-state information. The acknowledged master cluster-head includes the received node link-state to its cluster link-state. A cluster-head node sends a hello message to its cluster members to update them with the link-state information of other clusters in the network. Every cluster-head that has received one or more cluster link-state unicast messages
334
C. Kim et al. / Computer Networks 54 (2010) 330–340
tions, Eq. (1) ensures that every node is within a one-hop neighborhood of a cluster-head, and Eq. (2) minimizes the density of cluster-heads by ensuring that no two cluster-heads are tight neighbors of each other. In fact, to manage N l and N t separately seems to just make the protocol complicated. These two set of neighbors can be defined to be identical and can be called just ‘neighbors,’ which makes the protocol much simpler and easier to understand. However, we distinguish N l and N t to reduce control overhead caused by frequent cluster-head re-selection. Semantically, Eq. (1) is the condition to promote a cluster-head, and Eq. (2) is the condition to demote a cluster-head. N l ðvÞ in Eq. (1) makes promotion harder. But once a node is promoted to cluster-head, it will not be easily demoted because the demotion is based on N t ðvÞ. This prevents frequent change of network configuration, which can make the network unstable. Fig. 3. Control message structures.
from other cluster-heads broadcasts them to its dependents through the hello message along with its own node link-state information. The message format of the hello message sent by a cluster-head node is shown in Fig. 3a. As we mentioned earlier, cluster link-state is periodically propagated over the network. It is supposed to be less frequent than a hello message. In MCLSR, the rate of hello message is t c times the rate of cluster link-state propagation. Thus, tc hello messages are sent by the time a cluster link-state is issued by a cluster-head. An extended hello message is also issued for every t c hello messages. The structure of extended hello message is also shown in Fig. 3a. In an extended hello message, there is an additional field called the cluster-head list, where the master-clusterhead includes a list of known cluster-heads. This helps cluster-head discovery, as explained later.
Algorithm 1. Decision to be a cluster-head for node v Require Collected link-state information Ensure Decision to be a cluster-head 1: if v 2 V C then 3: NðvÞ ( N t ðvÞ 4: else 5: NðvÞ ( N l ðvÞ 6: end if 7: if NðvÞ \ V C ¼ £ then 8: return TRUE 9: else 10: if 8u 2 NðvÞ \ V C ; idðvÞ > idðuÞ then 11: return TRUE 11: else 12: return FALSE 13: end if 14: end if
4.5. Inter-cluster-head unicast message For every t c hello messages, an inter-cluster-head unicast message is sent to other cluster-head nodes indicating the cluster link-state. The structure of this message is described in Fig. 3b. It consists of the cluster link.state along with the list of known cluster-heads, like an extended hello message. Optionally, a dependent node also can send out an inter-cluster-head message to another cluster-head for cluster-head discovery. In this case, the dependent nodes slice a inter-cluster-head message out of the extended hello message received from its master-cluster-head. The details are described in Section 4.7. 4.6. Cluster-head selection procedure The cluster-head selection is performed based on the following rule:
8v 2 V; 9n 2 V C ; such that n 2 Nl ðvÞ 8m; n 2 V C ; m R Nt ðnÞ
Algorithm 1 describes the cluster-head selection procedure. It is run by each node independently, just before the hello message is issued. Here, idðvÞ is the unique identifier of a node v, which can be the node’s IP address (used in our implementation). How to assign a unique id (or IP address) is beyond the scope of this paper, but a recommended id assignment policy is discussed in Section 6. According to Algorithm 1, each node checks whether there is clusterhead in its neighborhood (Eq. (1)). If not, the node itself becomes a cluster-head and generates a unique cluster-head id. If a cluster-head is a tight neighbor of another clusterhead, then the cluster-head with the smaller id is demoted to dependent (according to Eq. (2)). By performing these decisions, no node is left without a cluster-head, and no pair of cluster-heads become tight neighbors in the steady state. Additionally, if a node sees multiple cluster-heads in its neighborhood, then it chooses the one to which link quality is the strongest as its master-cluster-head.
ð1Þ ð2Þ
where N l and N t denote the loose and tight neighbors of a node, respectively (see Section 3). Among the two equa-
4.7. Cluster-head discovery Once a cluster-head is elected, it has to discover the other cluster-heads in the network for propagating the
C. Kim et al. / Computer Networks 54 (2010) 330–340
cluster link-state information via unicast messages. Notice that a cluster link-state is delivered to designated nodes, which are the cluster-head’s dependents (via hello message) and other cluster-heads (via inter-cluster-head message), whichever the master-cluster-head is aware of. If a designated node knows more cluster-heads than the master-cluster-head, it forwards the cluster link-state to those cluster-heads. As a result, a cluster link-state is propagated farther than expected. This may result in discovery of an unknown cluster-head receiving the forwarded link.states. In this section, we explain how cluster link-state is forwarded farther. We call such a cluster link-state ‘cluster-head discovery’, as it aides in the discovery of a new cluster-head. Cluster-head discovery is performed in two phases: (1) neighbor-cluster-head discovery and (2) non-neighbor-cluster-head discovery. The following lemma supports the discovery algorithm. Suppose that the network does not change its topology while the discovery algorithm is running (the network is in a steady state). In accordance with the lemma, every cluster-head must discover all the other cluster-heads by the algorithm as long as the network is connected. Notice that the notion that ‘The network is connected’ means that the network is not partitioned; in other words, a path between any pair of nodes is available. 4.7.1. Neighbor-cluster-head discovery Lemma 1. If a graph GC ¼ ðV C ; EC Þ is the graph that connects every pair of cluster-heads in three-hops, the following is satisfied: GC is a connected graph if and only if G is a connected graph. If GC is connected then G is connected for sure because cluster-heads are all connected and their dependents are connected to cluster-heads. Suppose that G is connected but GC is not connected as a contradiction. It means that GC is partitioned. Suppose that GC has two disconnected groups of cluster-heads, then they are at least four hop distant. Then, there should be a node which is not a cluster-head and at least two-hop distant from any cluster-head. Then, that node cannot have a neighbor-cluster-head, but should be a dependent. It is against the protocol. Lemma is proven. From Lemma 1, we have that a network is connected if cluster-heads are connected in GC . A pair of cluster-heads, u and v, are called neighbor-cluster-heads when ðu; vÞ 2 EC . If they are at one-hop of each other, the discovery is trivial, as the nodes come to know each other through their respective hello messages. If they are at a two-hop distance, then there exists a node w, such that w 2 N l ðuÞ and w 2 N l ðvÞ. Thus, the nodes u and v can listen to w’s hello
Fig. 4. Three-hop cluster-head discovery.
335
message, which contains the link-states of ðw; uÞ and ðw; vÞ. As shown in Fig. 2, the link information of this hello message contains a ‘cluster-head indicator’ that indicates whether the node on the other side of a link is a clusterhead. Thus, nodes u and v can learn about each other through w’s hello message. Discovering a three-hop cluster-head is a little tricky. Fig. 4 shows an example of a three-hop cluster-head discovery. According to this figure, nodes u and v are cluster-heads, and nodes w and x are dependent nodes that lie between u and v. Let us assume that the cluster-heads u and v do not know about each other to start with. As mentioned before, node u periodically sends out an extended hello message containing cluster link-state information and the list of known cluster-heads to all it dependents. Incidentally, node w becomes aware of the presence of node v within its two-hop neighborhood through hello messages sent by node x. Thus, upon receiving the extended hello message from u, node w compares the list of cluster-heads (contained in the extended hello message) with the list of cluster-heads known to it through hello messages. If there is a mismatch between these two lists (which will be the case here, as the list sent by u will not contain v), the node w prepares an inter-cluster-head message from the extended hello message by retaining the self cluster link-state information and the cluster-head list fields (and chopping off the rest of the fields). It sends this message to the cluster-heads that are missing in the list sent by u. Thus, node w will send the inter-cluster-head message to node v. This way, node v can discover that u is a cluster-head (from the self cluster link-state information). Similarly, node u can learn about node v through an inter-cluster-head message from node x or through a subsequent inter-cluster-head message from node v. Because neighbor cluster-heads are cluster-heads in three-hops, all neighbor cluster-heads discover each other.
4.7.2. Non-neighbor-cluster-head discovery The procedure for non-neighbor-cluster-head discovery is performed similarly to that of neighbor-cluster-head discovery. Once a cluster-head receives an inter-cluster-head unicast message, it parses the cluster-head list to look for any known cluster-heads that are not contained in the received list. If it finds any, it forwards the received inter-cluster-head message to the missing cluster-heads immediately. The missing cluster-heads in turn can learn about the original cluster-head that sent the intercluster-head message. The procedure for forwarding the inter-cluster-head message to the missing cluster-heads is discussed in Algorithm 2. Once each undiscovered pair of cluster-heads exchange their cluster link-states, they will be aware of each other; discovery is done. By neighbor-cluster-head discovery, all neighbor-cluster-heads are discovered. By non-neighbor-cluster-head discovery, link-states are forwarded to unknown clusterheads, which results in cluster-head discovery for the receiver of the forwarded link-state. As a result, in a connected network, all cluster-heads are discovered through the link-state forwarding procedure by Lemma 1.
336
C. Kim et al. / Computer Networks 54 (2010) 330–340
1
Algorithm 2. Basic link-state propagation to undiscovered cluster-heads Ensure Decision to be a cluster-head Require Inter-cluster-head message M is arrived. h i ðmsgÞ 1: M :¼ L; V C 2: L: delivered cluster link-state ðmsgÞ
3: V C 4: 5:
: Cluster-head list in inter-coord. msg.
ðrxÞ V C : known cluster-heads of the receiver ðuncoveredÞ ðmsgÞ ðrxÞ ðuncoveredÞ VC ( VC n V C 6: if V C –
£
then 7:
h i ðrxÞ ðuncoveredÞ M new ( L; V C [ V C ðuncoveredÞ
8: send M new to the nodes 2 V C 9: end if
by unicast
CDF
0.8 0.6 0.4 MCLSR Reactive
0.2 0 0
1000
2000 3000 4000 initial round trip time (ms)
5000
Fig. 6. CDF of packet turnaround time to measure route discovery time for MCLSR and reactive routing.
set and are controlled by the Madwifi driver. The wireless drivers are modified to obtain shorter channel-switching time. More details on the software architecture can be found in [14].
5. MCLSR implementation
5.2. Performance measurements
5.1. Test bed platform
5.2.1. Route discovery time Time required for a route discovery is an important metric in wireless mesh networks for transient response to end users. We have measured route discovery time of MCLSR and the reactive protocol. To measure route discovery time, fifteen Soekris boxes were deployed on the fourth floor of Coordinated Science Laboratory building of the University of Illinois. Each box had two Atheros 802.11a interfaces as the fixed and switchable interfaces. Fig. 5 depicts our monitoring program, which displays 15 running nodes in the building. In the measurements, node 6 in Fig. 5, located at the top-right corner, played the role of gateway node, making
We implemented our MCLSR protocol over the IEEE 802.11a MAC protocol. IEEE 802.11a proposes 12 orthogonal channels in the 5 GHz band. In practice, however, only five to six channels can be concurrently used with off-theshelf devices due to adjacent channel interference, as shown by measurements [14]. The protocol is implemented on the Linux 2.4.26 kernel. The main MCLSR protocol runs as a service daemon, and system-oriented parts, such as network packet hooks and radio interface bonding (for multi-radio operation), are implemented as kernel modules. The wireless cards are based on the Atheros chip-
Fig. 5. Node deployment for experiments.
337
C. Kim et al. / Computer Networks 54 (2010) 330–340
1.2 Per-flow goodput (Mbps)
down-link routes to all the other nodes. By measuring packet turnaround times from the gateway to each destination node, one by one, we captured the cumulative distribution function of route discovery time3 in Fig. 6. The result presented in the figure is obvious. MCLSR has much shorter route discovery time than reactive routing. Because reactive routing has to discover a route using broadcast flooding, it requires a certain amount of delay for the destination node to gather enough information for a route with performance. However, MCLSR is ready for transmitting a packet to any destination beforehand.
1 0.8 0.6 0.4
MCLSR: 0.8Mbps Reactive: 0.8Mbps MCLSR: 1.6Mbps Reactive: 1.6Mbps
0.2 0
5.2.2. Goodput comparison We also measured average end-to-end goodput in a random communication scenario. At this time, 23 nodes were deployed in a building, eight more than the previous experiment in a configuration similar to Fig. 5. Three communication channels were selected and used for the measurement. In this experiment, every node initiated UDP traffic at a random time to a random destination to realize a random communication scenario for average end-to-end goodput measurements. The details of the experiment are as follows: Before the start of experiment, every node randomly chose a communication starting time between 0 and 90 s. Additionally, the nodes randomly selected a target node uniformly among all the other nodes. Traffic was generated from the chosen starting time to the selected target. Traffic from a source node was sustained only for a given duration, called communication duration. Communication duration was set constant within a run but varied, run by run, from 2 to 10 s. The data rate per flow also varied, run by run, either 0.8 or 1.6 Mbps in our experiment. UDP packet size was 1024 bytes. Every experiment used the same trace of a packet-generation pattern to make the comparison fair. The experiment ran with either reactive routing or MCLSR. The goodput was measured as follows: The target node sent an acknowledgment packet for the last 20 packets of the traffic; this packet contained the amount of the delivered data. The source node was able to capture some of the acknowledgments, and the last received acknowledgment was used to calculate the goodput. The goodput was given by the delivered data from the acknowledgment packet divided by the time from the first packet transmission to the last acknowledgment reception. Fig. 7 shows average per-route goodput with respect to communication duration. For each combination of measurements, five runs were performed, and the performance was averaged. Results showed that when communication duration is tuned to be short, MCLSR performs better with obvious margin because of the route discovery overhead in reactive routing. As communication duration gets longer, the performance gap between MCLSR and the reactive routing closes. Notice that many Internet applications are timesensitive and bursty. The result shows that link-state routing such as MCLSR is more suitable for wireless mesh networks. 3 Strictly speaking, it includes route discovery time plus packet turnaround delivery time.
0
2 4 6 8 Communication duation per flow (s)
10
Fig. 7. Average per-route goodput for MCLSR and reactive routing with respect to communication duration per flow.
6. Discussions 6.1. Role assignment strategy in MCLSR with infrastructure access For network stability and performance, it is important to assign the role of cluster-head or dependent appropriately. ‘Mesh nodes are obviously preferable to client nodes to serve as cluster-heads because of their stability; client nodes can move or disappear at any time. However, gateway nodes are not recommended as cluster-heads, even though they are also a sort of mesh node. Cluster-heads are expected to have higher control overheads than dependent nodes. If a gateway node is selected as a cluster-head, it will be overloaded by control packets as well as data packets. 6.2. Routing metrics and dynamic channel assignment in MCLSR MCLSR can be used with any multichannel routing metric. In our implementations, we use two routing metrics, case-by-case, in terms of traffic load per route. This dual routing metric approach was tailored to be used with a dynamic channel assignment scheme. The detail of dual metrics and dynamic channel assignment is described in the following paragraphs. 6.2.1. Hot routes and cold routes Suppose that a route is heavily loaded, and packets will be delivered back-to-back. In addition, two adjacent links share the same fixed channel. These two links cannot be active simultaneously because of interference between them. The maximum throughput of the route will be reduced because of this selective activation of the links. This is called self-interference. Due to self-interference, performance is affected not only by the quality of individual links but also by the channel sequence of a route [2,4]. Therefore, the routing metrics for multichannel mesh networks do well to include a self-interference mitigating strategy, as in MCETT [2] and WCETT [3].
C. Kim et al. / Computer Networks 54 (2010) 330–340
If a route is not heavily loaded, packets do not need to be delivered densely. Here a simple routing metric based on link quality may work well and consume fewer network resources than a complex metric when it comes to selfinterference.4 The saved network resources can be used for other routes. Thus, we propose to use different routing strategies for hot routes, which have heavy traffic, and cold routes, which have light traffic. The basic cost cðu; vÞ of a link ðu; vÞ is defined by the inverse of the link quality qðu; vÞ as:
cðu; vÞ ¼
1 : qðu; vÞ
ð3Þ
For a cold route, Eq. (3) defines the cost of each link, and the shortest path is selected for a route. If a route is hot, routing strategy is changed. In our implementation, the route is declared to be hot if there are more than 20 packets transmitted to the route in two seconds at the source node. Once a route becomes hot, the cost function of a link is changed, such that
^cðu; vÞ ¼
cðu; vÞ
iff ðuÞ – f ðvÞ
pcðu; vÞ iff ðuÞ ¼ f ðvÞ
ð4Þ
where f ðvÞ is the fixed channel of node v, and p is the penalty factor. In our implementation, p is set to 1.5. Eq. (4) gives some penalty cost to a link between a pair of nodes with the same fixed channel. For a consistent view of the hotness of a route, source routing is applied for hot routes. The routing table is announced from the source node for a hot route, while a cold route is managed in conventional link-state routing manner with hop-by-hop routing decisions. The shortest path is also selected for a hot route, but it is based on the cost function of Eq. (4). 6.2.2. Dynamic channel assignment Even though the metric used for hot routes penalizes links with the same fixed channel on both sides, consecutive fixed channels in a route cannot be totally avoided. For instance, a route with consecutive fixed channels may be the only available route. By adopting dynamic channel assignment, this problem can be significantly mitigated. To the best of our knowledge, this is the first work of dynamic channel assignment based on traffic pattern in multichannel wireless networks. In our proposed scheme, if a source node of a route detects that the route is hot and has adjacent nodes in the same channel within a route, it forces one of the nodes to change its fixed channel. If a node involved in multiple hot routes receives conflicting orders for channel reassignments from multiple sources, it applies only one of them and dismisses the others. Because these channel flipping enforcements happen only in hot routes. excessive channel flipping can be alleviated. The performance of the dynamic channel assignment scheme with MCLSR was measured by the deployed test bed. The performance of dynamic channel assignment was compared with routing without dynamic channel 4 By considering self-interference, a routing protocol can select less optimized route in terms of cost.
assignment. First, we measured the benefit of dynamic channel assignment from a simple example topology given in Fig. 8a. Flow 1 did not make self-interference by consecutive channels in a route, while flow 2 did. Nodes C and A were assigned the same channel 1 in advance. Without dynamic channel assignment, the self-interference between them could not be resolved. Then we ran flow 1 and 2 in 5 Mbps separately and measured their throughput with and without dynamic channel assignment. The results are given in Fig. 8b. Without dynamic channel assignment, flow 2 had significantly degraded performance due to unavoidable self-interference. Meanwhile, dynamic channel assignment resolved self-interference by assigning node C a new fixed channel. Thus, full performance was achieved. Even though Fig. 8b shows significant improvement when dynamic channel assignment is applied, its use must be carefully considered. If all channels have the same channel characteristics, dynamic channel assignment works fine. However, the conditions of wireless channels on different spectrums vary in reality. Notice that the example of Fig. 8b is a scenario intentionally tuned to show the potential of dynamic channel assignment. In practice, before assigning a channel dynamically, the new channel must be monitored and checked properly in advance. 6.3. Multicast tree for link-state propagations As shown in Fig. 1, inter-cluster-head messages are exchanged between the source of the message and the other cluster-heads through direct unicast. If we use a multicast tree for link-state propagations, control traffic can be further reduced, though this has not been implemented in our MCLSR implementation yet. The idea is as follows:
6 throughput (Mbps)
338
4 2 0
With dyn. chan. Without dyn. chan. 1
2 flow
Fig. 8. Dynamic channel assignment experiment; in the topology diagram, the number on the right-bottom corner of each node indicates the fixed channel. 5 Mbps UDP traffic was flown through the path 1 and 2, separately in time.
C. Kim et al. / Computer Networks 54 (2010) 330–340
Fig. 9. Link-state propagation via a multicast tree; shaded large circle represents cluster-heads. The node lists in boxes are cluster-head lists delivered with inter-cluster-head message.
Fig. 9 shows an example of multicast-tree propagation. The large shaded circles represent the cluster-heads. Suppose that all cluster-heads are already discovered. The node lists in boxes are cluster-head lists delivered with inter-cluster-head messages. Notice that node A delivers its cluster link-state with a cluster-head list of fA; Bg even though A knows the existence of all the cluster-heads. This shortened cluster-head list is intentional to force node B to deliver the cluster link-state to nodes C; D, E; F and G. Because these nodes are missed in the message, node B forwards the link-state to these nodes according to Algorithm 2. When B forwards the message to C, it also misses node D in the cluster-head list, in order to make node C forward the message to node D. The same thing happens on node E. Once an originator builds a multicast tree, it transmits the inter-cluster-head message only to child nodes of the tree. At this time, all descedents of each child are missed in the cluster-head list in the message. Then, by Algorithm 2, the child node has to be in charge of forwarding the message to all of its descedents. The multicast tree trick is recursively applied for the child, too.
339
[2] P. Kyasanur, N.H. Vaidya, Routing and link-layer protocols for multichannel multi-interface ad hoc wireless networks, SIGMOBILE MC2R 10 (1) (2006). [3] R. Draves, J. Padhye, B. Zill, Routing in multi-radio, multi-hop wireless mesh networks, in: Proceedings of ACM MobiCom, 2004, pp. 114–128. [4] Y. Yang, J. Wang, R. Kravets, Designing routing metrics for mesh networks, in: Proceedings of IEEE WiMesh, 2005. ˜ hlethaler, T. Clausen, A. Laouiti, A. Qayyum, L. [5] P. Jacquet, P. Mu Viennot, Optimized link state routing protocol for ad hoc networks, in: Proceedings of IEEE INMIC, 2001, pp. 62–68. [6] P.A. Spagnolo, T.R. Handerson, Comparison of proposed OSPF MANET extensions, in: Proceedings of MILCOM, 2006, pp. 1–7. [7] R. Sivakumar, P. Sinha, V. Bharghavan, CEDAR: a core-extraction distributed ad hoc routing algorithm, IEEE Journal On Selected Areas in Communications 17 (8) (1999) 1454–1465. [8] C. Chereddi, P. Kyasanur, N.H. Vaidya, Net-x: a multichannel multiinterface wireless mesh implementation, in: Proceedings of ACM REALMAN, 2006. [9] A. Raniwala, K. Gopalan, T.-C. Chiueh, Centralized channel allocation and routing algorithms for multi-channel wireless mesh networks, ACM SIGMOBILE MC2R (2004) 50–65. [10] A. Subramanian, H. Gupta, S. Das, Minimum interference channel assignment in multiradio wireless mesh networks, IEEE Transactions on Mobile Computing 7 (12) (2008) 1233–1536. [11] A. Das, R. Vijayakumar, S. Roy, Static channel assignment in multi-radio multi-channel 802.11 wireless mesh networks: issues, metrics and algorithms, in: Proceedings of IEEE GLOBECOM, 2006, pp. 1–6. [12] A. Raniwala, T.-C. Chiueh, Architecture and algorithms for an IEEE 802.11-based multi-channel wireless mesh network, in: Proceedings of IEEE INFOCOM, 2005, pp. 2223–2234. [13] B.-J. Ko, V. Misra, J. Padhye, D. Rubenstein, Distributed channel assignment in multi-radio 802.11 mesh networks, in: Proceedings of IEEE WCNC, 2007, pp. 3978–3983. [14] C. Chereddi, System architecture for multichannel multi-interface wireless networks, Master’s thesis, University of Illinois, 2006.
Cheolgi Kim received a B.S. (1996) degree in computer science, followed by M.S. (1998) and Ph.D. degrees (2005) in Dept. of Computer Science at Korea Advanced Institute of Science and Technology (KAIST). He has been working as a postdoctoral research associate at University of Illinois since September 2006. His research interests include safety-critical systems, cyber-physical systems, formal method applying for system integration, wireless mesh networks and mission-critical wireless networks.
7. Conclusion Due to the dynamics involved in a MANET, reactive routing schemes are usually preferred for multi-hop routing protocols. However, multichannel mesh networks have highly distinguished properties from MANET. Due to their relatively stable nature, static routing protocols are to be preferred in mesh networks. In this paper, we propose the Multi-Channel Link-State Routing (MCLSR) protocol tailored for multichannel mesh networks. We use the concept of cluster-heads to minimize the broadcast overhead in multichannel networks. The protocol was implemented on a IEEE 802.11a based multichannel test bed. The performance results show that MCLSR provides transient route discovery time and lower packet drop rate. Additionally, some improvements to MCLSR are discussed. References [1] P. Gupta, P.R. Kumar, The capacity of wireless networks, IEEE Transactions on Information Theory 46 (2) (2000).
Young-Bae Ko is an Associate Professor in School of Information and Computer Engineering at Ajou University, Korea, leading the Ubiquitous Networked Systems (UbiNeS) Lab. He was also a visiting professor of Coordinated Science Lab in University of Illinois at Urbana Champaign (UIUC) for the 2008–2009 academic year. Prior to joining Ajou University, Dr. Ko was with IBM T.J. Watson Research Center (New York) as a research staff member in the department of Ubiquitous Networking and Security. He received his Ph.D. degree in computer science from Texas A&M University, USA, and B.S and M.B.A from Ajou University, Korea. His research interests are in the areas of mobile computing and wireless networking. In particular, Dr. Ko is actively working on mobile ad hoc networks, wireless mesh networks, ubiquitous sensor networks, and tactical networks. Also, he is an expert on various wireless access technologies like WLAN, WPAN, and WMAN. He is one of the BEST PAPER award recipients from the ACM MobiCom (in 1998). He has served on the program committees of several conferences and workshops such as IEEE Infocom, SECON and ICC. See http:// www.uns.ajou for further details.
340
C. Kim et al. / Computer Networks 54 (2010) 330–340
Nitin Vaidya received the Ph.D. from the University of Massachusetts at Amherst. He is a Professor of Electrical and Computer Engineering at the University of Illinois at Urbana-Champaign (UIUC). He previously served as the Director of the Illinois Center for Wireless Systems at UIUC. He has held visiting positions at the Indian Institute of Technology-Bombay, Microsoft Research, and Sun Microsystems, as well as a faculty position at the Texas A&M University. He co-authored papers that received awards at the 1998 ACM MobiCom, 2007 ACM MobiHoc, and 2003 Personal Wireless Communications (PWC) conferences. Nitin Vaidya is a recipient of a CAREER award
from the US National Science Foundation. He has served as Editor-inChief for the IEEE Transactions on Mobile Computing, Editor-in-Chief for ACM SIGMOBILE publication MC2R, program co-chair for 2003 ACM MobiCom, and General Chair for 2001 ACM MobiHoc. For more information, please visit http://www.users.crhc.illinois.edu/nhv/.