NWC: Node Weight Computation in MANETsKaroly Farkas

Institute of Informatics and EconomicsUniversity of West Hungary

Bajcsy-Zsilinszky u. 9.H-9400 Sopron, Hungary

Email: farkas@inf.nyme.hu

Theus Hossmann, Bernhard PlattnerComputer Engineering and Networks Laboratory

ETH ZurichGloriastrasse 35

CH-8092 Zurich, SwitzerlandEmail: {hossmath, plattner}@tik.ee.ethz.ch

Lukas RufRuf Research & Consulting

Bellariastrasse 11CH-8002 Zurich, Switzerland

Email: lukas.ruf@rrc.ch

Abstract— As mobile devices are getting more and moreubiquitous, the paradigm of wireless Mobile Ad hoc NETworks(MANETs) is gaining popularity. Especially distributed real-timeapplications are attractive for their users in this environment.To help manage these applications in MANETs, previously wedeveloped a distributed algorithm called PBS (Priority BasedSelection). PBS divides the ad hoc network into zones and selectsand maintains a set of nodes, which act as zone servers, to managethese zones. The zone server selection applies node prioritycomparison, which reflects the node’s capabilities to act as zoneserver.

In this paper, we propose a mechanism called NWC (NodeWeight Computation) to be applied in the node priority com-parison of PBS. NWC computes the node weight, on which thepriority comparison is based, as the weighted linear combinationof the node parameters. The parameter weights are extractedfrom the so-called service profile which reflects the characteristicsand requirements of the given service. To create this profile wedeveloped a procedure using factorial design via simulations andmulti-objective optimization. Our NWC mechanism, applying thecreated service profile, assigns the highest priorities to the bestsuited nodes for a given service type and thus designates the mostpowerful nodes to be selected as zone servers by PBS. Moreover,the weight computation of NWC can be used by other clusteringalgorithms in MANETs, too.

I. INTRODUCTION

The number of mobile devices with wireless networkingsupport is constantly increasing these days. Direct communi-cation between these devices makes data exchange quick andcheap leading to the formation of multi-hop wireless MobileAd hoc NETworks (MANETs) [1]. In such networks, thedevices communicate directly in a spontaneous, ad hoc mannerwithout relying on any pre-existing infrastructure or centraladministration. However, the ad hoc way of communicationresults in several challenges including service management inthis flexible and unreliable environment.

The zone-based service management architecture [2] is apromising candidate to be used in MANETs. It provides acompromise between the centralized client/server architecture,which is error prone, and the distributed peer-to-peer archi-tecture, which suffers from limited scalability. Applying thezone-based model the network is divided into separate zones.In every zone, a dedicated server node, the zone server, handlesthe service management issues and synchronizes with the otherzone servers (see Fig. 1).

However, the zone server nodes should be selected in anefficient and distributed manner using the most powerful nodesas servers. To this end, we previously developed a distributedalgorithm called PBS (Priority Based Selection) [3]. This

Fig. 1. Zone-Based Service Management Architecture in MANETs

algorithm is based on graph theory, and computes and main-tains, using priority comparison, an appropriate DominatingSet (DS)1 of the ad hoc network graph containing nodes whichcan be used as zone servers.

In this paper, we propose a mechanism called NWC (NodeWeight Computation) to be applied in the node priority com-parison of PBS based on a set of node parameters and thecharacteristics of the service being used. The novelty of NWCis taking into account several parameters in the node weightcomputation and the technique to create the so-called serviceprofile. NWC computes the node weight, on which the prioritycomparison is based, as the weighted linear combination of thenode parameters. The parameter weights are extracted fromthe service profile. The role of this profile is to reflect thecharacteristics and requirements of the given service, and itsimply contains the appropriate parameter weights which arecomputed or given by the service designer in advance. As thetechnique to create this profile we propose factorial designusing simulations and multi-objective optimization. Moreover,NWC can be used for node weight computation in MANETsalso by other clustering algorithms.

The rest of the paper is structured as follows. In Section II,we briefly survey related node weight computation approaches.We present our NWC mechanism in Section III, and theservice profile creation technique in Section IV. And finally,we conclude the paper in Section V.

1A Dominating Set is a subset of the graph’s nodes, such that all the nodesare either part of the DS or are directly connected to a member of the DS.

II. RELATED WORK

