Wireless Sensor Network, 2009, 1, 324-333
doi:10.4236/wsn.2009.14040 Published Online November 2009 (http://www.scirp.org/journal/wsn).
H-TOSSIM: Extending TOSSIM with Physical Nodes*
Wenjun LI1, Xiaobin ZHANG2, Weihua TAN2, Xiaocong ZHOU2
1School of Software, Sun Yat-sen University, Guangzhou, Ch ina
2School of Info rmat ion Science and Techn ology, Sun Yat-sen University, Gua ngz hou, China
Abstract
As the development of Wireless Sensor Network (WSN), software testing for WSN-based applications be-
comes more and more important. Simulation testing is an important approach to WSN-based software testing,
and TOSSIM is the most widely used simulation testing tool targeted at TinyOS which is the most popular
operating system nowadays. However, simulation testing tools such as TOSSIM can not reveal program er-
rors about communication detail or timing, and lack accurate power consumption model and even can not
support power consumption estimation. In this paper, a hybrid testbed H-TOSSIM is proposed, which ex-
tends TOSSIM with physical nodes. H-TOSSIM uses three physical nodes, of which, one shares the simu-
lated environment with all virtual nodes to test the WSN program, and the other two bridge the real world
and the simulated environment. H-TOSSIM combines the advantages of both the simulation in physical node
and the simulation testing tools in WSN software testing. Through experiments, we show that H-TOSSIM
really reveals program errors which the pure simulation testing can not capture, and can support power con-
sumption estimation for large WSN with high accuracy and low hardware cost.
Keywords: Wireless Sensor Network, Sink, Principal Node, Superior Node, Network Lifetime
1. Introduction
1.1. Background
Recent advances in electronic technology and the need of
practical applications enable the rapid development of
Wireless Sensor Network (WSN), which consists of
many resource-limited sensor nodes, and can monitor the
phenomena in the physical world. WSN can be applied
in military surveillance, environmental monitoring,
health diagnostics, home automation, etc [1]. One of the
primary challenges in the researches on WSN is software
testing. A sensor network is self-configuration, and its
nodes are low-power embedded devices, which make its
software testing challenging.
Simulation testing and hardware-in-the-loop (HIL)
testing are the main approaches to W SN software testing.
There exist many simulation tools for sensor networks.
In simulation testing, the sensor network environment is
simulated through pure PC software, which is controlla-
ble, convenient and low-cost. HIL testing is one kind of
important means for embedded software testing. Com-
monly, HIL testing tools for WSN consist of dozens of
physical sensor nodes. In HIL testing, the program under
test runs in the physical sensor nodes with some assistant
middleware. Compared with simulation testing, HIL
testing can reveal more defects; however, it is high-cost
and not so convenient.
TOSSIM [2–4] is one of the most widely used simu-
lators for WSN, which is designed for TinyOS [5–7]
programs. TinyOS is the most popular operating system
for WSN nowadays, which supports almost all popular
sensor nodes; and its latest release is TinyOS 2.x, which
is corresponding to TOSSIM 2.x. In this paper, only
TOSSIM 2.x instead of TOSSIM 1.x is considered.
TinyOS is component-based and event-driven, and
TOSSIM simulates the sensor network through r eplacing
some low-level components and introducing a discrete
event queue. As a TinyOS WSN simulator, TOSSIM is
accurate and scalable. With its help, developer can test
the program before TinyOS application is deployed.
1.2. Motivation
Simulation testing tools such as TOSSIM have some
problems in WSN software testing. Firstly, they are dif-
ficult to reveal program defects and faults related with
communication details or timing. Secondly, they are hard
*Supported by the National Natural Science Foundationof China
under Grant No. 60673050.

W. J. LI ET AL 325
to include an accurate power consumption model. And
these problems are mainly caused by pure software
simulation.
Taking TOSSIM as the representative, it has the fol-
lowing defects and inadequacy. The first is that TOSSIM
can not reveal length setting error of message sending . In
a TinyOS program, message sending is a common opera-
tion, and when sending a message, its length must be set
correctly. However, even if the length of a message is set
to be less than its intended size, TOSSIM can not reveal
this fault when testing the program. Yet exceptions will
occur for such program to run in the physical sensor
network because messages will be partly lost.
The second is that TOSSIM can not reveal task calcu-
lation overload problem. Task is a deferred procedure
call in TinyOS, which is used to complete some calcula-
tion. For example, a TinyOS program sends a message
every 100 ms, and posts a task which includes 200 thou-
sands multiplication before each sending. In the simula-
tion testing of TOSSIM, such program works fine.
However, when running in the physical sensor network,
the task calculation overload problem will occur: the
number of messages a node sends per second is much
less than the expectation (about 10 messages, in this
case).
There is also an inadequacy in TOSSIM; it does not
support the power consumption estimation of sensor
nodes, which is an important issue in WSN software
testing because most sensor nodes are power-limited.
Though PowerTOSSIM [8], a pure software extension to
TOSSIM, can estimate the power consumption of sensor
node, yet it is not so accurate and supports only one kind
of sensor node. HIL testing can also estimate the power
consumption of sensor nodes through digital multimeter;
however, its hardware cost is too high because it needs
dozens of physical sensor nodes.The problems existing
in the simulation testing tools such as TOSSIM impede
the comprehensive testing for WSN software, which may
increase the cost of the application development. And
these problems are difficult to solve by pure software
extension.
2. Related Work
There exist many testing tools dedicated to WSN soft-
ware testing. In the following discussion, ns-2 [9], Sen-
sorSim [10], EmTOS [11], PowerTOSSIM, AMETU [12]
and avrora [13] belong to simulation testing tools; TO-
SHILT [14], MoteLab [15] and DSN [16] belong to HIL
testbed.
Ns-2 is a universal network simulator which has been
popular for many years. SensorSim is an extension to
ns-2, which integrates some WSN features. Both ns-2
and SensorSim can not support TinyOS program di-
rectly.
EmTOS is an extension to EmSim [17] which is de-
signed for EmStar [17], another WSN operating system.
EmTOS can simulate heterogeneous WSN, which sup-
ports both EmStar and TinyOS programs. PowerTOS-
SIM is an extension to TOSSIM, and sup ports the power
consumption estimation of the node; however, its error
rate can be up to 13% and it supports only one kind of
sensor node.
AMETU and avrora are both fine-grained TinyOS
program simulators, and they both simulate the WSN in
instruction level. The differences between them are
mainly the synchronization strategy for different nodes.
Because of the simplification of the network layer,
these simulators are difficult to reveal program faults
related to communication details. And they also can not
reveal program faults related to timing since they do not
model the practical capability of sensor nodes.
TOSHILT, MoteLab, and DSN are HIL testbeds, all of
which consist of dozens of physical sensor nodes. The
differences of them are mainly the connection type be-
tween sensor nodes and the console. All of them can re-
veal more faults than simulation testing; however, their
hardware cost is too high and they are not convenient
when testin g WS N programs.
3. Proposed Solution
As discussed above, pure software extension is not the
solution to solve the problems existing in simulation
testing tools such as TOSSIM. Instead, physical nodes
are considered here because they are the target platforms
for WSN software and may capture more problems. So,
the solution which combines the physical nodes and the
simulated environment is proposed in this paper. This
solution is called H-TOSSIM, which extends TOSSIM
with physical nodes. In H-TOSSIM, not all TinyOS pro-
grams run in the physical nodes, because that costs too
much and is inconvenient. H-TOSSIM is a hybrid testbed.
In fact, there will be just only one physical node in the
Physical node Virtual node
Figure 1. An example of the tested WSN topology in
H-TOSSIM.
C
opyright © 2009 SciRes. WSN

326 W. J. LI ET AL
tested WSN topology of H-TOSSIM, and others are all
virtual nodes. The only physical node can be configured
to be a neighbor of any virtual node. As shown in Figure
1, in H-TOSSIM, one physical node interacts with other
virtual nodes so as to test the TinyOS program, and all
nodes run the same program. So the potential faults
which pure simulation testing tools can not reveal will be
captured through the interaction between the physical
node and other virtual nodes. Another advantage of
H-TOSSIM is that the power consumption of a node in a
large WSN can be estimated through digital multimeter
with low hardware cost.
In H-TOSSIM testbed, the physical node runs in the
real world, and the virtual nodes run in the simulated
environment of PC, so two extra physical nodes are
needed as dual base stations to bridge the physical node
and the virtual nodes. It means that H-TOSSIM totally
needs three physical nodes.
4. Design of H-TOSSIM
4.1. Overview of the Architecture
Figure 2 shows the overview of the architecture of
H-TOSSIM, which consists of a PN, a pair of DBS, two
SFs, an MTTS, an ESECT and a GNB. PN is a physical
sensor node which runs the TinyOS application under
test. DBS consists of two base stations, which bridges the
PN and the PC side of H-TOSSIM. SF is a tool provided
by TinyOS to support serial communication, of which,
one end connects the serial port and communicates with
one of the DBS, and the other end may communicate
with any PC program through socket. MTTS provides
the services of messages transformation and transfer, and
its both ends are separately two SFs and ESECT. ESECT
is an extension to TOSSIM which aims to implement the
Figure 2. The architecture of H-TOSSIM.
synchronized execution and communication for the vir-
tual nodes with the only physical node. ESECT includes
five parts: the modification of TOSSIM, a driver, a re-
ceiver, a sender, and a GNB sender. GNB is a graphical
network browser, which displays the network interaction
situation in a GUI (Graphical User Interface).
In the following of this section, DBS, MTTS, ESECT
and GNB will be introduced in detail. PN will be referred
in the design of DBS. And since SF is a tool from
TinyOS, it is discussed briefly in the design of MTTS.
4.2. DBS
DBS is mainly used to tran sfer the messages between PN
and the serial communication. Herein, we first explain
why DBS but not single BS is used. There are two rea-
sons. The first reason is to make messages sending from
the virtual nodes to PN become concurrent. In
H-TOSSIM, PN may have several virtual neighbors;
however, all messages sent from the virtual nodes to PN
are serialized in ESECT. Yet if we want to finds out
more program faults through PN, we should test the case
that PN receives messages concurrently. So DBS is
adopted. With DBS, messages sent in high rate from the
virtual nodes will be forwarded to each of the DBS al-
ternatively, which will bring concurrency because of the
relatively low-speed DBS.
The second reason is that wireless radio rate is ap-
proximately as twice as serial rate. There are many kinds
of physical sensor nodes, and the radio rates of some of
them can be up to 250 Kbps [18,19]. However, the BS
connects with the PC through serial communication, of
which the rate is just up to 115 Kbps. When PN sends
messages in a high rate, there will be blocking between
the BS and PC if only one single BS is us ed. That is why
DBS is used in H-TOSSIM. With DBS, the transfer rate
between PN and PC can be up to 230 Kbps, which is
high enough because the serial messages are usually
shorter than the corresponding radio messages.
DBS physically consists of two BS’s; however, it is
not the simple combination of two BS’s in software.
The main differences between DBS and BS are re-
flected on the direction from PN to PC. In the direction
from PC to PN, each of the DBS transfers every mes-
sage received from serial to radio. However, in the
other direction, each of the DBS only transfers half of
the messages it receives from PN, and drops every
message from the other BS. In order to make each of
the DBS transfer half of the messages from PN, every
mess age sen t from PN is flagged to designate which of
the DBS should deal with it. In H-TOSSIM, the source
field of the message is chosen as the location of the
flag because it can be retrieved in ESECT. The work of
flag setting is done by a modified low component of
TinyOS in PN, and the tested.

W. J. LI ET AL 327
Figure 3. Threads relations of MTTS.
application does not need any modification. In fact, DBS
should also deal with message format transformation
between radio messages and serial messages; however, it
is rather trivial with the help of TinyOS components.
4.3. MTTS
MTTS connects two SFs with ESECT. An SF communi-
cates with a BS through a serial port in one end, and pro-
vides a socket server in the other end. MTTS connects to
two SFs as a client and provides a socket server for
ESECT. Figure 3 shows the threads composition of
MTTS.
In one end of MTTS, there are two SF receivers which
will get SF messages from two SFs and put them into the
buffer for SF-to-TOSSIM direction, and there is also an
SF sender which handles with sending messages from
the buffer for TOSSIM-to-SF direction to two SFs alter-
natively. And at the other end, there will be at least one
TOSSIM receiver which gets TOSSIM messages from
ESECT and put them into the buffer for TOSSIM-to-SF
direction, and there will be only one TOSSIM sender
which is used to send messages from the buffer for
SF-to-TOSSIM direction to any clients connected with
MTTS. In short, messages from two SFs are aggregated
to any MTTS client in SF-to-TOSSIM direction, and
messages from any MTTS client are dispatched to two
SFs alternatively in TOSSIM-to-SF direction. And there
is also a main control thread group which manages all
the senders and receivers.
Besides messages transfer, MTTS should also take
charge of message formats transformation between SF
message and TOSSIM message. SF message format is
similar to that of serial message except an extra field
called as AM type is added at the head of SF message.
And TOSSIM message format is the same as that of se-
rial message when just considering the header and the
data region of the message. Though there are other parts
in TOSSIM message, only the header and the data region
are considered in MTTS because ESECT will manage
the other parts of TOSSIM messages. So, message for-
mats transformation in MTTS is mainly implemented by
the adding or removing of the AM type fields. And ex-
Figure 4. The architecture of ESECT.
cept AM type fields, network byte order of some other
fields in the message may also be changed since network
byte order can be different between both ends. All this
transformation is done by each direction’s buffer.
4.4. ESECT
Figure 4 shows the architecture of ESECT. In ESECT,
execution model, radio model, ADC model and TOSSIM
components belong to the original TOSSIM; driver, re-
ceiver, sender and GNB sender are newly introduced.
Execution model is the foundation of TOSSIM, and it
is based on a discrete TOSSIM event queue. In TOSSIM,
the simulated WSN is driven by TOSSIM events. A
TOSSIM event is different from a TinyOS event which is
a kind of procedure call; however, a TOSSIM event is a
structure which is associated with a virtual clock. All
TOSSIM events in the event queue are ordered ascend-
ingly according to the virtual time. And the running of
TOSSIM is in accordance with the ordered TOSSIM
events.
Radio model and ADC model are separately used to
model the radio environment anc d the sensing environ-
ment. TOSSIM components are used to replace those
low-level and hardware-specific components. All these
components establish the simulated environment.
In the following, the newly introduced parts will be
discussed, which enable the simulated environment to
interact with the physical sensor node normally.
Driver The driver builds the simulated environment
which is shared b y all nodes, dr ives the simulated WSN,
and synchronizes the single physical node and the virtual
nodes.
The driver first creates the topology of the network
and the noise of each nod e based on a configuration f ile.
In order to make PN share the same simulated environ-
ment with all virtual nodes, a virtual agent which repre-
sents the single physical node is created in the simulated
environment. Figure 5 shows the interaction between PN
and the virtual nodes through the virtual agent. In
ESECT, messages sent from the virtual nodes to PN are
first sent to the virtual agent, and then sent to PN by the
sender of ESECT; however, messages from PN are di-
C
opyright © 2009 SciRes. WSN

328 W. J. LI ET AL
Figure 5. Interaction between PN and the virtual nodes.
rectly sent to the virtual nodes. In fact, the virtual agent
here is only a stub which does not run the TinyOS pro-
gram under test. After building the simulated environ-
ment, the driver will also establish all connections to
MTTS and GNB if possible.
In order to drive the simulated environment, the driver
sets the boot-up time for all virtual nodes (excluding the
virtual agent) by inserting corresponding TOSSIM
events into the discrete event queue. When the simula-
tion starts, the driver gets the latest TOSSIM event con-
tinually from the discrete event queue, and then runs the
event handler. Because every TOSSIM event is related to
a node, the execution of the event handler causes the
corresponding node to take some actions, which may
produce some more TOSSIM events such as to assure the
running of ESECT.
The time associated with a TOSSIM event is virtual,
but the time in PN is real. They are very different.
Therefore synchronization is essential to maintain a cor-
rect interaction between the virtual nodes and PN. Gen-
erally speaking, the virtual clock ticks faster than the real
clock when simulating not too large WSN applications.
So when fetching the latest TOSSIM event, the driver
checks whether the virtual time is faster than the real
time; if so, the driver will sleep until the real time is
equal with the virtual time, and otherwise it will execute
the event handler immediately.
Receiver The receiver in ESECT is used to receive
messages from MTTS and forward them to the neighbors
of PN. The receiver is not controlled by the driver; in-
stead, it inserts new TOSSIM events about message re-
ceiving for the driver. When the receiver receives a mes-
sage, it creates a new TOSSIM message according to the
one received and the ID of PN, and then deliver it to the
message list of any virtual node next to PN. The receiver
also creates a TOSSIM event for every virtual node next
to PN when sending a message to it.
Sender The sender is controlled by the driver and
starts each time the event handler of the virtual agent is
executed. In fact, there are only events about message
receiving in all TOSSIM events of the virtual agent be-
cause it does not run actually. So, the occurrence of a
TOSSIM event of the virtual agent means that a virtual
node sends a message to PN. Meanwhile, the sender will
fetch the message in the message list of the virtual ag ent,
and send it to MTTS.
GNB Sender The GNB sender manages sending net-
work interaction information to GNB, and starts every
time a TOSSIM event about message receiving occurs. If
a TOSSIM event is about message receiving, it records
both the source and the destination of the message. And
when the GNB sender starts, it creates a short message
which includes the source and the destination of the
message according to the information of the occurring
TOSSIM event, and then sends it to GNB.
4.5. GNB
GNB is a graphical brow ser for the tested WS N, sh ow ing
the network interaction dynamically. Figure 6 shows the
graphical interface of GNB, which is displaying the in-
teraction of an 8-node network. In GNB, each circle
represents a node, and the color of the single physical
node is different from others. An array represents a mes-
sage from the rear of the array to the head of the array.
GNB consists of two threads, of which, one is used to
show and update the interface, and the other is used to
receive short messages from ESECT. The positions of
the nodes in GNB can be random or designated by the
user. When ESECT starts, GNB collects the interaction
information continuously, and updates the interface pe-
riodically. Through GNB, the tester can get an overall
sight of the WSN application under test, which is helpful
for revealing some defects and faults in the program.
5. Evaluation
In this section, we show that H-TOSSIM really solves
the problems existing in pure simulation testing tools
Figure 6. The graphical interface of GNB.

W. J. LI ET AL 329
Figure 7. The testbed of H-TOSSIM.
such as TOSSIM. Figure 7 shows the testbed of H-
TOSSIM. On the left, there is a laptop running two SFs,
MTTS, ESECT, and GNB; in the center, there are three
physical nodes, of which the two side-by-side nodes are
used as DBS, and the remaining one is PN; on the right,
there is a digital multimeter which is used to record the
current of PN, and its result is saved to the desktop. The
digital multimeter and the desktop are an option for es-
timating the power consumption of PN.
In the rest of this section, the applications under test
we choose are typ ica l , which means: 1) they were de-
veloped by the scholars who designed and implemented
the TinyOS and TOSSIM, and distributed along with the
TinyOS 2.x Package; 2) many researches on WSN test-
ing also use these applications for evaluating their simu-
lators. Besides, for better understanding of the advan-
tages of H-TOSSIM against TOSSIM, comparisons of
testing the same applicatio n are made.
5.1. Revealing the Length Setting Error of Mes-
sage Sending
In the nesC programming, before sending out a message
via the radio, the code must explicitly depicts the length
of the package. Hence it has a chance that the declared
length and the actual length of the package are not cor-
responding. In the real network, the radio component of a
mote sends out the data according to the declared length,
so the above case possibly leads to a incomplete pack age
and unpredictable errors. However, TOSSIM, for the
consideration of scalability, simulates the package send-
ing by delivering a pointer to the package in the com-
puter memory from the source node to the destination
node, instead of the entire package, and this mechanism
makes it can’t reveal the length setting error of message
sending. H-TOSSIM has a physical network, which be-
haves identical to any node in the real network, so it has
the ability to reveal th is error.
typedef nx_struct Ra-
dioToBlinkMsg2 {
nx_uint16_t nodeid;
nx_uint8_t group;
nx_uint8_t value;
} RtoBGroupMsg_t;
RtoBGroupMsg_t message
typedef nx_struct Ra-
dioToBlinkMsg {
nx_uint16_t nodeid;
nx_uint16_t counter;
nx_uint8_t flag;
} RtoBFlagMsg_t;
RtoBFlagMsg_t message
Figure 8. The structures of the two types.
In the following experiments, the program called as
RadioToBlink is tested. This program sends two types of
messages periodically, and these two types are separately
called as RtoBGroupMsg_t and RtoBFlagMsg_t. Figure8
shows the structures of the two types. RtoBGroupMsg_t
message is 4 bytes, and RtoBFlagMsg_t message is 5
bytes
In the two types of messages, the nodeid field is the
source id of the message; the counter field is the value of
a variable kept in the program which will increase by 1
whenev er a RtoBGroupMs g_t message is sent; the group
field and the value field are separately the high byte and
the low byte of the counter; the flag field is the value of
the lowest 3 bits of the counter.
We implant a fault in this program: the length of
RtoBFlagMsg_t message is set to be 4 bytes when send-
ing it out. In such a case, this type of message will be
partly lost. We test the program in TOSSIM and
H-TOSSIM. Figure 9 and 10 show the tested network
topologies in TOSSIM and H-TOSSIM.
Figure 11 and 12 give the testing results, which show
the messages received by node 2. From Figure 11, it can
be shown that all R to BFlagM sg _t messages received are
normal. It means that TOSSIM can not reveal the length
setting error of the program. However, from Figure 12,
Figure 9. The tested network topology in TOSSIM.
Figure 10. The tested netw ork topology in H-TOSSIM.
C
opyright © 2009 SciRes. WSN

