Configurable Routing in Ad-Hoc Networks

Conﬁgurable Routing in Ad-Hoc Networks

Nadine Shillingford and Christian Poellabauer Department of Computer Science and Engineering University of Notre Dame Notre Dame, IN 46556 {nshillin, cpoellab}@nd.edu

Abstract— The actual use of a wireless ad-hoc network or run across the network, will be unknown a-priori. Further, ad- its operational parameters may be unknown before deployment hoc networks may be accessed by varying numbers of clients or they may change during the life time of a network. This (users), with different applications and differing expectations requires that an ad-hoc network be configurable to the unique needs of a client and that multiple clients can configure the on QoS. Therefore, it will be essential to make configurability network simultaneously. The QoS metric(s) used in the selection and customizability of future ad-hoc networks a key design of routes in an ad-hoc routing protocol can strongly affect the feature. network’s performance. Unfortunately, the majority of existing Toward this end, this work introduces the CMR (Con- routing protocols support only one or two fixed metrics in route figurable Mesh Routing) toolkit which provides an easy-to- selection. We conducted a survey of over 40 routing protocols published from 1994-2007 which indicated that 90% of the use API for ad-hoc networks, allowing applications or users protocols use one or two metrics and only 10% use three to to implement their own routing protocols and QoS metrics. four metrics in route selection. Toward this end, we propose a While our prototype implementation supports four of the most modular routing toolkit for ad-hoc networks, where users and popular QoS metrics, it is easily extensible and we expect that applications can initiate route discoveries that best suit their QoS future versions will cover a large variety of QoS metrics. requirements. To achieve this, we introduce CMR (Configurable Mesh Routing), which enables network users to initiate route The main contribution of this work is the introduction of discoveries that establish routes customized to their unique needs the concept of configurable ad-hoc network routing design (including multi-path routes with different QoS specifications for and implementation of a toolkit supporting such configuration. each path). Our experiments on a 20-node mesh testbed illustrate While CMR will enable us to configure, re-configure, and the ability of CMR to produce routes that mimic the behavior of existing protocols as well as its usefulness in deploying novel, customize an ad-hoc network after deployment, it will also be customized, multi-QoS routes. a valuable tool for rapid prototyping, testing, and comparison of novel routing protocols and for teaching the differences I.INTRODUCTION and inner workings of routing in wireless networks. We have The vast majority of routing protocols for ad-hoc networks implemented CMR as a middleware tool and used it to develop such as Dynamic Source Routing (DSR) [9], Dynamic Des- numerous routing protocols on a network of Linux-based tination Sequence Distance-Vector Routing (DSDV) [18], and wireless mesh routers. Zone Routing Protocol (ZRP) [6] establish routes based on a single Quality-of-Service (QoS) metric, giving the network II.RELATED WORK (and all its users) little choice or flexibility in route establishment. Only a few protocols consider multiple metrics, e.g., Routing protocols for ad-hoc networks have received signif- Admission Control enabled On demand Routing (ACOR) [10] icant attention over the last several years. Most ad-hoc network and Ad-hoc QoS on-demand Routing (AQOR) [23] attempt to routing protocols consider one or two QoS metrics only and include the metrics bandwidth and end-to-end delay in route all applications and clients in such a network must use the selection. We conducted a study of more than 40 routing same protocol and metrics. Once a network is deployed, these protocols for ad-hoc networks, which indicated that 90% of metrics can only be changed by modifying the routing layer the protocols use only one or two metrics in route selection. on each network node. We have studied numerous routing The other 10% use three to four metrics in route selection. protocols that have been proposed from 1994-2007 and Table I However, these routing protocols provide little flexibility be- shows a list of popular routing protocols and the QoS metrics yond their supported QoS metrics. that they implement. The protocols proposed by [1], [15], [25], While we move toward commercial-off-the-shelf available and [2] are abbreviated since no acronyms are specified and easily deployable ad-hoc networks, it will increasingly in the literature. The vast majority of protocols support a be the case that operational parameters of the network, such single metric; only 10% of these routing protocols implement as physical environment, network topology, potential interfer- more than two QoS metrics. Three of the routing protocols ences and hazards, and even the exact type of applications to investigated in our study [13, 17, 10] indicate that they can be extended to allow more QoS metrics (indicated by a ‘+’ This work is supported in part by NSF under grant number CNS- 0545899 and by the Army Research Office under grant number W911NF- sign in Table I), but these papers suggest the extensions as 06-1-0120. future work and still remain to be completed. Table II gives a summary of the number of protocols which implement the extendable and it has been used to implement different routing six main metrics identified during our study. protocols such as ClickDSR [3]. In contrast, CMR purely focuses on the customized deployment of routing layers in Metric Protocol ad-hoc networks and provides the mechanisms to support Shortest path DSDV, CGRS, WRP, DFR, IARP, MMRP, multiple QoS metrics simultaneously. While CMR has been OLSR, TBRPF, AODV, DSR, TORA, ARA, Ariande, AOMDV, BSR, CHAMP, DYMO, developed as middleware tool for Unix systems, it could also DNVR+, IERP, LUNAR, MOR, DQSRa, be implemented by extending Click (which will be considered ZRP, GSR, FSR+, CBRP, LQSR, STAR in our future work). Link quality/strength Babel, Guesswork, SSA, LQSR, QuaSAR, DQSRb Other configuration tools such as the x-kernel [8], Net- Reliability Guesswork, BSR, LBR, ABR graph [4], and the Active Network Research projects [20, b Bandwidth LSQR , ACOR+, AQOR, QuaSAR, 21] offer flexibility and reusability. In the x-kernel, one can DQSRb, FQMM, OLSMQc, QRP using TDMAd create different protocols out of a library of components. Latency LSQRb, ACOR+, AQOR, QuaSAR, However, x-kernel needs to be configured and executed in b DQSR , HSR addition to programming of the individual protocols. CMR Energy/Battery power QuaSAR, Guesswork is focused mainly on routing protocols and does not require aDistributed QoS Routing protocol (abbr.). any additional configuration except the starting of a service bA link-state QoS routing protocol (abbr.). on each network node. The ANTS [22] toolkit is based on cThe On-Demand Link-State Multi-path QoS Routing Protocol (abbr.). the concept of active networks. In ANTS a protocol is defined d QoS Routing Protocol for Ad-Hoc Networks using TDMA (abbr.). as a collection of related code groups that are treated as a TABLE I single unit of protection by the active nodes. The focus of ROUTING PROTOCOLSBY QOSMETRICS ANTS is on programmable networks, whereas CMR’s goal is the customization of the routing layer in ad-hoc networks. The XORP project [7] is a modular routing kit which provides open source implementations of major Internet protocols QoS Metric Number of Protocols Shortest Path 28 such as BIP and OSPF. XORP offers extensibility and also Bandwidth 7 promises the user the ability to implement new protocols. Latency 6 However, compiling of XORP takes up to an hour and requires Reliability 5 Link Quality/Capacity 6 1.4GB of free disk space. In addition, XORP does not have its Energy 2 own forwarding system but instead depends on the forwarding TABLE II system of the underlying operating system. Although, the goal ROUTING METRICSIN NUMBERS of XORP is similar, CMR offers a more compact system for implementing routing protocols in less time and with its own forwarding system. In the QuaSAR [14] protocol, the authors implement four In comparison to these previous efforts, an important design different QoS metrics (battery power, signal strength, band- feature of CMR is its easy deployment and ease-of-use, e.g., it width, and latency). The route discovery algorithm selects does not require dynamic code distribution or reconfiguration routes based on these collected metrics and a precedence/rank- of a kernel and the QoS-metrics for route discovery are ing passed down from the application (if the application does determined using a simple rule language. not specify a precedence, then the default metric precedence is battery power, signal strength, bandwidth, and latency). While III.PRELIMINARIES QuaSAR supports the largest number of QoS metrics of the investigated protocols, it is still inflexible in that an application CMR is designed for wireless ad-hoc networks, including can only give a precedence for route selection and not add or mesh networks, mobile ad-hoc networks (MANETs), and eliminate metrics. sensor networks. An ad-hoc network is a self-configuring The RSVP [24] protocol is used by a host to request specific network that does not have a fixed infrastructure. Nodes in QoS from the network. It is also used by routers to deliver QoS such networks can be dedicated (mesh) routers, sensor devices, requests to all nodes along the downstream paths. RSVP estab- gateway devices, and numerous end devices such as laptops, lishes and maintains state to provide the requested service. It handhelds, or cell phones. As the size of the network increases, is designed to operate with existing routing protocols. Unlike communication between nodes tends to be in the form of RSVP, CMR is not a resource reservation protocol; instead it multi-hop transmissions. This means that packets are routed allows for dynamic customization of routing protocols. through forwarder nodes from a source to a sink. As shown The Click router [11] is a tool that can be used to implement in the previous section, the QoS metrics of these protocols are flexible and configurable routers. Elements in Click are mod- limited and most protocols support only a single metric. CMR ules that perform tasks such as packet selection, modification, allows us to dynamically implement various existing routing and scheduling. A Click configuration is a collection of push protocols, but also novel ones, using any combination of the and pull elements in the form of a graph. Click is very supported QoS metrics. While our current implementation of

