Mirage: a microeconomic resource allocation system for sensornet testbeds

In this paper, we argue that a microeconomic resource allocation scheme, specifically the combinatorial auction, is well suited to testbed resource management. To demonstrate this, we present the Mirage resource allocation system. In Mirage, testbed resources are allocated using a repeated combinatorial auction within a closed virtual currency environment. Users compete for testbed resources by submitting bids which specify resource combinations of interest in space/time (e.g., "any 32 MICA2 motes for 8 hours anytime in the next three days") along with a maximum value amount the user is willing to pay. A combinatorial auction is then periodically run to determine the winning bids based on supply and demand while maximizing aggregate utility delivered to users. We have implemented a fully functional and secure prototype of Mirage and have been operating it in daily use for approximately four months on Intel Research Berkeley's 148-mote sensornet testbed.


INTRODUCTION
SensorNet testbeds are critical for understanding and meeting the technical challenges of wireless SensorNets.Such testbeds provide a means for developing and evaluating SensorNet technology in a controlled and instrumented environment.A canonical testbed incorporates a collection of compute and sensing nodes that are coupled together by an out-of-band communication channel and a power supply.This channel provides for remote control, reprogramming and data collection independent of a node's wireless capabilities.The power supply eliminates the need to replace batteries, reducing the physical maintenance needs of the testbed.
As with any large-scale system, resource management becomes a key aspect of testbed operation.Frequently, the infrastructure of a large testbed represents a significant capital cost to build and operate.Thus, it becomes more economical to share the testbed among users.The wholesale allocation of an entire testbed's resources to a single application or user is not desirable and frequently unnecessary.A method for partitioning the testbed based on user requirements provides a more efficient means of operation.
Current schemes for testbed resource allocation suffer from key shortcomings, falling short of meeting real user demands on a large system.First, they either lack or have inadequate mechanisms for resolving contention among competing users during times of peak demand.This often requires direct system administrator intervention to resolve conflicts.Second, they provide limited mechanisms for expressing resources, making it difficult for users to express desired resources and their associated constraints.This, in turn, affects the efficient utilization of the underlying resources by limiting the system's ability to make intelligent allocations for multiple users.
We argue that microeconomic resource allocation using a combinatorial auction is well suited to address these issues of Sensor-Net testbed resource management.To demonstrate this, we have implemented the Mirage testbed management system.In Mirage, resources are allocated using a combinatorial auction [3,8].Users submit bids specifying resource combinations of interest in space/time (e.g., "any 32 MICA2 motes for 8 hours anytime in the next three days") along with a maximum value amount the user is willing to pay.A combinatorial auction is then periodically run to determine the winning bids based on supply and demand while aiming to maximize aggregate delivered utility.Given that testbed users are typically interested in collections of nodes and are often indifferent to different allocations (as long as they meet the user's constraints) and averse to partial allocations, we believe that a combinatorial auction provides a more effective means for testbed resource allocation compared to alternatives.
In this paper, we describe the motivation, design, and implementation of Mirage.We also present details on our experience to date with a Mirage deployment on a 148-mote SensorNet testbed at Intel Research Berkeley (IRB), where Mirage currently serves as the sole means of getting physical access to testbed resources.Given the desirability of testbeds for SensorNet development and the growing user community for such testbeds, our deployment serves as a nice "laboratory" for studying how beneficial microeconomic approaches to resource allocation are relative to all of the theoretical/algorithmic work that has gone on in this space in the past.Our primary technical contributions in this paper include: • The design and implementation of a microeconomic resource allocation system for SensorNet testbeds that is part of a fully functional and deployed system.While previous work has largely explored the theoretical and algorithmic nature of microeconomic-based systems or presented "paper designs" of such systems, we believe that experience with working prototypes and real-world deployments are fundamental to shaping the research agenda in this space.
• A practical virtual currency policy with two novel components: (i) proportional-share profit sharing, to allow idle users to accumulate transient credit and (ii) a savings tax, which implements a "use it or lose it" policy to address highly imbalanced usage patterns.While microeconomic resource allocation has been explored in previous work, the majority of these efforts have not addressed this issue, opting instead to focus on either specific subsets of microeconomic system design or assuming the use of real money.
• Experience with an ongoing real-world deployment of our system on a 148-mote SensorNet testbed.Early experience over a two-month period indicates that demand for testbed resources is bursty, that users place significantly different value on these resources, and points to evidence of strategic user behavior.Feedback from users has also validated some of our early intuition about features (e.g., the need for sets of motes that meet specific physical constraints) of the problem that make SensorNet resource allocation non-trivial and, guided by real user needs, has pointed to future research directions.
The rest of this paper is organized as follows.In Section 2, we provide background and motivation on the testbed resource allocation problem.In Section 3, we present the design of Mirage, a microeconomic resource allocation system aimed to address this problem.In Section 4, we describe our prototype implementation.In Section 5, we describe our experience to date with real usage on an ongoing Mirage deployment on a 148-mote SensorNet testbed at Intel Research Berkeley.In Section 6, we describe related work and finally, in Section 7, we conclude the paper and describe future work.

BACKGROUND AND MOTIVATION
The initial motivation for this work became apparent during the construction of a 148-node SensorNet testbed at the Intel Research laboratory in Berkeley, CA.This testbed is comprised of 97 Crossbow MICA2 and 51 Crossbow MICA2DOT series sensor nodes, or motes, mounted uniformly in the ceiling of the lab.The motes incorporate an Atmel ATmega128 8-bit microcontroller, 4KB of RAM, 128KB of flash memory, and a Chipcon CC1000 FSK radio chip.The MICA2 series devices in the testbed operate in the 433 MHz ISM band and incorporate a sophisticated sensorboard that can monitor pressure, temperature, light, and humidity.The MICA2DOT devices operate in the 916MHz ISM band and do not include sensorboards.
The motes are coupled to the lab's wired production network using the Crossbow MIB600 Ethernet programming board.This device is based on a design developed at Intel Research which provides power, remote programming and out-of-band monitoring/debugging though a TCP/IP over Ethernet channel.Power is provided to each mote via the MIB600 using IEEE 802.3af power over Ethernet and can be centrally controlled from the network switch.The capabilities of the MIB600 are useful for creating large testbeds with minimal infrastructure and upkeep requirements.When the testbed was placed in service, the demand for it's resources by several users was immediate, obviating the need for an effective management system.

The Case for Auction-based Resource Allocation
When contention for shared resources arises, a fundamental question is how to prioritize different users vying for access to common resources.Complicating matters further are tendencies for testbed system usage to be bursty and for users to have differential value on the resources being contended for (e.g., using resources for testing vs. using resources to perform a critical experiment leading up to a conference deadline).In Figure 1, we show testbed utilization for 97 MICA2 motes and 51 MICA2DOT motes on a 148-mote SensorNet testbed at Intel Research Berkeley over a period of two months.Examining the graphs, we see that demand for testbed resources is very bursty, with noticeable bursts in early December and also in early February near the SIGCOMM '05 conference deadline.Further, as described in Section 5, the value (as determined by an auction) that users placed on allocations over this two month period varied over three orders of magnitude, suggesting highly varying levels of immediacy and importance in testbed usage.
The observed usage characteristics of the testbed suggest two requirements for a resource allocation system.First, there needs to be a systematic way to prioritize resource requests and second, users should be able to express the importance of their requests to use the testbed.The first requirement is motivated by the fact that testbed usage is bursty and that contention is a real phenomena, often occurring at the most important of times.The second requirement is driven by the fact that user valuations for resources varies significantly (Section 5) and thus, computing an efficient (i.e., a socially optimal allocation in terms of aggregate delivered utility) allocation requires additional information.
These requirements point towards the use of an auction-based resource allocation system.Owing to its use as a bidding process, auctions are ideally suited for eliciting the widely varying valuations that testbed users have.The ability to express a valuation explicitly combined with the fact that users bid using finite currency addresses both of our requirements.When testbed demand is high, users with the highest valuations get priority (using currency that was accumulated by making judicious use of testbed resources during previous periods of contention).When users place varying levels of importance on their requests, they simply bid higher or lower as needed.Contrast this to other scheduling schemes such as firstcome first-serve (FCFS), fair-share, etc. which provide no means to explicitly express the importance of a request and thus, fundamentally operate with strictly less information, delivering less overall utility.

Combinatorics of SensorNet Testbed Allocation
Users of a SensorNet testbed are frequently interested in acquiring combinations of resources that simultaneously meet certain constraints.Consider a machine learning researcher interested in testing distributed inference algorithms in sensor networks.Such a user might be interested in evaluating algorithms at a moderate scale while performing inference over temperature and humidity readings of the environment.The user's code might also be tailored to a particular type of device (e.g., a MICA2 mote) and need to run on a different, appropriately-spaced frequency to avoid crosstalk from other experiments.Thus, the user's abstract resource specification might call for "any 64 MICA2 motes, operating on an unused frequency, that have both a temperature and a humidity sensor".
The resource combinations that users of a SensorNet testbed are interested in often have the property that there are both substitutes and complementaries.In the machine learning example above, for instance, the user is not concerned with the specific allocation of MICA2 motes as long as a total of 64 are available.Hence, MICA2 motes are substitutes for one another.Similarly, the user does care that 64 motes are allocated simultaneously.A partial allocation of, say, 8 motes would not meet the user's needs in this case since the user's intention was to test at a moderate scale.Thus, the 64 motes can be viewed as being complimentary to one another.
Resource allocation problems involving substitutes and complementaries are well-suited to a combinatorial auction.Users submit bids specifying desired resource combinations along with a maximum amount the user is willing to pay.The auction, in turn, computes a set of winning bids that maximizes total revenue.Since users use virtual currency to express value, the allocation that maximizes revenue collected maximizes the aggregate stated value delivered to users of the system.Given a sufficiently expressive bidding language, user preferences on both substitutes and complementaries can be captured and hence more efficient global allocations can be achieved using a combinatorial auction.In Mirage, we use a repeated combinatorial auction to periodically allocate testbed resources both in space and time.

MIRAGE
In this section, we present the design of Mirage, a microeconomic resource allocation system for SensorNet testbeds.We assume each user has a value associated with a desired resource allocation and the primary goal of the system is to maximize aggregate value.To maximize aggregate value, Mirage relies on a repeated combinatorial auction [3,8].In such an auction, users submit bids specifying resource combinations of interest and the amount of virtual currency the user is willing to pay.Periodically, the auction clears, a set of winning bids is computed, and trades are settled through payments to a central bank.In this section, we describe the three main components that make up Mirage: the resource discovery service, the repeated combinatorial auction, and the central bank.

Resource Discovery
In Mirage, users specify the type of resources they are interested in using abstract resource specifications.A resource discovery service then maps these specifications to concrete resource sets that meet the desired constraints.We use this level of indirection for three reasons.First, it frees the user from having to manually identify candidate resources.Second, it allows users to automatically take advantage of new resources as they are introduced into the system.Finally, testbed users frequently wish to acquire sets of nodes but are indifferent to the specific nodes allocated as long as they meet user constraints.The resource discovery service allows users to discover all possible candidates and thus provide the system with the maximal amount of information on substitutes when clearing the auction.
Abstract resource specifications allow users to specify constraints on the types of resources they seek to acquire.For example, testbed users often need to specify constraints on per-node attributes.In other cases, constraints on inter-node attributes may be necessary.For example, a user might wish to acquire "8 motes where each pair of motes is at least 10 meters apart" to ensure that communication requires a multi-hop routing layer.Currently, our prototype supports resource discovery using per-node attributes including mote type, sensor board type, and supported frequency range.We are currently investigating how best to incorporate constraints on internode attributes into the system.

Repeated Combinatorial Auction
Mirage uses a first-price, repeated combinatorial auction to allocate resources to competing users over time.In this setting, an auction is run periodically.During each round, there are multiple buyers (the competing users) and a single seller who sells resources on the system's behalf.All bids submitted prior to the start of a round are considered.The auction will then calculate winning bids, their payments, and associated resource allocations.
Users submit bids to the auction using a two-phase process (Figure 2).First, they use the resource discovery service to find candidate nodes that meet their constraints.Second, using concrete nodes identified from the first step, they place bids in the auction using the Mirage bidding language.
Since time is a critical aspect of resource allocation (e.g., resources near a conference deadline), resource combinations specify resources in both space and time.Formally, a bid bi in Mirage is specified as follows: 1. 1.

Fig. 2. Bidding and Acquiring Resources.
bi = (vi, si, ti, di, fmin, fmax, ni, oki) Bid bi indicates the user wants any combination of ni motes from the set oki (obtained through resource discovery) for a duration of di hours, a start time anywhere between si and ti, and a frequency in the range [fmin, fmax].The user also is willing to pay up to vi units of virtual currency for these resources.Continuing with the distributed inference example, a user thus might say: "any 64 MICA2 motes, which have both a temperature and a humidity sensor, operating on an unused frequency in the range [423 MHz, 443 MHz], for 4 consecutive hours anytime in the next 24 hours".Suppose the user used the resource discovery service and found 128 motes meeting the desired resource specification and valued the allocation at 99 units of virtual currency.The corresponding bid in this case would thus be: bi = (99, 0, 20, 4, 423, 443, 64, list of 128 motes) (2) The goal of the system in each round is to clear the auction such that the winning bids maximize the amount of revenue collected by the system.Since users use currency to express value, the allocation that maximizes revenue maximizes the aggregate delivered value and thus can be viewed as being socially optimal.This problem of computing a revenue-maximizing allocation in a combinatorial auction is known as the winner determination problem and is known to be NP-hard by reduction from weighted set packing [11].Thus, in our prototype, we currently use a greedy heuristic to compute the set of winning bids.We are also currently investigating a mixed-integer program formulation using CPLEX, a commercial, linear-programming based, branch-and-cut solver for mixed integer programs.

Central Bank
Mirage supports virtual currency, because charging real currency in our environment is impractical.To support virtual currency, Mirage relies on a central bank to enforce currency policy.A good virtual currency policy is instrumental in controlling the aggregate amount and flow of virtual currency in the system, and to encourage desirable behaviors, while discouraging undesirable ones.The lack of proper policies can render the system useless.For example, if users can obtain large amounts of virtual currency easily, then they will bid arbitrarily high values at all times.Such a system reduces to resource allocation based on social conventions since there is no disincentive for a user to not always bid the maximum possible value.
Mirage is a closed economic system and users have no way to earn currency.Thus, the system must decide how to distribute virtual currency.Because users enter the system with no virtual currency, we must bootstrap users into the system by providing them with some amount of initial currency.In addition, as users spend currency over time, we also need a way to infuse their accounts with new currency.Clearly, there are many currency polices to meet these requirements and different policies will result in different economic systems and resource allocations.
Our virtual currency policy is based on two principles: (i) prioritizing users based on type of usage and (ii) penalizing/rewarding users based on usage during times of peak demand.Prioritizing based on type of usage (e.g., research vs. coursework) is a reasonable strategy lacking other metrics to differentiate users.In addition, it seems natural to reward the user who refrains from using the system during times of peak demand (or, more generally, does not waste resources) and penalize the user who uses resources aggressively when resources are most scarce.In Mirage, each user is associated with a project that has an account at the central bank.Each project's bank account is assigned a baseline amount of currency based on priority, and a number of currency shares which influence the rate that currency flows into the account.Given initial currency, users can bid for resources in the auction.Each time the auction clears, bids are settled and revenue is collected from the accounts for winning bids.This currency is then distributed back to all accounts through profit sharing in a proportional-share fashion based on the number of shares in each account (Figure 3).It is this profit sharing policy that allows users who do not waste resources to save additional currency which can be used for a subsequent burst of activity.
In addition to profit sharing, the system also imposes a fixed rate savings tax on all accounts that have excess currency above their baseline values, again with proportional-share distribution.The motivation for the savings tax is based on expected resource consumption.For example, in other distributed systems testbeds such as PlanetLab [9], it has been observed [1] that resource consumption is often highly imbalanced with a small fraction of users consum-ing the majority of the resources and many users often going idle for long periods of time.Given similar resource patterns here and in the absence of additional policy, the implication would be that heavy users would eventually be working out of accounts with very little currency even if there is low demand for testbed resources.To mitigate this effect, we thus impose a fixed rate savings tax (the "use it or lose it" policy).The basic idea here is that users should be rewarded for not wasting resources but that such a reward should not last forever.In the absence of any activity in the system, the savings tax works such that all accounts eventually converge back to their baseline values.

IMPLEMENTATION
We have implemented a prototype of Mirage and have been operating it daily for approximately two months on Intel Research Berkeley's 148-mote SensorNet testbed.The implementation is comprised of three types of components: clients, a server, and a front-end machine that provides controlled physical access to the testbed (Figure 4).Clients provide users with secure, authenticated command-line (the mirage program) and web-based access to a server (miraged) which implements a logical combinatorial auction, bank, and resource discovery service.The server accepts secure, authenticated XML-RPC requests using the SSL protocol with persistent state stored in a PostgreSQL database.Lastly, the frontend physically enforces resource allocations from the auction using Linux's per-uid iptables packet filtering capabilities.By default, all users are denied access to all motes.Based on the outcome of the auction, rules are added as needed to open access to users of winning bids for specific periods of time.Several variables parameterize the auction: the number of resource slots, resource slot size, and acceptable bid durations.Our initial parameterization is based on expectations of user desires but will likely evolve.Access to the testbed is based on 1-hour slots.To accommodate users who require a range of different time slots, users may bid for 1, 2, 4, 8, 16, or 32 hour duration blocks.To allow users to plan ahead, the auction sells resources up to three days in advance.Given our 1-hour slot size, this works out to a total of 72 slots.Thus, we can view the resources being allocated as a matrix of 148 motes by 72 slots.When the system boots, all slots are available.Over time, slots become occupied as bids are allocated and new slots become available as the window of slots opens up over time.
To use the system, users register for an account at a secure web site by providing identifying information, contact information, a project name, and by uploading an SSH public key.Each user is associated with a project and each project has an owner.An administrative user is responsible for enabling accounts for project owners and assigning each project a baseline virtual currency value and a number of virtual currency shares.Project owners can subsequently enable their own users, thereby eliminating the administrative user as a centralized bottleneck.
Once enabled, users can securely bid in the auction using either the command-line tool mirage or through the web interface, where PHP scripts on the backend act as XML-RPC/SSL clients to the miraged server.The command-line tool provides access to the entire RPC interface exposed by miraged.Use of this program is useful for scripting and automation.To accommodate users who prefer a graphical interface, the web-based interface provides a simple, integrated interface where users specify what resources they want and how much they are willing to pay using an HTML form.The web server, in turn, maps the user's abstract resources to concrete resources using the resource discovery service and places a bid in the auction on the user's behalf.
For winning bids, Mirage provides access to the associated set of motes for the associated amount of time to project members of the winning bid.Mirage provides physical access to each user by: (i) creating a temporary Unix login on the front-end machine using a global username (the base32-encoded MD5 hash of the user's SSH public key), (ii) enabling access to the front-end via SSH authentication using an SSH authorized keys file, and (iii) setting up firewall rules on the front-end such that only the user can access the particular motes assigned to the winning bid.

USAGE AND EXPERIENCE
We have been operating Mirage on the Intel Berkeley Lab's 148mote SensorNet testbed for approximately two months now.As of February 2005, users from 11 different research projects have registered to use the system and 51 bids have been submitted resulting in a total of 44783 allocated node hours.While our experience to date is still preliminary given the length of time the system has been in operation, measurements of system usage thus far point to three findings: (i) demand for testbed resources is bursty (Figure 1), (ii) users place significantly different value on resources, varying over three orders of magnitude, and (iii) there is evidence suggesting that some users are behaving strategically.These characteristics point toward the applicability of an auction for resource allocation in SensorNet testbeds.
In Figure 5, we show the cumulative distribution function (CDF) of bid values per node hour for all bids submitted to the system.A bid's value per node hour is computed as follows: if a bid has value v and requires n nodes for h hours, then that bid's value per node hour is v/nh.From the graph, we observe that users place significantly different value on testbed resources, varying over three orders of magnitude from a value of 0.000332 per node hour to a value of 1 per node hour, a factor of 3012 difference.We also see that these widely varying valuations are distributed relatively  evenly across each order of magnitude, suggesting that this range is not due to a few anomalous bids but rather to a wide range of underlying user valuations for testbed resources.These two observations support the use of auctions, which are designed precisely to elicit such widely varying valuations to compute an efficient allocation.
In Table 1, we show aggregate node hours consumed by each of the active projects using the system.The data indicates that system usage varies widely across projects.For example, in terms of aggregate node hours, the snetrouting project has consumed approximately half of all node hours in the system.In contrast, the nucleus and ucd projects combined have consumed just 1.19% of total allocated node hours.Given the bursty demand for system resources shown early in Figure 1, this data motivates the need for tracking consumption and for weighting such consumption by the pain it imposes on other users.For example, when contention is high, it would seem natural that snetrouting, given its previous consumption, would have a lower probability of acquiring testbed resources than, say, ucd.On the other hand, if most of snetrouting's consumption occurred when the system was idle, then its associated consumption penalty should be reduced accordingly given that the resources would have gone unused otherwise.Again, these properties are ones that are well suited for an auctionbased resource allocation system.
Figures 6 and 7 show CDFs for the number of nodes users requested and the lengths of time (in hours) they requested those nodes for.From the nodes CDF, we see that approximately 30% of the bids requested 16 nodes or less, resources that were likely related to development and debugging.On the high end, we see two noticeable spikes, one at 51 nodes and another at 94 nodes, corresponding to the 51 MICA2DOT nodes and 97 MICA2 nodes in the testbed.Turning to the time durations CDF, we find that approximately half the bids requested allocations of 8 hours or more.At the same time, we also see that more than 20% of the bids required 4 hours or less with the 2 hour point going completely unused.All of the above suggests that flexible sharing in both space and time of a SensorNet testbed is necessary.
Early system measurements also suggest that some users are behaving strategically rather than simply bidding their true value for desired resources.As one example, we found one user who almost always bids 1 for any amount of node hours requested but modifies his bidding strategy accordingly when competition (i.e., other active/recent bids) is observed on the system.Should this trend continue over time, this would suggest that it should be expected that users will try to game the system and that the system should be designed to handle this in an appropriate manner.
Luckily, in the case of Mirage, the above bidding strategy has essentially no effect on other users.The reason is that if a lowball bid wins the auction, then this implies that the other bids expressed even lower value for the resources being allocated.The opportunity cost of awarding the resources to the lowball bid is consequently low.In contrast, if a lowball bid competes with high value bids from users with pressing resource needs, then the fact that the user underbid does not affect other users.Since the auction optimizes for aggregate revenue, the high value bids will win and resources will be allocated accordingly.The only effect that a lowball bidding strategy really has is that it increases the overhead in the bidding process for users who attempt to game the system by underbidding, since such users then need to incrementally increase their bids (up to their true value) in response to other bids.
Finally, informal feedback from users has suggested that a resource allocation system based on a combinatorial auction is not hard to use given the simple web interface that Mirage provides.The main problems users have experienced have mainly concerned mechanics of logging into the front-end and a hardware failure that caused an outage for several days in mid-January.Additional user feedback has also involved requests for new features in the system, some of which present new research challenges.Notable requests include: (i) "buy-it-now" prices that allow resources to be acquired without having to wait for the auction to clear, (ii) bidding for resources that meet certain physical constraints, and (iii) bidding for an identical set of resources for repeatability.The last of these requests is relatively easy to support in the context of the current testbed model, while the first two will require augmenting the interface to Mirage and developing new algorithms.

RELATED WORK
Originally, the lab's SensorNet testbed used the Motelab scheduling and management system [15] for testbed resource allocation.Motelab provides a simple scheduling mechanism via a web-based interface and includes automated reprogramming and data collection capabilities.Resource requests are expressed by having users select time slot(s) from a master schedule in a first-come first-serve (FCFS) fashion and a simple time-based quota scheme is used to regulate equitable use of the testbed schedule amongst active users.As mentioned in Section 2.1, FCFS scheduling suffers from fundamental limitations that make it difficult to resolve resource contention in an efficient manner.In addition, since users request physical resources (as opposed to abstract resources specifying desired constraints) in Motelab, this further reduces opportunities for resource allocation optimizations when users are indifferent to multiple potential allocations.In our view, Motelab's primary strength is its automated reprogramming and data collection capabilities and such mechanisms are entirely complementary to Mirage.
There are a number of existing approaches to resource allocation in computing systems.Proportional-share scheduling is an approach commonly used to provide equal access to time-shared resources.This approach provides users easy access to all resources since it determines allocations using a well-defined metric.How-ever, it does not seem appropriate for a shared testbed, and in particular, for a system in which over-demand for resources can be a common occurrence.For example, as demand for resources during these periods increases, the time-share per resource received by each user decreases, thereby lowering the utility delivered by the system to the user.A resource allocation system should be able to manage allocations during times of light and heavy resource contention.
Batch scheduling is a commonly used approach used to schedule jobs in supercomputers and grid computing environments.These systems aim to schedule jobs in a way that optimizes system-level metrics such as total throughput or average job-turnaround time.However, these systems do not take into account user preferences in scheduling jobs.For example, such batch scheduling systems cannot distinguish between jobs that users require a timely completion and jobs that do not.In order to maximize the utility a system delivers to end-users, the system needs to elicit users' preferences for resources over time and space and seek to optimize user-level metrics.[6].
A number of previous efforts have explored market-based approaches for resource allocation in computer systems.The earliest work that we are aware of is a futures market for CPU time on Harvard's PDP-1 [13].Subsequent work has been largely dominated by auction-based schemes and been applied to resource allocation in a broad range of distributed systems including clusters [2,14], computational Grids [5,16], parallel computers [12], and Internet computing systems [7,10].As with these systems, Mirage also relies on an auction to allocate resources.A key distinguishing feature of Mirage, however, is its use of a combinatorial auction where users bid on bundles of resources as opposed to individual nodes.This ability to bid on resource combinations in space and time allows users to more accurately express their preferences on the distributed resources they seek to acquire.Such an ability we believe is highly desirable in a setting like SensorNet testbed allocation where users are typically interested in getting access to collections of nodes simultaneously.

CONCLUSION AND FUTURE WORK
Looking forward, we believe that microeconomic resource allocation using combinatorial auctions is well suited for large, shared SensorNet testbeds.We have explored this concept through Mirage, a microeconomic resource allocation system for SensorNet testbeds.The primary goal of Mirage is to allocate testbed resources to competing users in a maximally efficient manner in terms of aggregate utility delivered to users.To accomplish this, Mirage uses a repeated combinatorial auction.Users submit bids which express desired resource combinations in space/time along with a maximum amount the user is willing to pay in units of virtual currency.A combinatorial auction then determines an efficient set of winning bids and subsequently provides users with controlled physical access to the relevant nodes.To address practical issues pertaining to expected testbed usage and the fact that Mirage is a closed economic system, Mirage employs a virtual currency policy based on baseline virtual currency amounts, profit sharing, and a savings tax.The end result of this policy is that users can be prioritized based on type of usage and users are penalized/rewarded based on usage or lack of usage during times of peak demand.Our Mirage prototype has been deployed on a 148-mote SensorNet testbed and currently serves as the sole means of getting access to the testbed in nearly two months of ongoing operation.Early experience with real usage indicates that demand for testbed resources is bursty, that users place significantly different value on these resources (varying over three orders of magnitude), and points to evidence of strategic user behavior.
We acknowledge that there are still many open questions surrounding auctions for resource allocation.While an auction may provide the highest aggregate utility, it leaves to question whether it produces the most socially optimal allocation.For SensorNet testbeds, users may also wish to adhere to etiquette that is not necessarily captured in to the auction process.For example, this might involve giving preferential access to groups of users based on seniority irrespective of the the perceived monetary value.Another question concerns whether users will actually express the true value of their bid.As discussed, we have witnessed some users employing strategies to bid minimal amounts for their allocations.Further investigation of different bidding schemes is needed to minimize pathologic gaming of the system.Related to bidding, another open issue is whether Mirage's current bidding language is expressive enough to capture the full range of resource requests that users would like to make.Assuming extensions are needed, as initial feedback has suggested, another question is whether efficient algorithms can be designed to produce high quality allocations while simultaneously clearing the auction in a timely manner.Finally, while Mirage's current virtual currency policy provides mechanisms that we believe will be effective in practice, further investigation with real workloads over a longer period of time is still needed for proper tuning and evaluation.
To address such limitations, future work on this project revolves around three primary areas.First, we intend to continue to operate Mirage and gather further experience with real users and usage over an extended time period.Based on measurement and user feedback, we intend to obtain further insights on the issues associated with making a real economic-based resource allocation system work in practice and to quantify how well the system performs over time with a real workload.Lessons learned might then be used to focus both theoretical and systems work on the most germane areas (e.g., combinatorial resource allocation with inter-node constraints).Second, we are working with other research groups that operate Sensor-Net testbeds elsewhere in the world on gathering user requirements and, in one case, deploying Mirage on their local testbed.Third, we are also investigating how to extend this work to build an open economy of federated SensorNet testbeds where each testbed has its own combinatorial auction for local resources, its own virtual currency, and testbeds trade foreign currencies using either transitive bartering [4] and/or a virtual currency exchange to access remote resources.The primary benefits of having such a federation include: access to resources not available locally (e.g., different types of motes and/or sensors), access to idle remote resources when local resources are under contention, and enabling open trading of resource rights among participants.