330 W. J. LI ET AL
Figure 11. The debugging information for RadioToBlink in
TOSSIM.
Figure 12. The debugging information for RadioToBlink in
H-TOSSIM.
we can see that the flag fields of RtoBFlagMsg_t mes-
sages received from node 4 keep being 0, which means
that the flag field is lost. That is to say, H-TOSSIM can
reveal the length setting error through the comparison of
PN and other virtual nodes.
5.2. Revealing Calculation Overload Problem in
a Task
In the real network, while the mote is processing a heavy
task, it possibly ignores program interrupts because there
is not enough CPU resource to handle the interrupt.
Consequently, it leads some unexpected errors, such as
loss of package. So the programmer needs to test
whether his application will has a defect causing the
mote into a calculation overload status. However, events
in TOSSIM, by the mechanism of discrete event, are
considered as completion in a snap in the simulated vir-
tual environment. As a result, the calculation overload
problem never occurs in TOSSIM. However, this situa-
tion exists in the physical node of H-TOSSIM, which is
helpful for the developer to find out his application’s
defect.
In the following experiments, the program called as
BlinkToRadio will be tested. This program sends a
BtoRFlagMsg_t message every T time, and posts a task
to do some processing before each message sending. The
structure of the BtoRFlagMsg_t message is the same
with that of RtoBFlagMsg_t message. And the counter
variable in the program will increase by 1 when sending
a message. Here T is set to be 200 ms, and there is
300000 times multiplication in a task.
We test this program in both TOSSIM and H-TOSSIM
for 10 seconds. And each node is expected to send 50
messages totally. The testing network topologies in
TOSSIM and H-TOSSIM are the same with that of the
previous testing.
Figure 13 and 14 give the testing results, which focus
on the messages received by node 2. From Figure 13, it
can be shown that the value of the counter field is ap-
proximately 50 finally, which is as expected. However,
this does not mean that the program is correct when it is
Figure 13. The debugging information for BlinkToRadio in
TOSSIM.
Figure 14. The debugging information for BlinkToRadio in
H-TOSSIM.