2 CMR supports five of the most popular metrics, CMR can return. For the purpose of illustration we will use the Extended easily be extended to support others. Backus-Naur Form metasyntax notation. In the CMR language There are several categories of ad-hoc routing protocols, there are basic and advanced production symbols. A basic the most common ones being reactive and proactive protocols. production symbol is either a terminal symbol or a system Reactive protocols such as DSR [9] typically use some kind of specific constant. These are shown in Table III. flooding during route discovery (84% of the reactive protocols studied in this work), therefore, CMR also relies on this form Symbol Values of route discovery. Other categories such as proactive and alpha = “A” | “B” | “C” | “D” | “E” | “F” | “G” | gossip protocols can also be implemented (which remains a “H” | “I” | “J” | “K” | “L” | “M” | “N” | subject of our future work). In most routing protocols like “O” | “P” | “Q” | “R” | “S” | “T” | “U” | “V” | “W” | “X” | “Y” | “Z” DSR, the route discovery process is initiated when a request digit = “0” | “1” | “2” | “3” | “4” | “5” | “6” | “7” packet (e.g., RREQ in DSR notation) is flooded throughout | “8” | “9” the network and a receiver responds with one or more reply number = digit [ digit ] packets (e.g., RREP in DSR notation) directly back to the symbol = “>” | “<” sender. Route discovery can be initiated by either the source logical = “&&” | “||” | “!” of the data or the sink. CMR supports both sender and receiver metric = “HOP-COUNT” | “AVG-BATTERY-LEFT” initiated route discovery. However, in this paper, we focus on | “DELAY” | “AVG-BANDWIDTH-USED” the situation where the sink initiates route discovery because it quantity = “ALL” | “ANY” | number is common that only the sink is aware of the QoS requirements. In the receiver-initiated route discovery, no explicit route TABLE III CMRLANGUAGE BASIC SYMBOLS reply phase is necessary, therefore sources can utilize routes discovered via route requests messages immediately for data dissemination. The authors in [5] performed an empirical study which Symbol Values demonstrated that only 5-15% of links are asymmetric. There- composite = (“AVG” | “MIN” | “MAX”) metric fore, as in most protocols such as DSR and AODV [19], we OverlapExpression= ”OVERLAP” symbol (number | identifier) assume that the network links are symmetric. MetricExpression = (metric symbol (identifier | number)) | (composite symbol (identifier | num- IV. THE CMRARCHITECTURE ber)) [logical MetricExpression] [logical The CMR architecture is based on four main modules - (1) OverlapExpression] the CMR API, (2) the routing module, (3) the route estab- TABLE IV lishment module, and (4) the resource management module. CMRLANGUAGE ADVANCED PRODUCTION RULES The integration of these modules is displayed in Figure 1(a) and 1(b). Figure 1(a) illustrates the processes that occur during route discovery. The following subsections explain how each The metric terminal symbol is of special significance to the of these modules interact. CMR toolkit. This is a symbol representing a route metric. This may include constraints such as hop count, average A. The CMR API energy capacity (in percentages), average queue length, band- Suppose an application, A (on the sink) wishes to receive width, and reliability. These are specified by the language and data from a sensor node, S (on the source). Also, suppose made known to the users or applications. The ability to easily that A has specific QoS requirements for the transmission and quickly include additional values to this terminal symbol of this data. For example, A would like this data to be sent is the main contributor to the flexibility of CMR. within 300ms and using the minimum energy route in the Table IV lists the advanced production rules of CMR. network. The application sends a message to the CMR API These are a sequence of terminals assigned to a non-terminal indicating its requirements. The following steps occur during symbol. Table V gives examples of these advanced production QoS specification. rules. The application may request a composite of a metric. 1) The application specifies the number of routes required. Currently, the composites included in the CMR language In addition, they specify a baseline or threshold of the are minimum (MIN), maximum (MAX), and average (AVG). QoS requirements desired. In the previous scenario this Example 1 in Table V is used to select a route with the would be the minimum energy route whose delay is less minimum hop count among a set of routes. than 300ms. Metrics can be compared with constants or variables. One 2) The CMR API formulates this subset of QoS require- or more of these comparisons comprise a MetricExpression. ments into CMR rules. These are expressions used to determine whether a particular The operations of the CMR toolkit are primarily based route meets a combination of metric criteria. Example 2 in on the CMR language. This is a syntax used by the sink Table V returns the route with average energy capacity greater to specify the types of routes that the destination should than 50% and hop count less than 3.