The simplest approaches in regard to selecting the zoneserver nodes optimize the selection for a single objective (likepower consumption), and they are referred to as single metricmechanisms. There are other approaches that use some combi-nation of several metrics, thus combining multiple objectivesin the selection algorithm. We refer to these approaches asmultiple metric mechanisms. In the following, we discuss twosingle metric and two multiple metric mechanisms.

A. Single Metric Mechanisms

The largest-ID/lowest-ID mechanism [4] is one of thesimplest and most common approaches in the constructionof a Dominating Set. In this approach, each node of thenetwork is assigned with a unique ID and the nodes withthe largest/lowest IDs are selected as dominator nodes. Thisalgorithm does not show good adaptation properties, since theID assignment is static and changing the node IDs requires acomplex mechanism which is not practical.

The highest-degree mechanism [5] is another simple ap-proach. Each node broadcasts its ID to its neighbors. The nodewith the maximum number of neighbors, or maximum degree,is chosen as clusterhead, and any tie is broken by the nodes’IDs, which are unique in the network. The constructed DS hasa low rate of change, but the throughput is also low.

B. Multiple Metric Mechanisms

Shaikh et al. propose a mechanism in [6] to select the DSbased on the node degree and the remaining battery power ofthe nodes. In this case, the nodes frequently alternate betweentheir dominating and dominatee status, thus balancing energyconsumption and prolonging network lifetime. However, thisapproach does not consider the requirements of the service forwhich the DS is created.

Chatterjee et al. in [7] propose a weighted clustering mecha-nism called WCA (Weighted Clustering Algorithm). The mainidea of this approach, similarly to our NWC mechanism, is toperform the weight computation according to the requirementsof the application/system. Four parameters are considered inthe weight computation, namely the node degree, the batterypower, the mobility of the node and the distance between thenode and its communication counterparts. The node weight isthe weighted linear combination of the parameter values, suchas in NWC, where the weight co-efficients are dependent onthe service type being deployed in the network.

Our NWC mechanism is similar to WCA and based on thesame idea and node weight computation method. However,in WCA it is not specified, how the parameter weight co-efficients are computed. For this in NWC, we have developeda technique based on factorial design which can be easilyapplied by service developers.

III. NODE WEIGHT COMPUTATION

In this section, after describing the assumptions and require-ments with regard to our NWC mechanism we present NWCwhat we have developed to compute node weights being usedin the PBS algorithm’s node priority comparison.

A. Assumptions and RequirementsWe consider the following prerequisites for the weight

computation:• Local resource/parameter values: Every node is able to

extract/collect all the necessary information related to itslocal resource parameters, such as CPU, memory, batterycapacity and load.

• Link quality information: The nodes are able to collectlink quality information of their links from their networkinterface devices measuring the links’ SNR (Signal toNoise Ratio) values.

• Service profile: In case of various service types, differentimportance levels (parameter weights2) are to be assignedto the same parameter set, which is called service profile.Since this profile is created by the service developer,a mechanism has to be developed aiding the servicedevelopers in this procedure (see Section IV).

B. Node Weight Computation MechanismTo provide a systematic way for computing node weights to

be used in the PBS algorithm, we have developed a mechanismcalled NWC (Node Weight Computation).

The few mechanisms existing today (see Section II) useonly some simplified heuristics to classify/weight the nodesin the network. In these mechanisms, just one or very fewnode properties are taken into account aiming to achieve aspecific objective (e.g., minimize energy consumption).

However, different services have different requirements. InNWC, several node properties/parameters are used to accom-plish the node weight computation. In case of each servicetype, the most important properties from the viewpoint of theservice are considered with high parameter weights resultingin the best suited DS selection for the given service.

1) Node Parameters: The parameters of the node reflect thenode’s capabilities to act as zone server. In NWC, we considerthe following five parameters grouped into three classes:

Processing PowerCPU - It represents the available CPU capacity ofthe node.Memory - It represents the available memory capac-ity of the node.

EnergyBattery - Represents the available energy level of thenode.

ConnectivityLink quality - The link quality parameter representsthe quality of the wireless connections between thenode and its neighbors.Position - The position parameter is related to thenumber of neighbors the node has (node degree).This reflects the node position in the network.

The parameter values are computed in the following way:

PCPU (t) = 1− loadCPU (t), (1)

2Note that the parameter weight and the node weight are different things.NWC computes the node weight as the linear combination of the nodeparameters. In this computation, every parameter is weighted by its ownparameter weight extracted from the service profile.

where loadCPU (t) is the actual fraction (between 0 and 1)of the node’s CPU load. The CPU parameter value is timedependent and nodes with higher CPU load have lower valueof this parameter.