W. J. LI ET AL 331
of a node in these three networks. We can see that the
power consumptions of a node in different sizes of net-
works are different. So H-TOSSIM is necessary and useful,
we can use it to estimate power consumption for different
sizes of WSN with only three physical nodes.
deployed. From the result of H-TOSSIM, we can see that
the value of the counter field of the message from PN is
much less than that of the virtual node, which indicates
that the calculation of the task in the program is over-
laden. That is to say, H-TOSSIM can reveal the calcula-
tion overload problem in a task.
5.3. Estimating the Power Consumption
H-TOSSIM needs a digital multimeter when it estimates
the power consumption of a node; however, its advan-
tage is that it supports th e power consumption estimation
of single node in a large WSN with low hardware cost.
In this section, we first justify that H-TOSSIM is neces-
sary and useful; and then we evaluate the accuracy of
H-TOSSIM; finally, to show the advantage of H-TOS-
SIM, we use it to estimate the power consumption of a
single node in different size of WSN.
Figure 15. Average current of A node in different size of
WSN.
In the following experiments, a program called Sen-
sorToRadio is used. This program reads sensing result
every second and sends it out as a message. When the
program receives a message, it will do some processing,
and then forwards it if it is a new value. The program
will be tested for 150 seconds every time. Because the
voltage of PN can be kept 3V for a time, average current
is used to measure the power consumption.
We test the program in three different sizes of physical
sensor networks and estimate the power consumption of a
node in the networks. Figure 15 shows the average current Figure 16. Power consumption estimation: H-TOSSIM Vs
Physical WSN.
Figure 17. The three different sizes of network topologies.