3 (a) Route establishment (b) Data ﬂow

Fig. 1. The four main modules of CMR include the CMR API, the routing module (R), the route establishment module (RE) and the resource management module (RM) in a three-node (source, intermediate, and sink) scenario.

Construct Example Algorithm 1 intermediate node parser(r) 1. Composite MIN HOP-COUNT Require: A CMR rule r, upstream metric values u 2. MetricExpression AVG-BATTERY-LEFT > 50 && HOP- Ensure: Update of m COUNT < 3 1: for each i in r do TABLE V 2: Retrieve my metric value, m CMRLANGUAGE EXAMPLES i 3: u.i += mi 4: end for 5: u.hopcount += 1 B. Route Establishment Module 6: return m Once the rule has been formulated, it is passed on to the route establishment module on the sink. The route establish- Algorithm 2 destination node parser(id, r, u, q) ment module then initiates a route discovery process. Require: CMR-RREQ with request id, id, a CMR rule r, The rules are incorporated into a CMR request packet upstream metric values u, and quantity specified, q (CMR-RREQ). CMR-RREQ is an extension of the specifica- Ensure: CMR-RREQ is processed, and number of routes tion in DSR RFC 4728 [9]. This packet is broadcasted to all stored, n is updated neighboring nodes. The following code segment is an example 1: Parse r and store results in r m and r v of the structure of a CMR-RREQ packet with two metrics - 2: if n = quantity then AVG-BANDWIDTH-USED and AVG-BATTERY-LEFT. For 3: Discard route the purpose of this paper, use of the term hopcount refers to 4: else the num addresses DSR field. 5: Execute routecheck algorithm struct rreq { 6: end if /∗ standard DSR option header fields∗/ int option type; int option length; Algorithm 3 route check(r m, r v, u) int id; Require: Metrics in rule, r m, metric values requested in char dest[MAXLEN]; rule, r v, upstream metric values u char src[MAXLEN]; ROUTE src route; Ensure: The route meets requirements specified in rule int num addresses; 1: for each i in r m do /∗ CMR fields ∗/ double avg bandwidth used; 2: if u.i meets r v.i then double avg battery left; 3: Add to route cache int quantifier; 4: else char rule[MAX LENGTH OF RULE]; 5: Discard route int rule type; 6: end if }; typedef struct rreq CMR−RREQ; 7: end for

