Professional Documents
Culture Documents
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
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.
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
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
1
tsend 1 tread tprocessing
trelay
tpkt
1
2
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.)
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.
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).