332 W. J. LI ET AL
Figure 18. The estimation results for three different sizes of
network topologie s.
In order to evaluate the accuracy of H-TOSSIM, we
compare H-TOSSIM and physical sensor network in
power consumption estimation. Because of the limit of
the number of physical nodes, we compare the sensor
networks with 2 and 3 nodes only. Figure 16 shows the
estimation results. We can see that the results are the
same for the network with 2 nodes, and for the network
with 3 nodes the results are subequal. That is to say, it is
accurate for H-TOSSIM to estimate the power consump-
tion of a node in the network.
Finally, we test the program with H-TOSSIM in three
different sizes of WSN, and estimate the power con-
sumption of PN. Figure 17 shows the testing network
topologies. And the estimation results are shown in Fig-
ure 18. The average currents of PN for these three dif-
ferent topologies are separately 18.64 mA, 18.75 mA and
18.83 mA. Through these testing, we show the advantage
of H-TOSSIM that it can estimate power consumption
for large WSN with low ha r d ware cost.
6. Conclusions and Future Work
In this paper, we first analyze the problems existing in
pure simulation testing tools such as TOSSIM. Then we
propose H-TOSSIM, a hybrid testbed, which extends
TOSSIM with physical nodes. In H-TOSSIM, a physical
node shares the same simulated environment with all
virtual nodes so as to test a WSN program. H-TOSSIM
combines the advantages of both the physical node and
the simulated environment in software testing. Through
experiments, we show that H-TOSSIM solves the prob-
lems existing in pure simulation testing tools with low
hardware cost.
For the future work of H-TOSSIM, it uses only one
kind of combination pattern between the physical nodes
and the simulated environment; however, there are other
combination patterns which are worth considering.
The first consideration is to use the physical nodes to
provide signal gains between different nodes for the
simulated environment. Signal gains are designated by
user now. If these data can be acquired from real world
through the physical nodes, the accuracy for H-TOSSIM
to estimate the power consumption for large WSN can be
improved.
The second consideration is to use the physical nodes
to provide sensing data for the virtual nodes. Sensing
results are produced randomly in the current version of
H-TOSSIM. If the virtual nodes can get sensing data
from the real world through the physical nodes, the soft-
ware testing can be more sufficient and more practical.
7. References
[1] I. Akyildiz, W. Su, et al., “Wireless sensor networks: A
survey,” Computer Networks, Vol. 38, No. 4, pp. 393–
422, March 2002.
[2] P. Levis, N. Lee, et al., “TOSSIM: Accurate and scalable
simulation of entire TinyOS applications,” in Proceedings
of the First ACM Conference on Embedded Networked
Sensor Systems, Los Angeles, CA, pp. 126–137, No-
vember 2003.
[3] P. Levis an d N. Lee, “TOSSIM: A simulator for TinyOS
networks, October 2007,
http://www.cs.berkeley.edu/~pal/pubs/nido.pdf.
[4] H. Lee, A. Cerpa, and P. Levis, “Improving wireless
simulation through noise modeling,” in Proceedings of
the Sixth International Conference on Information Proc-
essing in Sensor Networks, Cambridge, Massachusetts,
pp. 21–30, April 2007.
[5] TinyOS. http://www.tiny os. net/.
[6] J. Hill, R. Szewczyk, et al., “System architecture direc-
tions for networked sensors,” ACM SIGPLAN Notices,
Vol. 35, No. 11, pp. 93–104, 2000.
[7] D. Gay, P. Levis, et al., “The nesC language: A holistic
approach to networked embedded systems,” ACM SIG-
PLAN Notices, Vol. 38, No. 5, pp. 1–11, May 2003.
[8] V. Shnayder, M. Hempstead, et al., “Simulating the
power consumption of large-scale sensor network appli-
cations,” in Proceedings of the Second ACM Conference
on Embedded Networked Systems, Baltimore, MD, pp.
188–200, November 2004.
[9] The Network Simulator: ns–2. http://www.isi.edu/
nsnam/ns.
[10] S. Park, A. Savvides, and M. B. Srivastava, “SensorSim:
A simulation framework for sensor networks,” in Pro-
ceedings of the Third ACM International Workshop on
Modeling, Analysis and Simulation of Wireless and Mo-
bile Systems, Boston, Massachusetts, pp. 104–111, Au-
gust 2000.
[11] L. Girod, T. Stathopoulos, et al., “A system for Simula-
tion, emulation, and deployment of heterogeneous sensor
networks,” in Proceedings of the Second ACM Confer-
ence on Embedded Networked Sensor Systems, Balti-
more, MD, pp. 201–213, November 2004.
[12] J. Pollet, D. Blazakis, et al., “ATEMU: A fine-grained
sensor network simulator,” in Proceedings of the First
IEEE Communications Society Conference on Sensor
and Ad Hoc Communications and Networks, Santa Clara,
CA, pp. 145–152, October 2004.