Another important addition to the route request structure is the rule type ﬁeld which is used to indicate to the source the There are three types of rules: (1) rules which do not contain a type of rule being used. This aids the source in rule parsing. composite function such as MIN, MAX, or AVG, and (2) rules

4 which contain composite functions and overlap requirements. delay during packet transmission. In the first process, A request which has rule type = 1 is evaluated immediately. a time stamp, t1 is added to the request packet when However, all routes from a request which has rule type = 2 it leaves the source/sink. When it arrives at its desti- need to be collected for a specified duration of time so that, nation, the time is noted, t2. The total latency of the for example, the route with a minimum metric value can be transmission is t2 − t1. This particular method requires determined. time synchronization among the nodes in the network. When the route establishment module receives a CMR- The other method is more complex. This involves three RREQ, the rule is parsed to determine which metrics have main components - the queuing delay at each node, the been requested for this particular CMR-RREQ. For example, packet transmission time at each node and the end-to- if the application specified energy capacity and delay as its end packet propagation delay. An example of such a requirements, the rule parser in the intermediate node’s route method is seen in [23]. For the purpose of this paper we establishment module indicates to the resource management use the first process with a simple clock synchronization module that these two metrics have been requested. The algorithm. However, CMR can be modified to use the route establishment module retrieves information about the second process with a few coding adjustments. All end- node’s metrics from the resource management module (to be to-end delay measurements are expressed in time units discussed in Section IV-C). Algorithm 1 illustrates the process for the purpose of this paper. of intermediate node parsing. 4) Bandwidth (AVG-BANDWIDTH-USED): The current Any node which receives a CMR-RREQ determines bandwidth utilization at each node can be retrieved from whether it is the target of the request. This is also performed the /proc/net/dev file. This file contains the number by the route establishment module of the node. Algorithm 2 of bytes received and transmitted on each network illustrates the steps taken once a CMR-RREQ arrives at interface. The percentage of bandwidth utilization is the source node. The route establishment module reads the equivalent to the sum of the number of bytes transfered quantity field of the CMR-RREQ and parses the CMR rule. into the node and the number of bytes transferred out This is different from the parsing done at the intermediate of the node during a defined interval. CMR includes nodes. The source determines which metrics are specified a small daemon that runs in the background on each within the rule and what values are required. This is done node. The daemon performs this calculation and stores in line 1 of Algorithm 2. The resulting metrics and metric the current bandwidth utilization in a simple text file. values are stored in the variables r m and r v respectively. During the parsing at each intermediate node, this file The route establishment module will then iterate through these is read and the value is retrieved. For the purpose of two variables and determine whether the route matches the this paper, current bandwidth utilization is expressed in criteria specified in the rule. If it does, then the route is added kilobytes per second. to the route cache. If not, the route is discarded. Once the resource management module has delivered the C. Resource Management Module values of all the metrics required by the route establishment module, the CMR metric fields in the packet are updated. The The resource management module is responsible for moni- packet is then broadcasted to all listening nodes in the network. toring and retrieving QoS metrics. We have implemented four different QoS metrics. The following list describes how the D. Routing Module resource management module monitors and retrieves each QoS metric in a Linux environment. Once the route establishment module has received the route(s), data transmission begins. The source streams data 1) Hopcount (HOP-COUNT): This is the number of hops to the sink via the routing module on each node. Data packets that a CMR-RREQ is forwarded through before it arrives are sent via a unicast channel to the sink using the route stored at the destination. This value is incremented every time in the route cache. Similar to DSR, routes are stored within the an intermediate node forwards a packet on the upstream packet and each intermediate node determines which neighbor path. In the DSR RFC specification, this is equivalent is the next hop towards the destination. to the num addresses variable. 2) Battery power remaining (AVG-BATTERY-LEFT): This V. IMPLEMENTING PROTOCOLS is a measure of the amount of battery power left on a node. To determine this value on Linux, the resource In order to show the effectiveness of the CMR protocol management module reads the last full capacity we chose three reactive protocols that use flooding as the value in the file /proc/acpi/battery/BAT 0/info and main form of route discovery. We demonstrate the flexibility compares it to the remaining capacity value from of CMR by implementing variants of each of these protocols /proc/acpi/battery/BAT 0/state. The remaining bat- by simply changing the rules being specified during route dis- tery power values specified in rules are expressed in covery. These protocols are Dynamic Source Routing protocol percentages. (DSR) [9], Split Multipath Routing protocol (SMR) [12], and 3) End-to-end delay (DELAY): There are two main ways Admission Control enabled On demand Routing (ACOR) [10]. of dealing with the problem of calculating end-to-end In addition, we introduce two novel protocols which we call

