Vous êtes sur la page 1sur 12

Journal of Network and Computer Applications 46 (2014) 48–59

Contents lists available at ScienceDirect

Journal of Network and Computer Applications


journal homepage: www.elsevier.com/locate/jnca

Communication performances of IEEE 802.15.4 wireless sensor motes


for data-intensive applications: A comparison of WaspMote, Arduino
MEGA, TelosB, MicaZ and iMote2 for image surveillance
Congduc Pham
University of Pau, LIUPPA Laboratory, Avenue de l'Université, BP1155, 64013 Pau Cedex, France

articleinfo
abstract
Article history:
Received 6 January 2014 In this paper, we are investigating the communication performances of low-resources sensor motes that
Received in revised form are commonly found in recent smart cities test-beds or used by the research community. We focus here
11 June 2014 on 802.15.4 radio and we will present a performance study of sending and receiving capabilities of
Accepted 6 August 2014 Libelium WaspMote, Arduino-based motes, Telosb-based motes, MicaZ motes and iMote2 motes when
Available online 21 August 2014 a large number of packets needs to be sent from sources to sink node. We provide measures for the
Keywords: minimum time spent in send procedure, minimum time needed to read data into application memory
Sensor networks space and maximum sender/receiver throughput. We will highlight the main sources of delays
Data intensive communications assuming no flow control nor congestion control to determine the best case performance level. Our
Communication performances contribution is therefore in determining the maximum realistic level of performance for commonly
Image surveillance found mote platforms in order to predict end-to-end performances for surveillance applications.
Finally, we illustrate our study with an image transmission test case for intrusion detection
surveillance applications.
& 2014 Elsevier Ltd. All rights reserved.

1. Introduction
where experimentations are conducted on the Santander's Smart-
Santander (www.smartsantander.eu) test-bed for demonstrating
In the last few years, the research efforts in the field of Wireless
the benefit of distributed acoustic sensing for a various number of
Sensor Networks (WSN) were focused more particularly on low
civil applications such as detection of unusual situations, move-
cost scalar sensor nodes. This type of networks composed of a
ment in Restricted Areas, crowding, measure traffic flow and
large variety of nodes is able to gather on a large scale environ-
Energy-Efficiency Monitoring (www.ear-it.eu). As multimedia data
mental data such as temperature, acceleration, moisture level, etc,
usually require a much larger amount of packets to be transferred,
and to carry out specific processing (fusion, compression, etc.) on
and most likely with some time constraints, they perfectly fit into
these data to transmit obtained information to a base station
the so-called data-intensive sensor network category.
(Sink) for further treatment and analysis. However, the purely
Nowadays, such applications are possible since low-power
scalar nature of these collected data might be limiting for more
sensors equipped with embedded CMOS cameras and micro-
complex applications such as object detection, surveillance, recog-
phones are easily available or be easily built from off-the-shelves
nition, localization, and tracking. Therefore, in addition to tradi-
hardware (such as Arduino platforms). This article particularly
tional sensing network infrastructures, a wide range of emerging
considers such Wireless Image Sensor Networks (WMSN) where
wireless sensor network applications can be strengthened by
sensor nodes can provide images data to a sink, either in an
introducing multimedia capability: image and acoustic sensing
automated way or in an on-demand basis. These sensors can be
for instance. The vision capability is a more effective mean to
thrown in mass on an area of interest for search&rescue situation
capture important quantity of richer information and vision
awareness or intrusion detection; or be deployed in the context of
constitutes a de-facto dominating channel by which people
an industrial or smart city infrastructure. In all cases, captured
perceive the world. Acoustic information can also be an important
images need to be sent from the source sensor node to the sink or
source of information, especially for security surveillance applica-
base station. In this paper, we are focusing on the communication
tions in the context of smart cities. For instance, the FP7 EAR-IT
performances of low-resources sensor motes that are commonly
project is an original project on acoustic sensing for smart cities
found in smart cities test-beds or used by the research community.
We will therefore present a performance study of sending, receiv-
ing and relaying capabilities of Libelium WaspMote, Arduino-
E-mail address: congduc.pham@univ-pau.fr
based motes, Telosb-based motes, MicaZ motes and iMote2 motes

