Here we outline the three main approaches to providing wsn testbeds. our notion of
VTBs allows users to arbitrarily combine elements of all three (see the figure here).
Physical testbeds (such as those described in chun et al., 4 dutta et al., 11 ertin et al., 13
Handziski et al., 18 Tutornet, 12 and werner-allen et al. 34) excel at high-fidelity evaluation
of mature wsn designs, as well as detailed planning for real-world deployments.
However, physical testbeds for wsn systems tend to be small in scale, expensive to
maintain, and time-consuming to set up. They also typically lack flexibility, often
offering only a single, fixed, connectivity topology and limited heterogeneity (such as
only a single type of sensor node, radio, operating system, or programming language).
They also tend to be limited in their programmability at lower levels of the system; for
example, many use fixed operating systems and networking stacks. They are also often
unsuited to experimentation scenarios requiring repeatability of experiments, as many
relevant operating parameters are beyond user control (such as local radio interference
due to infrastructure and other experiments).
Physical Testbeds vs.
Simulation vs. Emulation
three-cornered testbed design space for
problematic in traditional network environments, where simulators (such as NS-221) are
prominent, they represent significant drawbacks in wsn environments where resource
scarcity and incidental physical characteristics are of the essence. simulation alone is
therefore of limited use in planning for real-world wsn systems and deployments.
emulation (such as described in Girod et al. 16 and wu et al. 36) is situated between
physical reality and simulation. whereas simulation abstractly models target systems,
emulation duplicates the functionality of one system in terms of another system and
is therefore capable of much greater fidelity than simulation while potentially offering
greater flexibility than a purely physical testbed. emulation is a much less exploited
approach in the wsn testbed context despite much potential; for example, emulation
in the form of network overlay technology could be used to support different inter-node
connectivity patterns in a physical testbed. alternatively, a battery-based power supply
on a physical node could be emulated by interposing a mains electricity-powered
hardware module degrading power over time.
simulation (such as described in
fekete et al. 14 and Levis et al. 22) is useful
for quickly trying out new ideas and for
investigating the behavior of new protocols
and mechanisms in varied topologies at
large scale and in a repeatable manner.
The most notable drawback is a lack of
fidelity, often making it unrealistic to
simulate fully at the instruction-execution
level and with high-fidelity radio or
while such limitations are not necessarily
Simulation Physical Reality
tal system to real-world deployment.
Finally, all these projects were small in
scale and therefore of limited application in the development of large-scale
Turning now to work that applies
the federation concept to physical WSN
testbeds,a Ohio State University17 com-
bined the infrastructure and software
of the Kansei testbed with the GENI
facility to provide a unified solution;
the Senslab project30 aimed to unify
four discrete heterogeneous testbeds
into a single testbed of 1,000 nodes;
and Cooperating Objects Network Of
Excellence (CONET) 6 employed a REST
API to provide uniform Web-based ac-
cess to different testbeds. These ef-
forts highlight the promise of testbed
federation in pursuit of scalability, but
none support integration of simulated
and emulated elements or deliver the
transparency of federation offered by
our VTB abstraction.
a The concept of a federated testbed is not new;
projects (such as PlanetLab and Panlab) have
long applied similar ideas, though not in a
VTBs provide the abstraction of a
user-designed private WSN testbed
in which some testbed elements are
physical, some are simulated, and oth-
ers are emulated. Users design their
VTB in such a way that its mix of physi-
cality, simulation, and emulation is
appropriate to their goals. They then
instantiate their VTB, deploy their
software onto it, and observe the out-
puts and behavior of their experimen-
tal systems as if they were running on a
dedicated physical testbed.