5 CMR-MD and CMR-EDH. These protocols will be discussed in the following sections. A. CMR-DSR The route discovery process of DSR is similar to the processes explained in Section IV. The source initiates a route discovery process by sending an RREQ packet to the destination. The RREQ is received by every node in transmission range. Each node forwards the RREQ, however, before a RREQ is forwarded, the node appends its identification to the (a) 0% overlap source route of the RREQ. When the destination receives the first RREQ, it stores the route contained in the RREQ in the route cache. The first RREQ that arrives at the destination is referred to as the shortest path route. To implement a DSR-style protocol using the CMR toolkit our packet will have the following values: quantity = 1 rule = MIN HOP−COUNT rule type = 2 (b) 25% overlap The forwarding nodes do not need to execute any of the additional CMR functions except incrementing the hop count. The destination will simply parse the CMR rule and determine that we are implementing DSR. It will store the first route that arrives. B. CMR-SMR The Split Multipath Routing (SMR) protocol is also a reactive protocol whose route discovery mimics the DSR protocol. (c) 60% overlap However, the main challenge of SMR is to produce maximally disjoint routes. The main difference in the implementation Fig. 2. Three examples of routes with varying levels of disjointness. Route of SMR and DSR is that during route discovery, there are A is the solid line and Route B is the dashed line. Disjointness is expressed many duplicate route requests being transmitted. Duplicate in percentage of overlapping. route requests that originate from a different incoming link and whose hop count is larger than the previous route request Algorithm 4 find overlap(r, o) are not discarded. In addition, intermediate nodes are not Require: A set of routes, r and a requested overlap ratio, o allowed to reply to requests even when they contain a route Ensure: The maximally disjoint route with overlap ratio to the destination in their route cache. This is to ensure that greater than or less than o all possible routes arrive at the destination. The destination 1: Let r be shortest path route records the entire source path of the first route request that 1 2: for each route r , i = 2, 3, ...n and n is number of routes it receives and then sends a route reply. It then continues i do receiving other route requests for a particular duration of time. 3: for each node, k in r do Once the duration of time has expired, the destination chooses i 4: if k appears in r then the maximally disjoint route. 1 5: ratio += ratio + 1 To implement CMR-SMR, the following rule is included 6: end if in the packet. For the purpose of this paper, we are returning 7: Let d be the average of the sizes of r and r two disjoint paths although a greater number of paths can be 1 i 8: if ratio less than o then returned (this can be done by simply modifying the quantity 9: Return r field in the route request packet). i 10: end if quantity = 2 11: end for rule = OVERLAP < 50 12: end for rule type = 2

An important note is that vanilla SMR returns the maximally disjoint routes. With CMR-SMR, the user has the ability to speciﬁed in [12]. Then, the process collects other routes for a specify the amount of overlap required. The destination stores set duration of time. the route stored in the ﬁrst route request that it receives as CMR-SMR computes the overlap ratio by dividing the