http://dx.doi.org/10.1016/j.jnca.2014.08.002
1084-8045/& 2014 Elsevier Ltd. All rights reserved.
C. Pham / Journal of Network and Computer Applications 46 (2014) 48–59
4
when a large number of packets needs to be streamed from
aMaxPHYPacketSize¼ 127 bytes, the maximum payload is 127
sources to sink node.
— 5¼ 122 bytes. This payload is the MAC payload which is also
There have been previous work on image/multimedia
what is available for the application in case of no routing overhead
sensors (Rahimi et al., 2008; Hengstler and Aghajan, 2006;
(quite common in wireless sensor networks where routing could
Cucchiara et al., 2007; Misra et al., 2008; Soro and Heinzelman, 2009;
be done at application layer). If using the 64-bit addressing mode,
Rinner and Wolf, 2009; Paniga et al., 2011; Salvadori et al., 2013) but
the maximum payload is 102 bytes.
few of them really consider timing on realistic hardware
Non-beacon enabled IEEE 802.15.4 networks use an unslotted
constraints for sending/receiving packets. Paniga et al. (2011)
CSMA-CA channel access mechanism. Each time a device needs to
and Chen et al. (2013) are probably the closest work to ours with
transmit, it waits for a random number of unit back-off periods in
real experi- mentations on iMote2 and TelosB sensors. However,
the range f0; 2BE — 1g before performing the Clear Channel Assess-
their focus was more on global performances than on a detailed
ment (CCA). Initially, the back-off exponent BE is set to macMinBE.
study of the hardware and API limitations. In this paper, we
will present experimentations with real sensor boards and real Using the default value of 3 for macMinBE and assuming the
channel is found to be free, the worst-case channel access time can
radio modules to transmit a large amount of packets in a
be calculated as
streamed fashion. We will highlight the main sources of delays
assuming no flow control nor congestion control to determine InitialBackoffPeriod þ CCA
the best case performance level. One usage for this study could ¼ ð23 — 1Þ~ aUnitBackoffPeriod þ CCA
be to use these real performance measures in simulation models
¼ 7 ~ 320 μs þ128 μs
to provide more realistic performances for large-scale
multimedia sensor networks deployment for instance. Although ¼ 2:368 ms
it is not possible to address the large variety of existing sensor
boards (see Tavli et al., 2012 for a survey on image sensor
The CCA detection time is defined as 8 symbol periods.
platforms) we however provide measures for UART-based and
aUnitBackoffPeriod is defined as 20 symbol periods. 1 symbol
SPI-based sensors that could be adapted to other type of sensors
period is equal to 16 μs. However, macMinBE could be set to 0 to
to determine the performance level that can be expected. Also,
increase efficiency, in which case the CSMA/CA channel access
we will investigate on 2 well-known and well- used
time will default to the minimum Long Inter-Frame Spacing (LIFS)
programming environments: Arduino-like IDE (cc.arduino. org)
of 0.640 ms.
and TinyOS (www.tinyos.org). One side motivation of this article
IEEE 805.15.4 by default uses ACK for unicast communication.
is also to present the potentials and the limitations of multimedia
When such ACK are required the IEEE 802.15.4 standard stipulates
wireless sensor networks for surveillance applications when using
that the transmission of an acknowledgment frame (in a non-
IEEE 802.15.4 (IEEE, 2011) multi-hop connectivity to streamed a
beacon enabled network) commences aTurnaroundTime symbols
large amount of data. We will not address the capture process, i.e.
after the reception of the data frame, where aTurnaroundTime is
how to capture image, nor the compression overheads, as these 2
equal to 192 μs. This allows the device enough time to switch
compo- nents can be optimized in many various ways such as
between transmit and receive, or vice versa.
dedicated daughter boards with hardware optimizations (see for
An acknowledgment frame consists of 11 bytes that can be
instance the recent Seed-Eye board Evidence Embedding
transmitted in 0.352 ms. The transmission of an acknowledgement
Technology,).
does not use CSMA/CA. We show in Fig. 1 the various 802.15.4
The paper is then organized as follows. Section 2 reviews the
parameters and maximum throughput for macMinBE ¼ 3 and
IEEE 802.15.4 communication features and present the various
macMinBE ¼ 0 when there are no error.
hardware platforms that will be evaluated. The tests set-up is also
described. Then Sections 3–5 will present real measures of what
could typically be expected with 802.15.4 communication stacks at 2.2. Libelium WaspMote & Arduino
the application level for a sender, a receiver and a relay node
respectively. We will measure the various time overhead and will Libelium WaspMote use an IEEE 802.15.4 compliant radio
determine the maximum sender, receiver and relay throughput. module called XBee manufactured by (Digi) which offers a max-
Section 6 presents a test case consisting in multi-hop still image imum application level payload of 100 bytes. The maximum
transmission. Conclusions will be given in Section 7. transmission power is 1 mW for the regular version of the XBee.
A Pro version can use transmission power up to 100 mW. By
default, the XBee module uses a macMinBE value of 0 therefore the
2. Sensor motes hardware description and test set-tup

We will consider Libelium WaspMote (Libelium,) that are used


in a number of Smart Cities and environmental monitor-
ing projects (Libelium; SmartSantander), Arduino MEGA 2560
(Arduino,) (Libelium WaspMote IDE is largely based on Arduino),
TelosB motes from AdvanticSys (AdvanticSys,), Crossbow MicaZ
motes and CrossBow iMote2 motes. The last 3 platforms being
quite well-known to the WSN research community.

2.1. Review of the IEEE 802.15.4 protocol