Pmem(t) = 1− loadmem(t)MAXmem

, (2)

where MAXmem is the maximum memory capacity, whileloadmem(t) is the actual memory load in MByte on thenode, respectively. The memory parameter value is also timedependent and higher memory load on the node results inlower parameter value.

Pbat(t) = 1− loadbat(t), (3)

where loadbat(t) is the actual fraction (between 0 and 1) ofthe node’s battery load. The battery parameter value is timedependent and higher battery load results in lower parametervalue giving an indication about the remaining battery power.

Plink(t) =N∑

i=1

SNRlink i(t)MAXSNRlink i

× 1N

, (4)

where MAXSNRlink iis the maximum and SNRlink i(t) is

the actual SNR value of link i of the node, respectively.Moreover, N is the number of the node’s neighbors. The linkquality parameter is time dependent and directly proportionalto the measured SNR values of the node’s links.

Ppos(t) = 1− 1node deg(t)

, (5)

where node deg(t) is the actual degree of the node. Theposition parameter value is time dependent and nodes withhigher node degree have higher parameter value.

2) NWC Algorithm: When the node weight is required thenode does the following procedure:

Step 1: Collect the CPU load, memory load and battery energy leveland compute the parameter values PCPU (t), Pmem(t) andPbat(t);

Step 2: Get the list of neighbors;Step 3: Compute the link quality parameter value Plink(t);Step 4: Compute the position parameter value Ppos(t);Step 5: Collect the parameter weights WCPU (serv),

Wmem(serv), Wbat(serv), Wlink(serv), Wpos(serv)from the service profile;

Step 6: Compute the node weight based on the following equation:

Wnode x(t) = WCP U (serv)PCP U (t)NUMparam

+Wmem(serv)Pmem(t)

NUMparam+

+ Wbat(serv)Pbat(t)NUMparam

+Wlink(serv)Plink(t)

NUMparam+

+ Wpos(serv)Ppos(t)

NUMparam,

where NUMparam is the number of the parameters whichis 5 in our case.

Note that with this computation we get a normalized nodeweight value falling in the range of [0..1] because the parame-ter values and the parameter weights3 are also normalized (seeFig. 2). Node weight 1 means that the node is powerful, since

3For the sake of simplicity we use only 3 discrete parameter weight values.

node weight 0 means that the node is not powerful enough toact as a zone server.

Fig. 2. Value Scales in NWC

IV. SERVICE PROFILE CREATION

As we mentioned above, different importance levels andthus different parameter weights are to be assigned to thesame parameter set in case of various service types. Theseparameter weights are collected in the service profile createdby the service developer. The approach we have taken hereconsists of the definition of static service profiles. Hence, eachservice developer assigns the parameter weights in advance forthe given service. Then this profile is used by all the nodesfor the node weight computation.

Note that with such a static approach it is not possibleto accurately predict the future service context (e.g., networkscenario, mobility behavior of the nodes) in advance where thegiven service will be deployed. Thus, even knowing the basiccharacteristics of the service an optimal profile (parameterweight assignment) is not granted for every situation. Toachieve this, a more complex dynamic approach should bedeveloped which remains as future work.

To define the service profile and thus assign the parameterweights we have developed a mechanism using factorial designand multi-objective optimization [8]. This experimental designis based on simulation and discussed in the following.

A. Pseudo Game Service SpecificationWe have defined a pseudo service, a real-time multiplayer

game, via which we demonstrate here the procedure of thefactorial design to assign the node parameter weights, and thuscreate the service profile.

The main characteristics of this pseudo service are thefollowing:• Processing load generation: The service generates a

certain processing load on the nodes. Unfortunately, in asimulation environment it is hard to realistically simulatethe changes of the processing load (CPU and memoryload) without implementing the service itself. Moreover,this load can be different on diverse device types. Thus,for sake of simplicity we assume that, whatever the devicetype is, being a zone server of our game has a minimumrequirement of 500 MHz processor and 50 MByte freememory, since the game playing activity requires 700MHz processor and 30 MByte free memory, respectively.Moreover, the game server role generates a 10% CPUload and occupies 50 MByte memory continuously, sinceplaying the game (being a client) generates a 30% CPUload and occupies 30 MByte memory continuously.

After this, the minimum requirements of the serviceare checked before selecting a zone server or deployingthe game client on a node. Moreover, the generatedprocessing load of the service can be computed now.