6 number of common links in the routes by the average number E. CMR-MD of links in the two routes. Figure 2(a), 2(b), and 2(c) are The CMR-Multi-Delay (CMR-MD) protocol is used in a examples of routes which vary in their levels of overlapping. situation where the goal is soft real-time delivery of packets. In Figure 2(a), routes A and B have an overlap ratio of 0 For example, in a network that delivers live audio/video because there are no nodes in common. Figure 2(b) has an packets, the user may require a particular threshold of data overlap ratio of 25% because the average of the two route delivery. In this case, late packets may cause a decrease in the lengths is 4. Out of the four links on each route, only one link quality of the streaming but will not be catastrophic. Therefore, is common to both routes (25%). Figure 2(c) has an overlap the user may use CMR-MD for routing. The user may also ratio of 60%. The average of the two route lengths is 5 ((4 require that there be a backup route in the event that the + 6))/2). Since three links are common on both routes that main route becomes unstable. The authors of [16] specify overlap ratio is 3/5 which is 60%. that including multiple entries for a destination in the route We determine the overlap ratio of two routes by examining cache can significantly reduce the number of route discoveries. the routes, and for each route, ri where i=2,3,...n and n is the Therefore, using CMR, the user can create this CMR-MD number of routes collected within the specified time period, protocol that will chose a route which can ensure soft real- we compare the number of times a particular node, k in route time delivery of packets. This protocol determines whether the ri appears in the route of first route request received, r1. end-to-end delay of a route is less than a particular threshold. The process of finding the ratio is shown in Algorithm 4. The rule for this protocol is Algorithm 4 is a polynomial algorithm, however more efficient algorithms can be implemented as well. quantity = 2 rule = DELAY < 50 C. CMR-ACOR rule−type = 1 The ACOR protocol proposed by [10] uses the metrics bandwidth and delay in route selection. The authors use VI.EVALUATION a simple technique for calculating residual bandwidth by We implemented the CMR-DSR, -SMR, -ACOR, -EDH, listening to the bandwidth of the IEEE 802.11 MAC. For each and -MD protocols using the CMR toolkit. Our network node, the local bandwidth is a calculated value which considers testbed consisted of 20 Stargate devices. Stargate devices are the maximum bandwidth achievable (2MB/s, 11MB/s, and small single board computers equipped with an Intel 400MHz 54MB/s), the residual bandwidth of the node, and a requested XScale processor, 64MB SDRAM and an AmbiCom wireless bandwidth value. The formula for calculating delay in ACOR 802.11 card1. Each Stargate device uses the Linux operating is a combination of the estimated delay at each hop, the upper system (version 2.4.19). Note that since our Stargates were bound delay supported by a flow and the accumulated delay at not equipped with internal battery sources we conducted these each node. To implement CMR-ACOR we use the following experiments on Stargates which were connected to external rule: power. We simulated the drain of battery power by first initializing the percentage of battery power to 100 and then quantity = 1 rule = MIN DELAY && AVG−BANDWIDTH−USED < 2 decrementing this value by small fractions at the receipt of rule type = 2 each packet. This resulted in a realistic reduction in ‘battery power’ which did not adversely affect our results. For experimental purposes, the devices were arranged in D. CMR-EDH three different topologies which we termed very sparse, In the next two subsections we discuss two novel proto- sparse, and dense matrix topologies. Each matrix is a con- cols. This first protocol which we call CMR-Energy-Delay- nected graph with varying levels of connectivity. Table VI Hopcount or CMR-EDH, would be rather useful in the event gives the features of the different topologies while Figure 3 that an application requires a path that has a particular delay gives a visual example of each topology. threshold in an energy constrained network. One example of such a case is if a network consisting of multiple mobile Matrix Topology Number of Neighbors devices has been deployed for a prolonged period of time. Very sparse 1-3 The power level of the mobile devices would be running Sparse 2-4 low. To increase the probability of successful transmission, the Dense 3-5 application may request a particular threshold on the average power level of the nodes on the route. The rule for this protocol TABLE VI NUMBEROFNEIGHBORSPERNODEFORTHETHREETOPOLOGIES. is quantity = 1 rule = AVG−BATTERY−LEFT > 50 && DELAY < 30 We compared the results of the experiments in terms of the && HOP−COUNT < 10 metrics which we implemented - bandwidth, delay, hopcount rule−type = 1 1http://www.xbow.com

7 8

5 CMR-DSR 4 CMR-EDH 3 ACOR Average Hop countHop Average 2

0 Very sparse Sparse Dense

Fig. 4. Number of hops in route

(a) Very sparse

50 CMR-DSR 40 CMR-EDH 30 CMR-ACOR 20

Average Remaining battery power (%) power batteryRemaining Average 0 Very sparse Sparse Dense

(b) Sparse

Fig. 5. Percentage of battery power remaining

20 CMR-DSR 15 CMR-EDH CMR-ACOR 10

0 Fig. 3. The three topologies used in the experiments. Very sparse Sparse Dense

Fig. 6. End-to-end delay

8 Metric Very Sparse Sparse Dense Remaining battery power (%) 40.43 45.16 48.14 Hop count 7.85 7.5 10.27 2 Current bandwidth (KB/s) 1.42 1.13 0.80 1.8 Delay (s) 31.0 26.5 41.1 1.6 1.4 TABLE VII 1.2 CMR-DSR AVERAGEVALUESOFTHEROUTESREJECTEDBY CMR DURINGROUTE 1 DISCOVERY FOR THE CMR-EDH PROTOCOL