W. J. LI ET AL 333
[13] B. L. Titzer, D. K. Lee, and J. Palsberg, “Avrora: Scal-
able sensor network simulation with precise timing,” in
Proceedings of the Fourth International Conference on
Information Processing in Sensor Networks, Los Angeles,
CA, pp. 477–482, April 2005.
[14] D. Jia, G. H. Krogh, and C. Wong, “TOSHILT: Middle-
ware for hardware-in-the-Loop testing of wireless sensor
networks,” October 2007.
http://www.ece.cmu.edu/~webk/sensor_networks/pub/ips
n05_hilt.pdf.
[15] G. Werner-Allen, P. Swieskowski, and M. Welsh, “Mo-
teLab: A wireless sensor network testbed,” in Proceed-
ings of the Fourth International Conference on Informa-
tion Processing in Sensor Networks, Los Angeles, CA, pp.
483–488, April 2005.
[16] M. Dyer, J. Beutel, et al., “Deployment support network:
A toolkit for the development of WSNs,” in Proceedings
of the Fourth European Workshop on Sensor Networks,
Berlin, pp. 195–211, January 2007.
[17] L. Girod, J. Elson et al., “EmStar: A software environ-
ment for developing and deploying wireless sensor net-
works,” in Proceedings of the USENIX Technical Con-
ference, San Diego, CA, pp. 24–37, June 2004.
[18] J. Hill, M. Horton, et al., “The platforms enabling wire-
less sensor networks,” Communications of the ACM, Vol.
47, No. 6, pp. 41–46, June 2004.
[19] J. Polastre, R. Szewczyk, and D. Culler, “Telos: Enabling
ultra-low power wireless research,” in Proceedings of the
Fourth International Conference on Information Process-
ing in Sensor Networks, Los Angeles, CA, pp. 364–369,
April 2005.
C
opyright © 2009 SciRes. WSN