• Energy consumption: For sake of simplicity, in com-puting the consumed energy by the service we consideronly the traffic generated by the game on the node. Thus,we define the energy consumption of the service as thelinear function of the game traffic, i.e., every sent/receivedpacket consumes 1 mW energy.We have implemented this simple mechanism in the sim-ulator. Moreover, we used this strategy also in computingthe battery level of the node taking into account only thetraffic the node sent or received.

• Generated traffic: We define the game traffic as a fullduplex 10 kbit/s CBR data flow (20 packet/second with 64byte packet size) [9] between the zone servers and theirclients. For server to server synchronization, we assumethat the traffic coming from the clients of the given serveris simply forwarded to the other servers.

The characteristics of our pseudo game service are summa-rized in Table I.

TABLE ICHARACTERISTICS OF THE PSEUDO GAME SERVICE

Property ValueMin. CPU (server) 500 MHzMin. CPU (client) 700 MHzCPU load (server) 10%CPU load (client) 30%Min. free memory (server) 50 MByteMin. free memory (client) 30 MByteMemory load (server) 50 MByteMemory load (client) 30 MByteEnergy consumption 1 mW per packet sent/receivedTraffic (server ⇔ client) Full duplex CBR - 10 kbit/sTraffic (server ⇔ server) Forwarded traffic coming from the clients

B. Factorial DesignFactorial design is an experimental design technique espe-

cially useful to measure the effects of a group of factors onthe output of an experiment [8]. Applying this technique itis possible to determine that combination of the factor valueswhich gives the best performance of the system. The completeanalysis of the factors is called Full Factorial Design. Usually,a full factorial design is expensive, time consuming and notpossible to carry out due to the huge number of combinationsto be investigated. However, in most of the cases some of thefactor values can be eliminated intuitively, and thus we aretalking about Fractional Factorial Design.

In NWC, we have five factors (the parameter weights) withthree different values of each (see Section III-B). Our objectiveis to determine via simulations that combination of the factorvalues, the service profile, which gives the best performanceof the selected metrics (see Section IV-D).

1) Fractional Factorial Design: In the NWC mechanism,three possible values can be assigned to each factor. The valuesare shown in Table II (0 - low; 0.5 - normal; 1 - high).

TABLE IIVALUES OF THE DIFFERENT PARAMETER WEIGHT FACTORS

Weight ofCPU Memory Battery Link Quality Position

0 ; 0.5 ; 1 0 ; 0.5 ; 1 0 ; 0.5 ; 1 0 ; 0.5 ; 1 0 ; 0.5 ; 1

To reduce the number of combinations and thus the numberof simulations to run, we eliminated some of the values (seeTable III), taking into account the properties of real-timemultiplayer games, from the further investigations based onthe following intuitions:

TABLE IIICONSIDERED COMBINATIONS OF THE PARAMETER WEIGHT FACTOR

VALUES

Comb. No. CPU Memory Battery Link Quality Position1 1 1 0 1 12 1 1 0 1 0.53 1 1 0 0.5 14 1 1 0 0.5 0.55 1 0.5 0 1 16 1 0.5 0 1 0.57 1 0.5 0 0.5 18 1 0.5 0 0.5 0.59 0.5 1 0 1 1

10 0.5 1 0 1 0.511 0.5 1 0 0.5 112 0.5 1 0 0.5 0.513 0.5 0.5 0 1 114 0.5 0.5 0 1 0.515 0.5 0.5 0 0.5 116 0.5 0.5 0 0.5 0.5

• CPU weight: Real-time applications, hence real-timemultiplayer games are usually processing intensive ser-vices. To avoid selecting weak nodes as zone servers, itis important to take into account the nodes’ processingpower in the node weight computation. Thus, we usedtwo values, such as normal and high, for the CPU weightfactor in our factorial design.

• Memory weight: The same arguments hold for thememory weight factor. So, we investigated two levels ofthis factor, like normal and high.

• Battery weight: The available battery level can be impor-tant for energy intensive or long-life services. However,ad hoc games do not have special energy requirementscomparing to other applications and they are usually shorttime games mainly to kill waiting or travelling time.Thus, we neglected this factor from our investigationsand assigned always the low weight level.

• Link Quality weight: Real-time multiplayer games havestrict QoS (Quality of Service) requirements towards theunderlying network [9] reflecting the importance of linkquality. Hence, we used again two values, normal andhigh, for this factor in our factorial design.

• Position weight: The creation of a small DS has theadvantage of reducing the inter server synchronization