(KB/s) CMR-EDH 0.8 0.6 CMR-ACOR 0.4 0.2 Average Current bandwidth utilization bandwidthCurrent Average 0 EDH protocol remains lower than the other protocols. The Very sparse Sparse Dense results for the dense topology show that the average delay of the CMR-EDH protocol is as much as 10 time units lower than the other two protocols combined. Again, this is due to the nature of the protocol. CMR-EDH specifies a minimum delay constraint therefore, any routes added to the route cache Fig. 7. Bandwidth utilization have this minimum delay requirement and routes which do not have this requirement are rejected. These rejected routes may be accepted by other protocols. This explanation extends to and energy. Overhead is an important component in evaluating the CMR-ACOR protocol as well. Although the CMR-ACOR a toolkit such as CMR. Our results show that the parsing of protocol specifies that the minimum delay should be returned, CMR rules during route discovery takes only 1.3 milliseconds this does not mean that the minimum delay is going to be on average. small. Figures 4, 5, 6, and 7 compare the three single-path proto- Figure 7 shows that the average current bandwidth utiliza- cols to each other. These protocols include CMR-DSR, -EDH, tion increases with the connectivity of the topology. This is and -ACOR. The QoS requirements used in these experiments because the individual nodes on the route to the destination are the same as those mentioned in Section V and the results have a higher load as the number of possible routes to the are an average of 10 runs. destination increases. DSR has a linear increase in average Overall, as indicated in Figure 4 the hopcount of the bandwidth utilization as the connectivity of the topology in- routes returned by the three protocols are similar with only creases. The values for CMR-EDH also increase with topology slight variations of about 5% in the very sparse and sparse connectivity, however, it levels off in the dense topology. topologies. The CMR-EDH protocol appears to produce a This is directly correlated to the drop in hop count from lower hopcount than the other topologies, however, closer the sparse to dense topology. Again, this does not mean that analysis of the data shows that the majority of the longer routes with higher bandwidth utilization were not discovered routes were rejected because of either low battery power or in the CMR-EDH route discovery. The CMR-EDH protocol high delays in the routes. The multiple metrics in the CMR- is a more selective protocol, therefore, many of these routes EDH protocol resulted in a smaller number of routes that are were rejected based on other criteria besides the bandwidth. added to the route cache. Table VII lists the characteristics of CMR-ACOR also specifies bandwidth in the QoS require- the average route rejected by the CMR-EDH protocol during ments. However, the bandwidth component of the CMR- route discovery. ACOR rule is very high. Therefore, only 30% of the routes Figure 5 illustrates the average remaining battery power. The were rejected due to an average current bandwidth utilization CMR-DSR and CMR-ACOR protocols perform similar to each greater than 2. These results also show the importance of fine other in terms of remaining battery power. This is because tuning the QoS requirements. A constraint that is too high these two protocols ignore energy requirements. The results may result in a poorer quality of routes. In future work, we of CMR-EDH are more interesting. Since the CMR-EDH will further investigate the process of specifying proper QoS protocol stresses the amount of battery power required by the requirements. routes, the CMR-EDH protocol has an increasing advantage Our implementation of CMR-SMR on a dense matrix topol- over the other protocols in this metric with 6% in the sparse ogy yielded good results. The CMR-SMR protocol returned topology and 16% in the dense topology. routes whose level of overlap were within the threshold of The average delay of the routes returned from our experi- 50%. The average percentage of overlapping (overlap ratio) ments are displayed in Figure 6. The results show a random was 33.5%. The average hop count of the secondary routes trend in delay. CMR-DSR returns the route with the minimum discovered was higher (7.33 hops) than that of the first route hop count which may or may not correspond to a low delay discovered (5.25 hops). route. This can be seen in the almost random nature of the Table VIII shows the results of the CMR-MD protocol results. The average delay of the routes returned by the CMR- experiments. This novel protocol returns multiple routes with