The latest standard for IEEE 805.15.4 is described in (IEEE,


2011). The radio maximum throughput is 250 kbs. In 802.15.4
networks, node addressing could be realized using 16-bit address
or 64-bit address. Therefore the addressing field could be a
minimum of 0 bytes and a maximum of 20 bytes which results
in a header size between 5 bytes and 25 bytes in the case of no Fig. 1. Theoretical IEEE 802.15.4 application level throughput with ACK, no error.
security header. As the maximum frame size at radio level is
effective maximum throughput roughly corresponds to the 102-
bytes payload case presented previously. The WaspMote has an
Atmega1281 running at 8 MHz. The XBee module and the micro
controller communicate through an UART, and for the WaspMote
the default data rate is set to 38,400 bps by the Libelium API. We
use a modified version of the “light” Libelium API provided by
Libelium. Compared to the “full” Libelium API that additionally
handles long packets with fragmentation/reassembly support, the
light Libelium API is much faster and our modified version further
reduces the complexity of the send operation. As WaspMote is
very similar to the well-known Arduino boards the previous
information also apply to the Arduino MEGA 2560 board which
features an ATmega2560 running at 16 MHz. Except for the most
recent Arduino Due board, the Arduino MEGA2560 board is one of
the fastest Arduino boards in the market and is quite representa-
tive of UART-based sensor boards. On the Arduino, we also use a Fig. 2. Sensor mote platforms.
very lightweight communication library (Rapp,) and our modified
API for the WaspMote achieves the same level of performance
than the Arduino's API. Both motes use the Arduino programming the energy saving profile. It is targeted for multimedia application
environment that offers a Cþþ-like programming language. as it also come with an MMX DSP Coprocessor. The mote has
Various libraries are available for the Arduino and they can be 256 kB SRAM, 32MB FLASH and, as the TelosB and MicaZ, uses
used on the WaspMote with very little changes. the ChipCon CC2420 802.15.4 radio module. Communication
between the microcontroller and the CC2420 is realized through an
2.3. Advanticsys TelosB-based mote and CrossBow micaz mote SPI bus and the programming environment we use is TinyOS.
Unfortu- nately, the TKN154 protocol stack is not supported by the
AdvanticSys motes (we experimented on CM5000 and iMote2, therefore we use the TinyOS Ieee154 component that is
CM3000) are based on TelosB motes and therefore will be referred basically the ActiveMessage system but without the 2 additional
to as TelosB. TelosB motes are built around an TI MSP430 micro- bytes in the payload, therefore allowing full compatibility with
controller at 8 MHz while the MicaZ uses an Atmel128 at 8 MHz. XBee radio modules (Libelium and Arduino) and TKN154 protocol
Both have an embedded ChipCon CC2420 802.15.4 compatible stack (TelosB and MicaZ).
radio module with a maximum transmission power of 1 mW. The
original TelosB description and datasheet can be found in Cross- 2.5. Test set-up
Bow (http://www.bullseye.xbow.com:81/products/product_pdf_
files/wireless_pdf/telosb_datasheet.pdf). Documentation on the In all the tests described in this article, the transmission power is
AdvanticSys motes can be found in AdvanticSys (http://www. set to the maximum radio module power which is 1 mW for all
advanticsys.com/). MicaZ description can be found in CrossBow radios (we did not use the Pro version of the XBee module) and the
(http://bullseye.xbow.com:81/products/product_pdf_files/wireless maximum payload at the application level is set to 100 bytes. We use
_ pdf/micaz_datasheet.pdf). The CC2420 radio specification and a very simple topology consisting in a sender mote and a receiver
doc- umentation are described in Texas Instrument mote. The receiver can act as a sink or a relay is case of relaying
(http://www.ti.com/ lit/gpn/cc2420). The important difference operations. The motes are placed at a distance of a few meters. Also,
with these motes, com- pared to the previously described we took care in running our tests in low WiFi perturbation environ-
Libelium WaspMote or Arduino, is that the radio module is ment to limit the interferences with WiFi signals. However, we found
connected to the microcontroller through an SPI bus instead of a that these interferences have very little even in the presence of
serial UART component. This normally would allow for much operational WiFi networks. Regarding the antennas, we used the
faster data transfer rates. 2dBi SMA antenna for the XBee module and the 5dBi SMA antenna
TelosB and MicaZ are usually programmed under the TinyOS for the AdvanticSys TelosB (the one that is shipped by default). The
system (TinyOS,), although other OS can be used. In this paper, we MicaZ antenna is the monopole 1.2 inch antenna shipped with the
will only study the communication performance under TinyOS. mote which gain is not specified. For the iMote2, this is the PCB
The lastest stable version of TinyOS is 2.1.2 and our tests use this antenna model. However, the impact of antenna gain is very small
version. The default TinyOS configuration use a MAC protocol that given the small distance set up for the tests. This is done on purpose
is compatible with the 802.15.4 MAC (Low Power Listening because there are too many antenna designs and orientations
features are disabled). The default TinyOS configuration also uses available depending on the deployment environment for us to test.
ActiveMessage (AM) paradigm to communicate and interoperable Figure 2 illustrates the various platforms used in the tests. From left
frames (IFRAME) are used to allow interoperability with non- to right and top to bottom: Libelium WaspMote, Arduino MEGA
TinyOS network. However, AM system takes 2 extra bytes in the 2560, AdvanticSys TelosB, MicaZ and iMote2.
802.15.4 payload for interoperability purposes. We will not use the The results we will present in this article can therefore be
default MAC layer of TinyOS but rather the TKN154 IEEE 802.15.4 considered as “best case” results and we did not want to have
compliant API. We verified the performances of TKN154 against packet losses due to attenuation, interferences or radio
the TinyOS default MAC and found them similar (TelosB case) or contention since the main goal is to measure the time overhead
greater (MicaZ case) than the ActiveMessage protocol stack. for commu- nication in order to determine experimentally the
Therefore, in all cases, the results that will be presented are the maximum performance level.
best case results that we could obtained with our tests.

2.4. Crossbow iMote2 mote 3. Sending performances

The iMote2 is a high-performance mote featuring a PXA271 One of the main objectives of our work in this paper is to take
XScale processor running between 13 and 416 MHz depending on into account the real overheads and limitations of realistic sensor
hardware. Most of simulation models or analytical studies only
bottleneck in the communication process. In order to avoid this
consider the frame transmission time as a source of delay.
bottleneck, we increased the UART data transfer rate. However,
However, before being able to transmit a frame, the radio
increasing the baud rate cannot be done without taking into
module needs to receive the frame in its transmission buffer. In
account some timing constraints that may make the serial com-
many low cost sensor platforms, the bottleneck is often the
munication unreliable, see Foster.
interconnection between the microcontroller and the radio
The WaspMote microcontroller runs at 8 MHz while the
module. Many sensor boards use UARTs (serial line) for data
XBee module has a 16 MHz clock and requires that the
transfer which data transfer rate lies somewhere between 38,400
frequency is 16 times the baud rate. It means that for a baud rate
bps and 230,400 bps for standard bit rates. Non-standard baud
of 38,400, the actual operating frequency need~ to be 16 38,000
rates are usually possible, depending on the microcontroller
614,400 Hz. For reliable communication, the WaspMote clock
master clock, and also, depending on UARTs, higher speed can be
should also produce a frequency close to 614,000 Hz. Since it
achieved. Nevertheless, in addition to the radio transmission time,
runs at 8 MHz, the dividing factor is 8,000,000/614,000¼
one has to take into account the time needed to write data into the
13.020833. Using the nearest integer dividing factor of 13, the
radio module's buffer. This time is far from being neglectible as
actual baud rate is 8,000,000/16/13¼ 38461.54 which is
most of serial communications also adds 2 bits of overhead (1 start
1.0016026 times greater than the target baud rate. The error is
bit and 1 stop bit) to each 8-bit data. Therefore, with a serial data
about 0.1602% which allows for reliable communication between
transfer rate 230,400 bps, which is already fast for a sensor board
the microcontroller and the XBee module. Actually, 38,400,
UART, writing 100 bytes of application payload needs at least 100
which is the value chosen by the Libelium API is the fastest
~ 10/230,400¼ 4.34 ms if the 100 bytes can be passed to the radio
standard baud rate that provides acceptable errors between the
without any additional framing bytes. In many cases, one has to
target baud rate and the actual baud rate. Using 57,600 or
add extra framing bytes, making the 4.34 ms a sort of minimum
115,200 baud rates would generate too many errors, making the
overhead to add to each packet transmission in most of UART-
communication very unreliable and therefore not functioning at
based sensor boards. If we consider an image trans- mission that
all. Even on the XBee, 57,600 and 115,200 baud rates cannot
requires sending the image in a multitude of packets, we clearly
accurately be achieved with the 16 MHz clock. Using these
see that the minimum time before 2 packet generation is the sum
constraints, the perfect dividing factors for the WaspMote are
of the time to write frame data to the radio and the time for the
10, 5, 4, 2 and 1 which correspond to 50,000,
radio to transmit the frame. According to the 802.15.4 standard, if
100,000, 125,000, 250,000 and 500,000 baud rates respectively.
we consider a unicast transmission with the initial backoff
As we showed that the maximum 802.15.4 effective
exponent BE set to 0 (default is 3), we typically need a
throughput is roughly 150,000 bps in unicast mode when there
minimum of 5.44 msþ
are no errors, there is no point to consider 500,000 baud rate that
4.34 ms ¼ 9.78 ms to send a single 100-byte packet if there is no
would additionally overflow the transmission buffer. On the
error. Now, in more advanced hardware architecture the radio
Arduino, as the clock runs at 16 MHz, there is no problem in
module can be connected to the microcontroller through a high-
getting these baud rates with a dividing factor of 20, 10, 8, 4 and
speed bus (SPI for instance) which allows for much higher data
2 respectively. However, on both platforms, we observed many
transfer rates, in which case a unicast transmission of a single 100-
transmission errors between the microcontroller and the radio
byte packet with the same MAC parameter would take 5:44 msþ ϵ.
module at 250,000 baud rate that make the whole transmission
However, as we will show later on, not only the sending side
very unreli- able. Therefore, in practice, WaspMote and the
should
Arduino cannot really be used with a serial data transfer rate
be taken into account and sending fast is usually not reliable.
higher than 125,000 bps. This is the UART speed that we will be
To highlight the importance of data handling overheads, we
using in the experiments described in this paper.
will first measure on real sensor hardware and communication API
Figure 3 shows the time in send() breakout for the WaspMote
the time spent in a generic send() function (most communication
(data transfer rate is 125,000bauds) where we can especially see
APIs have a function to send a packet), noted tsend, and the
the time required to write to the radio. Each value for a given
minimum time between 2 packet generation, noted tpkt. tpkt will
payload size is an average value over 20 measures. The sum of all
typically take into account various counter updates and data
the timing represents what we called tsend. We can see that the main
manipulation so depending on the amount of processing required
delay here is the time to write to the radio and the overhead of the
to get and prepare the data, tpkt can be quite greater than tsend. With
communication library is kept small. The original Libelium “light”
tsend, we can easily derive the maximum sending throughput that
API has higher sending latencies because the send function
can be achieved if packets could be sent back-to-back, and with tpkt
includes a delay to wait for the transmit status from the XBee
we can have a more realistic sending throughput.
module. Our modified API removes this overhead and the transmit
In order to measure these 2 values, we will use a traffic generator
that sends packet back-to-back with a minimum of data manipula-
tion needed to maintain some statistics (counters) and to fill-in data
into packets, which is the case in a real application. For TinyOS, the
sending process may post send requests and the system will issue a
sendDone event when the send is completed. A busy flag should be
used to indicate that a sending is undergoing. This flag should then
be released when the sendDone event is process. Nevertheless, we
can use the same methodology than for the qualification of Wasp-
Mote and Arduino boards and we will measure the time between the
post of the send and the sendDone event as the “time in send()”
measure. The real time between 2 packet generation (when the busy
flag is cleared for the next send request) will also measure the
minimum time between 2 send.

3.1. Libelium WaspMote & Arduino, sending side

Fig. 3. Time in send() breakout, WaspMote.


By default, the communication between the microcontroller
and the XBee module is set to 38,400 bauds which is clearly a
realistic throughput could be derived from tpkt. On the Arduino,
the communication API has better performances, especially for tpkt:
for a 100-byte packet tpkt is about 13 ms. This is mainly due to the
higher clock frequency of the Arduino.

3.2. TelosB, MicaZ and iMote2, Sending side

Again, we use a traffic generator to send packet back-to-back


at the sender side. We then measure the time in send() (tsend) and
the minimum the time between 2 packet generation (tpkt) under
TinyOS. Once again, the so-called “fitted” curve is a linear
approx- imation and the label values on the curves correspond
to the fitted curve. Figure 5 shows the measures for the
Fig. 4. Time between 2 packet generation and time in send(), WaspMote.
TelosB(top), MicaZ (middle) and iMote2(bottom) respectively.
In Fig. 6 the top part shows the corresponding maximum
sending throughput and the maximum realistic throughput at
the sender side for the TelosB and the MicaZ. The bottom part is
for the iMote2. We differen- tiated the maximum sending
throughput case when only the time in send() is considered
from the case the time between 2 packet generation is used,
which is a more realistic scenario.
We can see that the MicaZ platform showed the best perfor-
mances, both in terms of time in send() and time between 2 packet
generation. MicaZ can realistically send one 100-byte packet in
about 11ms. The resulting maximum realistic sending throughput
is close to 70 kbps. Compared to the previous WaspMote and
Arduino platforms pushed at 125000 baud/s, MicaZ motes are still
much more performant while Imote2 has the lowest maximum
realistic sending throughput at about 31 kbps. The iMote2, despite
its much more powerful microprocessor has quite disappointing
networking throughput when it come to maintain a high traffic
rate. Regarding the difference between the time in send() and the
time between 2 packet generation, it is still difficult to clearly
identify why some platforms have higher differences than others.
In the case of MicaZ motes, this difference is very small, indicating
that the overheads outside the send() function is smaller that

Fig. 5. Time in send() and time between 2 packet generation: TelosB, MicaZ and
iMote2.

status can be checked outside the send function, just as the API for
the Arduino does.
Figure 4 shows both tsend and tpkt for the Waspmote. The so-called
“fitted” curve is a linear approximation and the label values on the
curves correspond to the fitted curve. The maximum Fig. 6. Maximum sending throughput for TelosB and MicaZ (top) and iMote2
(bottom).
those on the TelosB for instance. This may be due to differences in
microcontroller architecture with impacts on performances of
memory read/write operations or I/O transfers on SPI bus. How-
ever, the main objectives here still remains to quantify the
maximum performance level one can get at the application level.
In all the sending tests, the packet jitter at the source was found
very small.

4. Receiver performances

In the next set of experiments, we use the traffic generator to


send packets to a receiver. In general, flow control and
congestion control can be implemented but in practice the
latency will be increased. As we are not looking at reliability Fig. 8. Maximum sending throughput and maximum receiver throughput on
issues, we are not using flow control nor congestion control but WaspMote and Arduino.
rather send packets as fast as possible, measure the number of
received bytes at the receiver and compute the receiver
throughput each time the payload size is increased. Prior to this
test we also wanted to measure the time needed by the mote to
read the received data into user memory or application level,
noted tread. Normally, the receiver throughput is linked to tread
following a simple producer– consumer model: if packets arrive
faster than they can be made available to the application they
are dropped by the limited receiver buffer.

4.1. Libelium WaspMote & Arduino, receiver side


Fig. 9. Minimum read time on TelosB, MicaZ and iMote2.
Figure 7 shows for both the WaspMote and the Arduino the
time needed to read a packet into the application memory space.
Actually, we found that tread is quite independent from the
communication baud rate between the microcontroller and the
radio module. In all our experimentations, for baud rates of
38,400, 125,000 and 250,000, tread remains constant and depends
only on the data size. The reason why tread only depends on the
data size, at least at the application level, is as follows: most of
communication APIs use a system-level receive buffer and
when a packet arrives at the radio, a hardware interrupt in
raised and appropriate callback functions are used to fill in the
receive buffer that will be read later on by the application.
Therefore, the baud rate has only an impact on the time needed
to transfer data from the radio module to the receive buffer. Fig. 10. Maximum receiver throughput on TelosB, MicaZ and iMote2.
When in the receive buffer, the time needed to transfer the data
from the receive buffer to the application depends on the speed
of memory copy operations, therefore depending mainly on the 4.2. TelosB, MicaZ and iMote2, receiver side
frequency used to operate the sensor board and the data bus
speed. As we can see in Fig. 7, tread on the WaspMote is about 50 Following the same methodology applied for WaspMote and
ms and tread on the Arduino is about 35 ms, for a 100-byte Arduino, Fig. 9 shows for TelosB, MicaZ and iMote2 the time
packet. needed to read a packet into the application memory space.
Then, Fig. 8 shows the maximum receiver throughput for both Compared to values for WaspMote and Arduino shown in Fig. 7,
the WaspMote and Arduino motes. we can see that the more advanced architecture using in part an
SPI bus for the communications between the microcontroller and
the radio module offers very small data read time.
We therefore plot in Fig. 10 the maximum receiver throughput
on TelosB, MicaZ and iMote2 based on these values. Then Fig. 11
(top) shows the maximum measured receiver throughput for
these platforms using the MicaZ traffic generator. Our first experi-
ments on the TelosB and iMote2 used the same platform for the
sender. Then, we found the receiver throughput very close to the
sender throughput which showed that the limiting factor was at
the sender side. We then use a MicaZ sender which is the fastest
sending mote available to us and ran the experiments again. The
measured receiver throughput on the TelosB in Fig. 11(top) is for
this last case where we can see that TelosB and MicaZ have similar
receiving performances (the labels for the receiver throughput are
only for the MicaZ motes for clarity reasons).
Fig. 7. Minimum read time on WaspMote and Arduino.
when the minimum time between 2 packet generation is too
small, there are contention issues between receiving from the
source and relaying to the sink. This is depicted in Fig. 12 by the
gray block. However, as we found that the minimum time between
2 packet generation is much greater than the radio transmission
time (about 5 ms for a 100-byte packet), multi-hop transmissions in
this case will most likely rather suffer from high processing
latencies than from contention problem. Figure 13 shows that upon
reception of the packet from a source node, an intermediate needs
an additional delay to get data from the radio before being able to
send it to the next hop. This delay was referred to as the time to
read data, tread, and was found to be quite large in simple mote
architecture such as the WaspMote and Arduino (see Fig. 7).
In total, when adding additional data handling overheads
(tprocessing), we measured that a relay node based on a WaspMote
needs about 108 ms to process the incoming packet and to relay
it to the next hop, once again for a 100-byte packet. The Arduino
can do it in about 94 ms, see Fig. 14, red (WaspMote) and purple
(Arduino) curves. In case the next packet from the source node
arrives before the previous packet has been read, the reception
buffer may overflow quite quickly. On more elaborated OS and
processors, it is possible to have a multi-threaded behavior to
processed the received packet earlier but in this case contention
on serial or data buses need to be taken into account. In all
cases, we clearly see that in the best case the next packet will not
be sent before the return of the last send. We can see that multi-
Fig. 11. Maximum sending throughput and maximum measured receiver through- hop transmission on this type of platform adds a considerable
put on TelosB and MicaZ (top) and iMote2 (bottom). over- head that put strong constraints on data-intensive sending
appli- cations. Figure 15 shows the measured relay throughput
for both WaspMote and Arduino. We also plot the sending
throughput (WaspMote and Arduino have same level of
Figure 11 also shows the maximum realistic sending through- performance) and the receiver throughput previously shown in
put on the TelosB and MicaZ motes previously shown in Fig. 6 Fig. 8 for comparison purposes.
for comparison purposes. The bottom part of Fig. 11 is for the On the TelosB and the MicaZ we also measured the time
iMote2 mote. needed to receive a packet, from the time the frame delimiter
As we do not have the possibility to send with an 802.15.4 was received by the radio, to the time when relay has been
device packet faster than 1 packet every 11 ms (performance of performed (when the packet is notified to be sent). For each
the MicaZ platform), even with a 802.15.4 bridge plugged into a packet size, we receive and relay 20 packets, then the packet size
desktop workstation, at this point of our experimentation, we increases by 5 bytes, starting with an initial size of 10 bytes. The
cannot state for sure whether the receiving performance will be relay time for each packet is then shown in Fig. 16 for TelosB and
largely smaller than the theoretical maximum receiver Micaz (top) and iMote2 (bottom).
throughput as depicted in Fig. 10, or can be close to theoretical Figure 17 compares the theoretical relay time computed by
values. However, we can see in Fig. 11 that the receiver adding tread and tsend to the measured relay time obtained by
throughput starts to diverge from the sender throughput for averaging the 20 values for each packet size, for both the TelosB
large packet size therefore our opinion is that the maximum and the MicaZ (top) and iMote2 (bottom). We show again tread
realistic receiver throughput will be well below the theoretical for comparison purposes. The measured relay time in all cases is
maximum receiver throughput because of various overheads of very close to the theoretical value, therefore validating that data
the reception opera- tions: hardware interrupts, tasks handling, read time and data send time represent the main part of relaying
memory copy, etc. overheads.
Finally, Fig. 18 shows the various throughput for the TelosB
and MicaZ (top) and iMote2 (bottom): sending, receiver and
5. Relay performance in multi-hop scenario relay throughput. For the TelosB and the iMote2, as expected,
the relay throughput is limited by the sending throughput and
In data-intensive WSN such as multimedia motes, a large we can see that both curves are very close. On the MicaZ, the
amount of data are sent from sensor nodes to a sink or base relay throughput stay close to the receiver throughput for
station. This sink is not always the final destination because it packet size smaller than 45 bytes. In all our experiments, the
can also transmit the data to a remote control center, but it is MicaZ motes appeared again to be the most performant mote for
generally assumed that the sink has high bandwidth sending, receiving, and thus relaying, operations.
transmission capabil- ities. Figure 12 shows a detailed time Table 1 summarizes the main communication delays of the
diagram of a multi-hop transmission for a scenario of image various sensor motes we study in this paper. The last line
transmission as depicted by the camera field of view. We can see indicating the relay time is the most relevant for multi-hop
that all the sensor nodes along the path from the source node to transmission as a lower inter-packet time at the source will most
the sink do have the same constraints regarding the minimum likely make intermediate nodes storing packets in their reception
time between 2 packet generation. buffer with a high risk of packet dropping without any gain in the
Multi-hop transmissions generate higher level of packet losses transmission latency.
because of interference and contention on the radio channel
(uplink, from the source; and downlink, to the sink). In this case,
Relay node

APPLICATION APPLICATION
(SENDER) API radio API APP API radio medium (RCV)
medium (RLY)
Start
of send()
data 0

Return ack
from send()

data
Start
of send() 0 ack
data 1

ack
Return
from send() data 0

Time to get data from radio

Fig. 12. Multi-hop transmission of images.

1
tsend 1 tread tprocessing
trelay
tpkt
1
2

Fig. 13. Multi-hop communication overheads.

Fig. 14. Measured time to read and relay data on WaspMote and Arduino. (For
interpretation of the references to color in this figure caption, the reader is referred
to the web version of this article.)

6. Test-case: performance of still image transmissions


Fig. 15. Maximum sending throughput, receiver throughput and relay throughput
6.1. Image encoding on WaspMote and Arduino.

Transmitting images on WSN faces numerous constraints


such as transmission latency, energy efficiency and reliability.
proposed in Lecuire and Makkaoui (2012) which features the
For surveillance applications, it is not very tractable to increase
2 following key points:
reliability with retransmission mechanisms, and usage of redun-
dant information for error correction is very costly. Early studies
1. Image compression must be carried out by independent block
have confirmed that image communication needs to be especially
coding in order to ensure that data packets correctly received at
tolerant to packet losses (Yeo and Ramchandran, 2007) which
the sink are always decodable.
automatically make traditional JPEG compression scheme unsui-
2. De-correlation of neighboring blocks must be performed prior
table as it suffers from very high spatial correlation: an entire
to packet transmission by appropriate interleaving methods in
image could be impossible to decode with only a few packets
order to ensure that error concealment algorithms can be
missing. We therefore use an optimized encoding scheme
efficiently processed on the received data.
Fig. 16. Measured time to relay data on TelosB, MicaZ (top) and iMote2 (bottom).

Fig. 18. Maximum sending throughput, receiver throughput and relay throughput
on TelosB, MicaZ (top) and iMote2 (bottom).

Table 1
Summary of communication delays for a 100-byte packet.

Sensor platform WaspMote Arduino TelosB MicaZ iMote2

tsend (ms) 11 10 20.3 10.7 25.6


tpkt (ms) 16.3 13 25.3 11.5 24.5
tread (ms) 50 35 8 5 5
trly (ms) 108 94 28.1 15.7 29.9

Factor, of the compression ratio/energy consumption trade-off


while maintaining an acceptable visual quality in case of packet
loss. Figure 19 shows a 200 ~ 200 image with various quality
factor (Q).
We set the maximum image payload per packet to 90 bytes
because 4 bytes need to be reserved in the 802.15.4 payload for
storing image information such as the offset in the image of each
data packet received. Generated packet sizes are between 81 and
89 bytes thus the maximum packet size with the additional
header is 93 bytes. The number of generated packets, the total
size of the compressed image and the PSNR compared to the
Fig. 17. Measured time to read and relay data on TelosB, MicaZ (top) and iMote2
original image are shown in the figure. We can see that a quality
(bottom).
factor of 20 is visually still acceptable while providing a good
compression ratio of 6.14. This is the value for Q that we will
The compression scheme is referred to as a JPEG-like coder and
choose for the next experiments but one could imagine setting Q
proposes to operate on 8x8 pixel blocks with advanced optimiza-
according to network congestion level for instance. Smaller
~ size
tions on data computation to keep the computational overhead
such as 128 128 size can be used for critical surveillance
low. The combination of the fast JPEG-like proposed encoder with
applications, such as intrusion detection that need the lowest
an optimized block interleaving method (Duran-Faundez and ~
latency, while the 200 200 size can be used for a situation-
Lecuire, 2008) allows for an efficient tuning, the so-called Quality
awareness application which is less delay constrained.
Fig. 19. 200 ~ 200 image, typical of search&rescue applications.

Fig. 20. Left: Arduino Mega2560 for sending images stored in the SD card. Right: relay nodes, from left to right. TelosB, MicaZ and iMote2 (top) and Libelium WaspMote
and Arduino Mega2560 (bottom).

6.2. Experimental test-bed


connected to a Linux computer running the reception program
to receive the image packets and display the image. Figure 20
The experiment uses 1 source node consisting of an Arduino
(right) shows the 5 types of relay nodes.
Mega2560 with an XBee module connected to the
microcontroller at 125,000 bps. The images are stored on an SD
6.3. Experimental results
card and we can dynamically select which file is going to be
sent, see Fig. 20(left). The image file is fragmented in a number
The experiment consists in using 2 homogeneous motes as
of packets according to the encoding scheme. We choose a
relay nodes between the sender and the receiver, thus giving a
quality factor of 20 that presents an acceptable quality for a
4-hop transmission scenario. According to the previous studies,
small image size, see Section 6.1. When the sending is triggered,
Table 2 shows in the trly line the minimum relaying time for a 95-
we can choose the time between 2 packet generation.
byte packet. We will start by setting the inter-packet time at the
We then use our 5 relay node platforms: Libelium WaspMote
Arduino sender (noted tS 0 in Table 2) greater than the minimum
and Arduino Mega 2560, both with an XBee module (once again
relay time of each sensor platform and then reduce the inter-
the XBee module is connected to the micro controller at
packet time to see the impact on image reception quality. Except
125,000 bps), TelosB, MicaZ and iMote2, all three with a CC2420
for the MicaZ relay nodes, the various values for the inter-
radio. These relay nodes are programmed to relay incoming
packet time are noted tS 0 to tS 3. With the MicaZ, only 2 inter-
packets to the sink which is, in our case, an XBee module
packet time are used at the sender, 20 ms and 15 ms, because
(i) as shown
Table 2
Summary of inter-packet time used at the sender node.

Platform WaspMote Arduino TelosB iMote2 MicaZ

95B 105 90 27.8 29.5 13.7


trly (ms)
tS 0 (ms) 110 (8.37–10.46) 95 (7.23–9.03) 35 (2.67–2.73) 35 (2.67–2.76) 20 (1.53–1.56)
tS 1 (ms) 105 (7.99–10.11) 90 (6.85–8.66) 30 (2.29–2.35) 30 (2.29–2.36) 15 (1.15–1.18)
tS 2 (ms) 90 (6.85–8.96) 75 (5.71–7.52) 20 (1.53–1.58) 20 (1.53–1.60) –
tS 3 (ms) 80 (6.09–8.20) 65 (4.95–6.76) 15 (1.15–1.22) 15 (1.15–1.21) –

Fig. 21. Reception quality of a 200 ~ 200 image.

previously, this platform is the fastest in terms of relaying


image, compressed into a file of size 6236 bytes can be sent and
capabilities and (ii) it is not really possible to send packets with
relayed with 2 intermediate MicaZ nodes in about 1.18 s making
an inter-packet time smaller than 13 ms with the sender Arduino
critical surveillance applications such as intrusion detection pos-
board. Then, the left value in parenthesis is the sending time while
sible. One can decrease the quality factor or send faster at the
the right value is the image reception latency with 2 relay nodes,
cost of packet drops to have much smaller transmission time:
both values are in seconds. We obtained these values with a ¼
with Q 10 and 15 ms inter-packet time, the image can be sent
promiscuous sniffer node (TelosB) plugged into the wireshark
and relayed in less than 1 s. For situation-awareness
packet analysis tool.
applications, assuming a optimized scheduling strategy for the
Figure 21 shows for the 200 ~ 200 rescue image an example of
image nodes we can assume that a control center can get 100
the typical various reception quality for tS 0 to tS 3 on the various
images from 100 different locations in about 2 min. Although
platforms, except the MicaZ. Here, for an inter-packet time
these results could be improved by a number of optimizations to
greater than tS 0, the image is received with very few packet
grab a few ms on the same hardware platforms, we believe that
losses or corrupted packets. With Arduino relay nodes the time
these values are quite typical of what can be found on existing
to send the image
¼ at tS0 95 ms is about 7.23 s with a reception
sensor boards and radio modules. At least, it is much more
latency of about 9.03 s. This latency can decrease to about 7.52 s
realistic than assuming only the cost of radio transmission as it
when using tS2 ¼ 75 ms between each packet at the cost of more
is usually the case in many simulation studies.
packet drops. With iMote2 as relay nodes and tS1 ¼ 30 ms the
One source of high improvement can however come from the
image can be sent in about 2.29 s with a reception latency of
relay node: we use in our experiments an application-level
about 2.36 s. For the MicaZ nodes as relays, we have the highest
relaying feature. It means that the packet must go up to the
quality corresponding to tS 0 and tS 1 and the image latency can
application level to then be re-transmitted. If the relaying is
be as low as 1.18 s.
performed at the MAC layer as some radio firmware allows it,
such as the DigiMesh firmware available on the XBee module, the
6.4. Discussions relaying time could be greatly reduced. We could not however
tested this feature of DigiMesh because it was not possible to
We found the best performance for the MicaZ platform: accurately perform separate timing measures of the MAC relaying
about 15 ms between 2 packets makes this platform very mechanism and of the AODV-based embedded routing protocol.
attractive for fast sending and relaying. With the image test-
case, the 200 ~ 200
A more general solution could be to perform the relaying not at
Acknowledgments
the MAC level but once the packet is stored in the reception buffer
at the lowest level of the sensor board API or OS. In all these cases,
we can save the time to fetch the data from the reception buffer to This work is partially supported by the Aquitaine-Aragon
the application. OMNIDATA project. Congduc Pham would like to thank Vincent
Lecuire from CRAN laboratory for providing the optimized image
We chose to not address the overhead for capturing and
encoding technique.
compressing the image. In practice, in addition to the commu-
nication latency, each image adds a processing delay to get image
data from the camera, to compress the image and to build the
image packet. Our rationale for not having addressed these issues References
is because there is a very large range of possibilities, connection
technologies (SPI, I2C, dedicated) and some specific hardware can AdvanticSys, 〈http://www.advanticsys.com/〉 [accessed 27.05.2014].
Arduino, 〈http://arduino.cc/en/main/arduinoboardmega2560〉 [accessed 27.05.2014].
also speedup the compression scheme. Moreover many camera Chen P, Hong K, Naikal N, Sastry SS, Tygar D, Yan P, et al. A low-bandwidth camera
boards have the possibility to perform some processing task sensor platform with applications in smart camera networks. ACM Trans Sens
independently from the main microcontroller. Netw 2013;9(2).
CrossBow, 〈http://bullseye.xbow.com:81/products/product_pdf_files/wireless_pdf/
telosb_datasheet.pdf〉 [accessed 27.05.2014].
CrossBow, 〈http://bullseye.xbow.com:81/products/product_pdf_files/wireless_pdf/
7. Conclusions
micaz_datasheet.pdf〉 [accessed 27.05.2014].
Cucchiara R, Prati A, Vezzani R, Benini L, Farella E, Zappi P. Using a wireless sensor
Data-intensive applications such as those involving images network to enhance video surveillance. J Ubiquitous Comput Intell 2007;1(2). Digi,
or acoustic data on wireless sensor networks are becoming more 〈http://www.digi.com/products/wireless-wired-embedded-solutions/zigbee-
rf-modules/〉 [accessed 27.05.2014].
and more desirable for a number of surveillance applications. In Duran-Faundez C, Lecuire V. Error resilient image communication with chaotic
this paper, we presented experimentations with various pixel interleaving for wireless camera sensors. In: Proceedings of ACM work-
commonly found sensor boards and radio modules to highlight shop on real-world wireless sensor networks; 2008.
Evidence Embedding Technology, Seed-eye board, a multimedia WSN device,
the main sources of delays assuming no flow control nor
〈http://rtn.sssup.it/index.php/hardware/seed-eye〉 [accessed 27.05.2014].
congestion control. The purpose of the study is to determine the Foster J. Xbee cookbook issue 1.4 for series 1 (freescale) with 802.15.4 firmware,
best case perfor- mance level that could be expected when 〈www.jsjf.demon.co.uk/xbee/xbee.pdf〈 [April 26th, 2011. Accessed 27.05.2014].
considering IEEE Hengstler S, Aghajan H. WiSnap: a wireless image sensor network application
platform. In: Proceedings of COGnitive systems with Interactive Sensors; 2006.
802.15.4 multi-hop connectivity. We showed that there are IEEE, IEEE STD 802.15.4-2011; 2011.
incompressible delays due to hardware constraints and software Lecuire V, Makkaoui L, Moureaux J-M. Fast zonal DCT for energy conservation in
API that limit (i) the time between 2 successive packet send and wireless image sensor networks. Electron Lett 2012;48(2).
Libelium, 〈http://www.libelium.com/〉 [accessed 27.05.2014].
(ii) the receiver throughput. We found that typical sending Libelium, 〈http://www.libelium.com/top_50_iot_sensor_applications_ranking/〉 [accessed
throughput is about 50kbps for the WaspMote and Arduino motes, 27.05.2014].
and about 32kbps and 70kbps for TelosB and Micaz motes Misra S, Reisslein M, Xue G. A survey of multimedia streaming in wireless sensor
networks. IEEE Commun Surv Tutor 10. 2008.
respectively. Even if WaspMote and Arduino motes can send data
Paniga S, Borsani L, Redondi A, Tagliasacchi M, Cesana M. Experimental evaluation
faster than a TelosB, both are much more limited for data of a video streaming system for wireless multimedia sensor networks. In:
reception. TelosB and MicaZ have reception throughput of about Proceedings of the 10th IEEE/IFIP Med-Hoc-Net; 2011.
67kbps while WaspMote and Arduino merely reach 16kbps and Rahimi M, Baer R, Iroezi OI, Garcia JC, Warrior J, Estrin D, et al., Cyclops: in situ
image sensing and interpretation in wireless sensor networks. In: ACM
23kbps respectively. In all our experiments, the MicaZ motes SenSys; 2005.
appeared to be the most performant mote for sending, receiving, Rapp A. 〈http://code.google.com/p/xbee-arduino/〈 [accessed 27.05.2014].
and thus relaying, operations. Rinner B, Wolf W. Toward pervasive smart camera networks in Multi-Camera
Networks. In: Hamid Aghajan, Andrea Cavallaro, editors. Academic Press; 2009.
Our contributions can also be used for building realistic
p. 483–96 chapter 20.
simulation models. Also, by identifying the limitations and the Salvadori C, Petracca M, Madeo S, Bocchino S, Pagano P. Video streaming applica-
bottleneck, more suitable control mechanisms could be studied tions in wireless camera networks: a change detection based approach targeted
and proposed. For instance, while flow control and congestion to 6LoWPAN. J Syst Archit, SI Smart Camera Arch 2013;59(10, Part A):859–69.
SmartSantander, 〈http://www.smartsantander.eu〉 [accessed 27.05.2014].
control are of prime importance we believe that traditional Soro S, Heinzelman W. A survey of visual sensor networks. Adv Multimed. 2009.
approaches based on buffer management or rate control are not Tavli B, Bicakci K, Zilan R, Barcelo-Ordinas JM. A survey of visual sensor network
efficient because they will add to much latency that is not platforms. Multimed Tools Appl 2012;60(3):689–726.
Texas Instrument, 〈http://www.ti.com/lit/gpn/cc2420〉 [accessed 27.05.2014].
compatible with surveillance applications. Our further works,
TinyOS, 〈http://www.tinyos.net/〉 [accessed 27.05.2014].
based on the results presented in this paper, will rather propose Yeo C, Ramchandran K. Robust distributed multi-view video compression for
to have scheduling mechanisms to explicitly prevent nodes from wireless camera networks. In: Proceedings of SPIE visual communications
sending packets at the same time in the same area. and image processing; 2007.

Vous aimerez peut-être aussi