delay and overhead traffic. Clearly, this can be achievedby selecting nodes with good network position into theDS. Thus, the position parameter is important to take intoaccount and we used the normal and high values of thisfactor in the investigations.

C. Simulation Settings

To select the best combination of the factor values for thegiven service, we did run simulations. In these simulations,we investigated 16 combinations (cf. Table III) and pickedthat combination as the service profile which had given thebest performance of the measured metrics.

We used the NS-2 network simulator and its wireless exten-sions [10] for the simulations. We applied the PBS algorithm tocompute and maintain the zone server set in the simulations.The node weights were computed by our NWC mechanismimplemented as an extension to PBS. Each mobile node shareda 2 Mbit/s radio channel with its neighboring nodes using thetwo-ray ground reflection model, IEEE 802.11 MAC protocoland AODV routing protocol [1]. We did run the simulationsusing the following scenario:

School Yard Scenario: We set the area of the school yardto 400x400 m2, the transmission range of every device to250 meters and the node density to 15 nodes from which 10nodes were participating in the game session in average. Themovements of the nodes were modelled by using the RWP(Random WayPoint) mobility model [1]. The speed of thenodes was uniformly distributed in the range of 0-6 km/h.

We had repeated every simulation 10 times using differentseed values then averaged the results and computed the 95%confidence interval of the average. We set the duration of thegame session, and thus the simulation time, to 900 seconds.The players’ game joining and leaving points in time were ran-domly distributed during the simulation. To simulate the gametraffic, we used the characteristics of the pseudo game servicewe specified above (cf. Section IV-A). We also generated somebackground traffic by 5 parallel connections being active atthe same time during the whole simulation between any tworandom nodes (consuming the same amount of energy as incase of the game service but not generating CPU and memoryload on the given node). Per connection, the sender produceda 5 kbit/s data flow for 30 seconds, then a new connectionwas established.

For computing the parameter values in NWC, besides theservice specification we have to specify also the node proper-ties. Thus, in the simulations we used nodes with 500 - 1000MHz CPU regardless the exact processor type, 256 or 512MByte memory and 1500 - 5000 mW battery capacity. Thevalues were randomly assigned to the nodes at the beginningof the simulations.

D. Simulation Results

The simulation results are depicted in Fig. 3. The figureshows the average values of the applied metrics and their 95%confidence interval in case of the investigated factor valuecombinations. To measure the performance of the differentcombinations, we used the following metrics:• Number of DS Nodes: This metric indicates the number

of dominator nodes in the computed DS. We always

Fig. 3. Simulation Results

observed a quite small DS, see Fig. 3, which can beexplained basically by the scenario properties. The bestperformance regarding this metric was produced by com-bination 5.

• Number of DS Changes: This metric measures thestability of the DS. It shows how often the initial DSneeds to be changed during the simulation from a globalviewpoint. Our simulation results showed a very stableDS performance (cf. Fig. 3). In most of the cases, only afew or no changes occurred during the whole simulation.Combination 13 produced the best performance with anaverage of 1.43 DS changes.

• Number of Anomalies: This metric counts how manytimes the available CPU, memory or battery capacity ofdominator nodes drops below a preset threshold value(10% in case of CPU and memory, 5% in case of battery)in global. If such a thing happens, an anomaly is gener-ated triggering a new DS selection round. Consideringour simulation results, again combination 13 showed thebest performance (cf. Fig. 3).

1) Determine the Service Profile: We used several metricsin the performance investigation of the different factor valuecombinations and obviously not always the same combinationshowed the best performance. Thus, the selection of thecombination appropriate for the given service is a trade-offbased on how important the various metrics are for the servicedeveloper. To be able to compare the different combinations,we used the multi-objective optimization technique [8].

This technique takes each objective function (metric) andmultiplies it by a weighting coefficient wi. The modifiedfunctions are then added together to obtain a single costfunction as given in (6):

f(x) =k∑

i=1

wifi(x), (6)

where 0 ≤ wi ≤ 1 and∑k

i=1 wi = 1. The objective functions,

i.e. fi()-s, must be optimized and the weighting coefficientsmust be determined before computing the cost value.

In our example, the objective functions represent the com-puted average values of the metrics and we set the weightingcoefficients according to Table IV.

TABLE IVWEIGHTING COEFFICIENTS OF THE USED METRICS

Metric WeightNumber of DS Nodes (NUMn) 2/10Number of DS Changes (NUMc) 5/10Number of Anomalies (NUMa) 3/10

After this, the cost value of the different combinations canbe computed in the following way:

f(cn) =2 ·NUMn(cn) + 5 ·NUMc(cn) + 3 ·NUMa(cn)

10,

(7)where cn represents the combination number. Note that beforethe cost value is computed all the metric values are normalized.This way the cost value of the different combinations can beeasily compared, and the combination with the lowest costvalue can be selected as the service profile.

Fig. 4. Cost Values

Fig. 4 depicts the cost values of the different combinationstogether with their 95% confidence interval.

We can see, that combination 13 has the lowest cost value.Thus, we can select the parameter weight values representedby combination 13 (cf. Table V) as the service profile of real-time multiplayer games.

TABLE VSERVICE PROFILE OF REAL-TIME MULTIPLAYER GAMES

Weight ofCPU Memory Battery Link Quality Position0.5 0.5 0 1 1

Note that the selected metrics to evaluate our factorialdesign were up to our choice and any other metrics couldhave been used also. This is true for the weighting coefficientassignments, too.

V. CONCLUSIONS AND FUTURE WORK

In this paper, we presented a mechanism called NWC (NodeWeight Computation) to calculate node weight in mobile adhoc networks. The node weight can be used to select dedicatednodes, like zone servers, in the network for managementpurposes.

Our NWC mechanism computes the node weight using arepresentative group of node parameters and a so-called ser-vice profile. The novelty of NWC is taking into account severalparameters in the weight computation and the technique tocreate the service profile applying factorial design and multi-objective optimization based on simulation. Moreover, NWCcan be used for node weight computation in MANETs also byother clustering algorithms.

However, the considered static/offline approach to create theservice profile does not make it possible to accurately predictthe future service context (e.g., network scenario, mobilitybehavior of the nodes) in advance where the given service willbe deployed. Thus, even knowing the basic characteristics ofthe service an optimal profile is not granted for every situation.This problem can be solved with a more complex, dynamicapproach which adapts continuously the service profile tothe actual service context. The development of this dynamicservice profile creation mechanism remains as a topic forfuture work.

ACKNOWLEDGEMENTS

This work was supported by the Informatics program ofERFARET and by IBM. And we would like to thank EduardoSilva the great work which gave the basis of this paper.

REFERENCES

[1] C. S. R. Murthy and B. S. Manoj, Ad Hoc Wireless Networks -Architectures and Protocols, C. E. Perkins, Ed., 2004.

[2] S. Riera, O. Wellnitz, and L. Wolf, “A Zone-based Gaming Architecturefor Ad-Hoc Networks,” in Proceedings of the Workshop on Network andSystem Support for Games (NetGames2003), Redwood City, USA, May2003.

[3] K. Farkas, F. Maurer, L. Ruf, and B. Plattner, “Dominating Set BasedSupport for Distributed Services in Mobile Ad Hoc Networks,” in Pro-ceedings of the 10th IEEE/IFIP Network Operations and ManagementSymposium (NOMS 2006), Vancouver, Canada, April 2006.

[4] D. J. Baker and A. Ephremides, “A Distributed Algorithm for OrganizingMobile Radio Telecommunication Networks,” in Proceedings of the 2ndInternational Conference in Distributed Computer Systems, 1981.

[5] M. Gerla and J. Tsai, “Multicluster, Mobile, Multimedia Radio Net-work,” ACM/Baltzer Journal of Wireless Networks, vol. 1, no. 3, pp.255–265, 1995.

[6] J. A. Shaikh, J. Solano, I. Stojmenovic, and J. Wu, “New Metricsfor Dominating Set Based Energy Efficient Activity Scheduling in AdHoc Networks,” in Proceedings of the 28th Annual IEEE InternationalConference on Local Computer Networks (LCN’03), 2003.

[7] M. Chatterjee, S. Das, and D. Turgut, “WCA: A Weighted ClusteringAlgorithm for Mobile Ad Hoc Networks,” Journal of Cluster Computing(Special Issue on Mobile Ad hoc Networks), vol. 5, pp. 193–204, 2002.

[8] R. Jain, The Art of Computer Systems Performance Analysis. NewYork: John Wiley and Sons, 1991.

[9] T. Henderson and S. Bhatti, “Networked Games: A QoS-SensitiveApplication for QoS-Insensitive Users,” in Proceedings of the ACM SIG-COMM workshop on Revisiting IP QoS, Karlsruhe, Germany, August2003.

[10] Information Sciences Institute ISI, “The Network Simulator ns-2,”February 2005, http://www.isi.edu/nsnam/ns/.