9 an end-to-end delay within a certain limit. For the purpose [6] Z. J. Haas. A new routing protocol for the reconfigurable wireless of this paper, we used 50 time units as the threshold and networks. In Proceedings of 6th IEEE International Conference on Universal Personal Communications, volume 2, pages 562–566, October requested two routes. Route 1 represents the average of the first 1997. qualifying routes discovered by CMR-MD in each run while [7] Mark Handley, Orion Hodson, and Eddie Kohler. Xorp: an open platform Route 2 is the average of the next qualifying route. The average for network research. SIGCOMM Comput. Commun. Rev., 33(1):53–57, 2003. hop count of Route 1 is lower since it is discovered earlier. [8] N. C. Hutchinson and L. L. Peterson. The x-kernel: An architecture Table VIII indicates that the end-to-end delay requirement was for implementing network protocols. IEEE Transactions on Software met by both routes in each run of this experiment. Engineering, 17(1):64–76, January 1991. [9] D. B. Johnson and D. A. Maltz. Dynamic source routing in ad hoc wireless networks. In Imielinski and Korth, editors, Mobile Computing, Metric Route 1 Route 2 Average volume 353. Kluwer Academic Publishers, 1996. [10] N. Kettaf, A. Abouaissa, T. Vuduong, and P. Lorenz. A cross layer Hop Count 6.55 8.11 7.33 admission control on-demand routing protocol for qos applications. Battery Power Remaining 45.17 38.92 42.04 International Journal of Computer Science and Network Security, 6(9B), Bandwidth 1.56 1.42 1.49 September 2006. http://tools.ietf.org/id/draft-kettaf-manet-acor-02.txt; accessed August 24, 2007. Delay 22.9 37.5 33.7 [11] E. Kohler, R. Morris, B., J. Jannotti, and M. R. Kaashoek. The Click modular router. ACM Transactions on Computer Systems, 18(3):263– TABLE VIII 297, August 2000. THETWOROUTESRETURNEDFROM CMR-MD. [12] S.J. Lee and M. Gerla. Split multipath routing with maximally disjoint paths in ad hoc networks. IEEE International Conference on Commu- nications, 10:3201–3205, 2001. [13] Y.J. Lee and G.F. Riley. Dynamic nix-vector routing for mobile ad hoc networks. In IEEE Wireless Communications and Networking VII.CONCLUSIONAND FUTURE WORK Conference, 2005, volume 4, pages 1995–2001, March 2005. [14] S. R. Medidi and K.H. Vik. Quality of service-aware source-initiated ad- This paper introduces the configurable mesh routing toolkit, hoc routing. In First Annual IEEE Communications Society Conference on Sensor and Ad Hoc Communications and Networks, pages 108–117, CMR. This toolkit allows users/applications to set QoS thresh- October 2004. olds for route discovery. Our experiments indicate that CMR [15] A. Munaretto, H. Badis, K. Al Agha, and G. Pujolle. A link-state can be used to implement existing protocols (DSR, SMR, and qos routing protocol for ad hoc networks. In Mobile and Wireless Communications Network, 2002. 4th International Workshop on, pages ACOR) as well as novel protocols (CMR-EDH and CMR- 222–226. IEEE, 2002. MD). They also illustrate the ability of CMR to implement [16] A. Nasipuri, R. Castan˜eda, and S. Das. Performance of multipath routing both single path (DSR, EDH, and ACOR) and multipath pro- for on-demand protocols in mobile ad hoc networks. Mobile Networks and Applications, 6:339–349, 2001. tocols (SMR and MD). In addition, as mentioned earlier, the [17] G. Pei, M. Gerla, and T. Chen. Fisheye state routing in mobile ad hoc overhead of the CMR rule parsing algorithms is significantly networks. In Proceedings of ICDCS Workshop on Wireless Networks low incurring only 1.3 milliseconds on average. In future and Mobile Computing, April 2000, Taipei, Taiwan, pages D71–D78, April 2000. work, we intend to explore a version of CMR that allows for [18] C. E. Perkins and P. Bhagwat. Highly dynamic destination-sequenced asymmetric links. In addition, we intend to explore different distance-vector routing (DSDV) for mobile computers. In SIGCOMM methods for metric calculations such as a delay calculation ’94: Proceedings of the conference on Communications architectures, protocols and applications, pages 234–244, 1994. that incorporates queueing delays at each node. Although no [19] C. E. Perkins and E. M. Royer. Ad hoc on-demand distance vector mention was made of route maintenance we assume that a routing. In 2nd IEEE Workshop on Mobile Computing Systems and method similar to that of DSR will be implemented in future Applications, pages 90–100, February 1999. [20] J. M. Smith, K. L. Calvert, S. L. Murphy, H. K. Orman, and L. L. work as well. Peterson. Activating networks: A progress report. IEEE Computer, Overall, CMR has proven to be a useful toolkit based on the 32(4):32–41, April 1999. results of our 20 node testbed. We believe that the toolkit is a [21] David L. Tennenhouse and David J. Wetherall. Towards an active network architecture. Computer Communication Review, 26(2), May valuable contribution to the area of routing in ad-hoc networks 1996. and will be particularly useful for future work on multi-QoS [22] D. Wetherall, J. Guttag, and D. Tennenhouse. ANTS: A toolkit routing in ad-hoc networks. for building and dynamically deploying network protocols. In IEEE OPENARCH, April 1998. [23] Q. Xue and A. Ganz. Ad hoc qos on-demand routing (AQOR) in REFERENCES mobile ad hoc networks. Journal of Parallel and Distributed Computing, 63(2):154–165, February 2003. [1] S. Chen and K. Nahrstedt. A distributed quality-of-service routing in [24] L. Zhang, S. Deering, D. Estrin, S. Shenker, and D. Zappala. RSVP: A ad-hoc networks. IEEE Journal on Selected Areas in Communications, new resource reservation protocol. IEEE Network Magazine, 40(5):116– 17(8), August 1999. 127, September 1993. [2] Y. Chen, Y. Tseng, J. Sheu, and P. Kuo. On-demand, link-state, multi- [25] C. Zhu and M. Corson. Qos routing for mobile ad hoc networks. In path qos routing in a wireless mobile ad-hoc network. IEEE Infocom, volume 2, pages 958– 967, June 2001. [3] S. Doshi, S. Bhandare, and T. Brown. An on-demand minimum energy routing protocol for a wireless ad hoc network. Mobile Computing and Communications Review, 6 (3), July 2002. [4] J. ELISCHER and A. COBBS. The netgraph networking system. technical report (jan.), 1998. [5] D. Ganesan, B. Krishnamachari, A. Woo, D. Culler, D. Estrin, and S. Wicker. Complex behavior at scale: An experimental study of low- power wireless sensor networks, 2002.