Sensornetze - Institut für Informatik

Transcrição

10. Fachgespräch
Sensornetze
der GI/ITG Fachgruppe Kommunikation und Verteilte Systeme 15.‐16. September 2011 Technischer Bericht
TR‐RI‐11‐313 Jun.‐Prof. Dr. Hannes Frey (Hrsg.) KuVS
Institut für Informatik
Warburger Str. 100
33098 Paderborn
Inhaltsverzeichnis Session 1 – Lokalisierung Towards Autonomous Indoor Flights Using Wireless Sensor Network Based Localization ....... 01 Jürgen Eckert, Falko Dressler Distribute & Erase, a Self‐Calibration Algorithm for Ultrasound Based Localization Systems .. 005 Armin Runge, Marcel Baunach, Reiner Kolla Ein adaptives Vorhersagemodell für Signalstärken in einem Funknetzwerk ............................. 09 Christian Huisinga, Jens Kamenik Session 2 ‐ Hardware Plattformen SuperG: A Multi‐Radio Architecture to interconnect multiple Wireless Sensor ........................ 13 NetworksClemensMühlberger, Tobias Schäfer Wireless Sensor Actor Nodes for theBuilding Automation ........................................................ 17 Hannes Frey, Rafael Funke, Marcus Autenrieth, Harald Mundinger, Peter Detzner, Roland Groll 21 We Must Move ‐ We Will Move: On Mobile Phones as Sensing Platforms ............................... 25 DelphineChristin, Matthias Hollick INGA ‐ Architektur eines universell einsetzbaren Sensorknotens ..............................................
Ulf Kulau, Felix Büsching, Wolf‐Bastian Pöttner, Lars Wolf Poster‐Session: MAC, Kommunikation, Entwicklung, Anwendung Reasons for priority‐based Medium Access in Wireless Sensor Networks ................................
Alexander Klein, Lothar Braun 29 QoS‐Routing und Reservierungen in mobilen Ad‐Hoc‐Netzwerken ...........................................
Anuschka Igel, Reinhard Gotzhein 33 Kommunikationsanforderungen in zukünftigen Ad‐Hoc‐Netzwerken .......................................
Dennis Christmann, Reinhard Gotzhein 37 Energy Profiling for Wireless Sensor Networks ..........................................................................
Oliver Hahm, Stephan Adler, Nicolai Schmittberger, Mesut Günes 41 Simulationsgestützte Algorithmenentwicklung für drahtlose Sensornetze ..............................
Stefan Lange, Oliver Stecklina, Michael Methfessel 45 On the Integration of Wireless Sensor Networks and Smartphones in the Logistics Domain …
Sebastian Zöller, Andreas Reinhardt, Heiko Guckes, Dieter Schuller, Ralf Steinmetz 49 Session 3: Energieeffizienz Implementation and simulation of an energy‐efficient cluster‐based wireless sensor network ........................................................................................................................................
Volker Delport, Mario Gessner, Toni D. Grossmann, Adrian Singer 53 Utilizing Voltage Decline for Reaching Lifetime Goals ................................................................
André Sieber, Jörg Nolte 57 Session 4: Sicherheit A Secure Monitoring and Control System for Wireless Sensor Networks .................................
Michael Riecker, Walther Müller, KarstenSaller, Matthias Hollick 61 Vertrauenswürdige drahtlose Sensornetze in sicherheitsrelevanten Einsatzszenarien ….........
Björn Stelte 65 Security for PracticalCoAPApplications: Issuesand Solution Approaches ..................................
Martina Brachmann, Oscar Garcia‐Morchon, Michael Kirsche 69 Session 5: Anwendungen / Virtuelle Maschinen Zellenweiser Messbetrieb, Vorverarbeitung und drahtlose Kommunikation bei Fahrzeugbatterien ........................................................................................................................
Sergej Ilgin, Niels Jegenhorst, Raik Kube, Simon Püttjer, Karl‐RagmarRiemschneider, Matthias Schneider, Jürgen Vollmer 73 Efficient Power Management Using Out‐of‐Band Signaling …....................................................
Tobias Vaegs, Muhammad Hamad Alizai, Jó Ágila Bitsch Link, Klaus Wehrle 77 Wireless Sensor Network‐Based Asset Management for Mobile Measurement Devices ......... 81 Helena Preiss, Sebastian Lempert, Christopher Kaffenberger, Alexander Pflaum TakaTuka ‐ Java for Wireless Sensor Motes ................................................................................
Christian Schindelhauer, Faisal Aslam, ZartashUzmi 85 Towards Autonomous Indoor Flights Using
Wireless Sensor Network Based Localization
Juergen Eckert∗ , Reinhard German∗ and Falko Dressler†
∗ Dept.
of Computer Science, University of Erlangen, Germany
of Computer Science, University of Innsbruck, Austria
{juergen.eckert,german}@cs.fau.de, [email protected]
† Institute
Abstract—Indoor hovering objects such as quadrotors need to
continuously be controlled to hold their position in space. For real
autonomous flight of these copters, the necessary position control
including all related information transfers have to be provided
in a fully decentralized and autonomous manner. We discuss
challenges related to flight control based on our Autonomous
Localization Framework (ALF), which provides scalable and
decentralized localization in GPS-denied areas. Using a sensor
network based on the IEEE 802.15.4 communication protocol,
continuous position maintenance is feasible but, unfortunately,
in no way stable. Therefore, we introduce a sensor array, which
reduces the system dynamics and allows a robust position control
of the platform.
scope of this paper, we rely on our ALF framework, which,
to the best of our knowledge, is the first platform fulfilling all
the requirements for a real autonomous indoor flying system;
including the necessary sensor deployment and information
acquisition.
II. AUTONOMOUS L OCALIZATION F RAMEWORK
Our Autonomous Localization Framework (ALF) has been
designed to fulfill the task of providing a zero-effort accurate
localization system for autonomously flying robots [3]. However, it is not exclusively restricted to this. The framework
satisfies several requirements, low cost being probably the most
I. I NTRODUCTION
important one. This is the main reason why we not built-up
Six degrees of freedom need to be controlled continuously a SLAM approach (usually expensive laser distance scanners
for motion in the three-dimensional space. The usual fall back would be needed). Furthermore, the framework should be able
mechanism for unsolvable problems in the field of robotics is to operate with minimal computational power.
simply to stop. This, of course, can not be applied during the
ALF has been designed as a decentralized system without
flight of an Unmanned Aerial Vehicle (UAV). In this paper,
any synchronization or global knowledge and a finite amount
we are focusing on a UAV subclass, the so called vertical
of energy. The typical operation scenario is depicted in
take-off and landing (VTOL) devices. They are most suited for
Figure 1. Sensor nodes need to be capable of detecting and
our indoor usage scenario. Here, however, not much space for
communicating with their direct neighbors; no special routing
maneuvering is available, which forces the platform to mostly
information or topology is required. For localization, at least
remain in the most unstable condition: hovering. Serious selfthe distance to the neighbors needs to be measurable. As we
caused air turbulences additionally affect the flight stability.
desire an accurate localization system, we do not rely on rather
Copters (classical, coaxial, quad, etc) are basically controlled
vague Received Signal Strength Indicator (RSSI) measurements
the same way. The forward/back and left/right axes get
(although it would be possible [4]). Our ground platform [5]
indirectly controlled by pitch and roll, respectively. Applying
is equipped with an ultrasound based Time of Flight (ToF)
a constant angle, different from zero, to an axis will cause the
measuring hardware. It reports distances with an observational
platform to move into this direction with increasing speed. This
error of less than ±2 cm. A byproduct is a rough estimation
reduces the amount of independent degrees to four: pitch, roll,
of the angle to a neighbor (±45◦ ), which is sub sequentially
yaw, and altitude (also indirectly controlled by thrust). Even
also used but not required. The mobility is a key feature of a
if it would be possible to perfectly control the pitch and roll
truly autonomous system but not required for ALF.
axes, the system would still move according to Newton’s first
law of motion. Moreover, each disturbance in the air results
in an on-board unpredictable and unmeasurable movement. To
counteract such involuntary movement, a guidance system is
needed to continuously control the position – otherwise the
system would quickly crash into walls or other obstacles.
Indoor position controlling approaches for flying objects
based using localization systems [1] or Simultaneous Localization and Mapping (SLAM) [2] already exist. However, they
either depend on a highly accurate and expensive localization
system that needs to be deployed manually; or they need a
Fig. 1. Autonomous Localization Framework scenario [3]
high amount of (mostly off-board) computing power. In the
1
We evaluated the system performance in a lab experiment:
Nine nodes were placed on the floor to build up a coordinate
system. We simulated a customer by a sensing device on a
stick (fixed altitude) mounted on a toy train. Two different
experiments were evaluated: Line of Sight (LOS) and NLOS
measurements. For the latter one, obstacles were placed
into the testbed. These obstacles introduced incorrect NLOS
measurements with a probability of PNLOS ≈ 30 % (this value
is commonly reported in the literature [8]).
Due to the lack of a more accurate localization system,
the error of the generated absolute position was not directly
measurable. However, Figure 2 shows the altitude error of the
experiment. All the results are shown in form of boxplots: The
thick line represents the median, the rectangular boxes contains
50 % of the measurements, the boundaries are indicating the
25 % and 75 % quantiles. The circles show statistical outliers.
The dashed red lines are indicating the hardware sensing
accuracy of ±2 cm. It can be seen that at least 50 % of the
measurements of both experiments are within that range. A
maximum error of ±20 cm and ±40 cm can be given for the
LOS and for the NLOS experiment, respectively.
IV. C OMMUNICATION
As stated before, ALF relies on simple direct neighbor
communication. When a customer wants to know its position
it triggers an active ultra sound measurement. The sound pulse
is received by the ground nodes. This flight duration needs to
be reported back, using the radio, to conclude to a position.
We used SunSpot nodes in our experiments. These systems
operate an IEEE 802.15.4 [9] compatible Chipcon CC2420
interface for wireless communication. The primary design goals
2
-0.4
Altitude Error in m
-0.2
0.0
0.2
NLOS
Experiment
Fig. 2.
Customer localization accuracy
80
III. S YSTEM ACCURACY
LOS
Duration in ms
100 120 140 160 180 200
First (step 1 in Figure 1) each node needs to find a
“convenient” place, which is a trade-off between area coverage,
accuracy, and cost. As no global knowledge exists, each node
needs to find this independently from the states of its neighbors.
A local decision table based approach is used. Afterwards (step
2), the node localizes itself according to an already existing
reference grid [6]. Using this information as an initial position,
the node joins the reference network and enters the maintenance
and correction process, which is based on our Advanced MassSpring-Relaxation (advMSR) approach [7]. Again, only local
information are used.
In this process, as typical for indoor scenarios, many Non
Line of Sight (NLOS) measurements may happen. In order
not to corrupt the system those need to be detected and
blacklisted [3]. The algorithm was designed so that it reaches
convergence. At any point in time, nodes are allowed to join
or leave the network. Reason for leaving might be unsatisfied
system parameters or the depletion of the battery. Finally (step
3), the nodes and the generated position information are used
as a reference grid for providing a localization support for
customers [6], such as the autonomously flying copters. The
trilaturation-based scheme was specially designed to fulfill
real-time requirements.
3
4
5
Fig. 3.
6 7 8 9 10 11 12
Reference nodes
Communication Latency
of this interface were energy efficiency and scalability. High
latency and low bit rates were accepted, but low-latency support
has been worked on for this protocol [10], [11], but completely
different low latency MAC approaches might be even more
suitable [12]). However, we intended to stick to the default
setup to show the general applicability of ALF. We showed
that a custom agent based application layer protocol can collect
the information in time [6]. It performs significantly better than
a pure broadcast based approach.
In an experiment we placed three to twelve ground nodes
around one customer. We measured the required time for
collecting enough measurement tuples to robustly determine
the customer’s position. The results are plotted in Figure 3.
Three is the minimum number of reference nodes required for
g
0.15
1
u
VI. O PTICAL S ENSOR
α
a
1
1
v
Fig. 4.
x
System model of a copter
trilaturation. The red dashed line shows the upper border of a
time slot, which must not be exceeded by all means. The red
rhombi are showing the mean values. It can be seen that the
slot boarder is never crossed and that the duration significantly
decreases for five and more nodes. This is because we stop the
collection process prematurely, because five tuples are enough
to robustly compute a position [6]. On the average, it takes
100 ms to 160 ms to complete the data collection. No outliers
exceeded the 200 ms border.
V. C ONTROL T HEORY
In order to reduce system dynamics and to have a temporary
fall back mechanism, we currently experiment with an optical
flow sensor. These sensors are very low cost, low power, and
light-weight, typically also installed in computer mice, with an
adjusted lens. They have already been identified as suitable for
this application [13]. Usually this sensor is facing downwards
to the floor and controls the speed on the forward/back and
left/right axes. Before the velocity control can do its work, two
more things are required: The altitude, which is rather simple
to obtain, is needed to derive the moved distance.
More important and but even more difficult to estimate is
the nick and roll angle on the copter. As the platform tilts to
move and the sensor is rigidly mounted to the frame, it detects
a relatively high movement into the inverse direction of the
actual movement (see Figure 5(b)). This is counter-productive
and needs to be compensated by the knowledge of the current
slant. However, this is very time critical and the angles need
to be very accurate, especially for large altitudes. Therefore,
we are planing to exploit a unique feature of indoor flights:
Rooms not only have floors but also ceilings. Thus, we use
one down and one up facing sensor. This way the angle of the
platform can be neglected.
Figure 5(a) depicts one axis of a quadrotor hovering at
time t. The current tilting αt usually needs to be known, but
the absolute value is not important. It additionally knows the
distances to the floor df and to the ceiling dc . If the room
height h is known, dc = h − df needs not to be measured. In
Figure 5(b), the quadrotor has a different tilting αt+1 and has
also moved a distance ∆x. However, the up facing sensors
reports the distance ∆xc and the down facing one reports
∆xf . NB: For improved visualization the values are already
normalized according to the resolution of the sensor and the
distance to the surface.
The common approach is now just to use the down facing
sensor, which might report a movement into the negative
direction as depicted in Figure 5(b). An inclination correction
can be calculated as
From a control theory point of view, we approximated the
system of the roll and nick axes as depicted in Figure 4. Both
axes can be controlled independently from each other. The
system input u is tilt information, given in radian. The platform
tries to reach this value by tilting. Due to inertia this takes
some time (150 ms on our platform). We approximated this
using a first order lag element. Now, considering that it hovers
in the air |Fweight f orce | = |Flif t | and only very small angles
are applied, it is sufficient to multiply the previous outcome
with the gravitational acceleration g to get an acceleration into
the direction of the axis. By double integrating the value a
position x is obtained, which, can be measured by ALF.
This system could be stabilized by a classical PD controller.
Due to the previously mentioned communication latency
∆x = ∆xf − df tan ∆α,
(1)
the control frequency is fairly low (5 Hz). However, results
reported in the literature indicate that under optimal conditions where ∆α = αt+1 − αt .
stabilization is still doable [1]. By moving from the classical
It can be seen that for large df accurate tilting information
continuous to a time discrete perspective and by utilizing a state- is mandatory and needs to be measured with a high resolution.
space position controller, we tried to overcome the tremendous Unfortunately, tilting information in general is very hard
delay time of the communication channel. Still, the total delay to obtain on such dynamic systems. The relative distance
time of up to 195 ms (including measurement, information movement ∆x is normally in the range of a few millimeters
transport and computation) made the system very susceptible. (due to high sampling rates), whereas the average flight height
The slightest measurement or communication error results df is usually in the range of 1 m to 2 m. That clearly shows
in an overshoot, potentially followed by a crash. We see two the error-proneness of this approach. NB: It is assumed that
possible solutions to this problem: (a) A significant reduction of the platform is only doing minor inclinations, i.e., αt is always
the communication latency (e.g., a different MAC layer [12]). nearly orthogonal to the floor (see Figure 5(a)).
(b) A reduction of the system dynamic of the customer. We
We are about to circumvent the evaluation of the tilting
chose to rely on the second option following our discussions angle by placing an additional sensor on top of the platform.
ob the communication hardware options.
Using the intercept theorem gives us the following angle free
3
∆xc
∆x
dc
dc
h
h
αt
df
df
∆α
xt
xt
∆xf
x
Fig. 5.
Quadrotor movement
equation for the platform movement ∆x:
(2)
In case of an undetectable surface (no contrasts) on one
sensor, the fall back to the others in combination with the
standard angle based approach (Equation 1) provides a second
safety stage.
VII. C ONCLUSION
We briefly introduced a scalable, real-time capable localization framework using sensor network technology. It is
fully aware of scenario driven limitations such as energy
and computing power boundedness. Additionally it does not
require synchronization, routing information or any other global
knowledge. As shown it is mostly (P ≈ 50 %) as accurate as
the utilized sensing hardware.
However, due to measurement outliers in combination
with the communication time lag we were not yet able to
continuously stabilize the quadrotor. After reducing the system
dynamic of the copter by the use of the optical flow sensor, the
Autonomous Localization Framework will be able to stabilize
the platform permanently.
R EFERENCES
[1] D. Gurdan, J. Stumpf, M. Achtelik, K.-M. Doth, G. Hirzinger, and D. Rus,
“Energy-efficient Autonomous Four-rotor Flying Robot Controlled at 1
kHz,” in IEEE International Conference on Robotics and Automation
(ICRA 2007). Roma, Italy: IEEE, April 2007, pp. 361 –366.
[2] S. Hochdorfer and C. Schlegel, “6 DoF SLAM using a ToF Camera:
The Challenge of a Continuously Growing Number of Landmarks,” in
IEEE/RSJ International Conference on Intelligent Robots and Systems
(IROS 2010). Taipei, Twaiwan: IEEE, October 2010, pp. 3981–3986.
[3] J. Eckert, R. German, and F. Dressler, “ALF: An Autonomous Localization Framework for Self-Localization in Indoor Environments,” in
7th IEEE/ACM International Conference on Distributed Computing in
Sensor Systems (DCOSS 2011). Barcelona, Spain: IEEE, June 2011.
4
x
(b) Time t + 1
(a) Time t
∆xc − ∆x
dc
=
∆x − ∆xf
df
xt+1
[4] K. Chintalapudi, A. P. Iyer, and V. N. Padmanabhan, “Indoor Localization
Without the Pain,” in 16th ACM International Conference on Mobile
Computing and Networking (MobiCom 2010). Chicago, IL: ACM,
September 2010, pp. 173–184.
[5] J. Eckert, K. Koeker, P. Caliebe, F. Dressler, and R. German, “Selflocalization Capable Mobile Sensor Nodes,” in IEEE International
Conference on Technologies for Practical Robot Applications (TePRA
2009). Woburn, MA: IEEE, November 2009, pp. 224–229.
[6] J. Eckert, R. German, and F. Dressler, “An Indoor Localization Framework for Four-rotor Flying Robots Using Low-power Sensor Nodes,”
IEEE Transactions on Instrumentation and Measurement, vol. 60, no. 2,
pp. 336–344, February 2011.
[7] J. Eckert, F. Villanueva, R. German, and F. Dressler, “Distributed
Mass-Spring-Relaxation for Anchor-free Self-localization in Sensor
and Actor Networks,” in 20th International Conference on Computer
Communication Networks (ICCCN 2011). Maui, HI: IEEE, July/August
2011.
[8] R. Casas, A. Marco, J. Guerrero, and J. Falco, “Robust Estimator for
Non-Line-of-Sight Error Mitigation in Indoor Localization,” EURASIP
Journal on Applied Signal Processing, vol. 2006, pp. 1–8, 2006.
[9] “Wireless Medium Access Control (MAC) and Physical Layer (PHY)
Specifications for Low Rate Wireless Personal Area Networks (WPANs),”
IEEE, IEEE Standard 802.15.4-2006, 2006.
[10] F. Chen, R. German, and F. Dressler, “Towards IEEE 802.15.4e: A
Study of Performance Aspects,” in 8th IEEE International Conference
on Pervasive Computing and Communications (PERCOM 2010), 2nd
IEEE International Workshop on Information Quality and Quality of
Service for Pervasive Computing (IQ2S 2010). Mannheim, Germany:
IEEE, March 2010, pp. 68–73.
[11] A. Koubaa, M. Alves, B. Nefzi, and Y.-Q. Song, “Improving the IEEE
802.15.4 Slotted CSMA/CA MAC for Time-Critical Events in Wireless
Sensor Networks,” in 5th International Workshop on Real-Time Networks
(RTN 2006), Dresden, Germany, July 2006.
[12] D. Carlson and A. Terzis, “Flip-MAC: A Density-Adaptive ContentionReduction Protocol for Efficient Any-to-One Communication,” in 7th
IEEE/ACM International Conference on Distributed Computing in Sensor
Systems (DCOSS 2011). Barcelona, Spain: IEEE, June 2011.
[13] S. Lange, N. Sunderhauf, and P. Protzel, “A vision based onboard
approach for landing and position control of an autonomous multirotor
UAV in GPS-denied environments,” in IEEE International Conference
on Robotics and Automation (ICRA 2009), Kobe, Japan, June 2009, pp.
1–6.
Distribute & Erase, a Self-Calibration Algorithm for
Ultrasound Based Localization Systems
Armin Runge, Marcel Baunach and Reiner Kolla
Department of Computer Engineering, University of Würzburg, Germany
Email: {runge,baunach,kolla}@informatik.uni-wuerzburg.de
Abstract—Most indoor localization systems are based on static
sensor nodes with known position. By means of this infrastructure
and measured distances to the static nodes, mobile nodes can
localize themselves. But a major problem is the manual position
determination of all static sensor nodes, since this procedure is
time consuming and fault-prone. In this paper, we present Distribute & Erase, a self-calibration algorithm for ultrasound based
localization systems. Distribute & Erase calibrates progressively,
is fault tolerant, and achieves an accuracy of millimeters.
wheels. Since this method presupposes a special mobile vehicle it is also prone to slippage of the tires.
In contrast to the mentioned approaches, we present a precise self-calibration method for ultrasound based sensor networks, which just requires small, cheap, and energy-efficient
sensor nodes.
I. I NTRODUCTION
To apply our Distribute & Erase (D&E) algorithm only few
pre-conditions must be fulfilled. Not a single pre-calibrated
anchor is required if relative positions are sufficient for the
underlying localization system. If absolute position estimations
are required, two (for 2D calibration) or three (for 3D calibration) pre-calibrated anchors at fixed positions are needed. The
pre-calibration corresponds to the specification of the origin
and orientation of the local coordinate system within the global
coordinate system.
Distribute & Erase calibrates the anchors through the gradual improvement of the estimated positions. The anchors’
estimated initial positions can be chosen randomly. However,
as trilateration is used for all localizations, the positions used
for a localization must not be collinear. The mobile nodes can
take arbitrary positions for distance measurement, too, as long
as each anchor measures a sufficient number of distances.
The required time for a localization step depends strongly
on the time of the data aggregation. To achieve a high
localization frequency, the data must be packed tightly. To
ensure a minimal and predictable transfer time and to avoid
mutual interference, the TDMA (time division multiple access)
communication protocol HashSlot [8] is used. HashSlot assigns an exclusive transmission slot to each anchor. HashSlot
requires that the anchors are arranged roughly along a grid
because the slot number relies on each anchor’s known cell,
and is calculated by each anchor autonomously. In the case of
uncalibrated anchors, the anchors’ cells must be determined.
But as an anchor cell is usually few square meters in size,
the effort is not high and no special equipment like a laser
distance measurement system is required.
So, if HashSlot is used to control the transmission of the
radio packets, every anchor just has to know its anchor cell.
D&E employs this precondition for successive calibration of
all anchors. While D&E can also be used with other MAC
protocols, like CSMA-CA, this reduces the calibration speed
remarkably.
Ultrasound (US) based localization systems are an important
research area within the WSN domain. This is the reason
why various such systems exist, like Cricket [1], AHLoS
[2], or SNoW Bat [3]. But a common problem of anchor
based localization systems is the determination of the anchors’
positions. Our objective was to find a self-calibration method,
which achieves an accuracy of millimeters and requires no
further hardware. Several self-calibration approaches are based
on distance measurement between anchor nodes, such as the
method introduced by Capkun et al. [4]: Local coordinate
systems are generated for each anchor and then are joined
together to a global coordinate system. As the distances in our
real world localization system are measured by TDoA (time
difference of arrival) between ultrasound and radio signals
emitted by a mobile node and received by an anchor, a distance
measurement between two anchors is not feasible without
adaption of our hardware.
A GPS-based method was provided by Sichitiu and Ramadurai [5]: Instead of equipping each node with an expensive
GPS-receiver, just one mobile node with GPS was used. The
positions of the static anchors were determined using the
distances between the anchors and the mobile node. However,
GPS-based methods are not suitable for indoor localization
because of the unreliable reception of GPS signals inside
buildings. The achievable localization accuracy of 1-2 m is
insufficient for us, too.
A higher accuracy was achieved by Moses et al. [6] through
the use of sensors measuring both the direction-of-arrival
(DOA) and the time-of-arrival (TOA). But the sensor nodes
used in our localization system can not measure the DOA
without expensive hardware modification.
Menegatti et al. investigated the capability of WSNs and
AMRs (autonomous mobile robots) for calibration [7]: They
introduced a self-calibration method with an AMR that determines its position through odometers attached to the driving
II. R EQUIREMENTS
5
III. D ISTRIBUTE & E RASE
This section introduces our self-calibration algorithm Distribute & Erase, which can replace the manual calibration
process. For the rest of this paper, pi,real denotes the real
position of an anchor ai with i ∈ {1, . . . , n}, and pi,est
denotes the estimated position of anchor ai . Anchor ai ’s grid
cell is herein referred to as Ai . In order to simplify, we assume
just one single mobile node m with real position pm,real , and
estimated position pm,est respectively.
A localization is initiated by the mobile node by sending
a radio signal followed by an US signal. Every anchor that
has received both signals returns the calculated distance and
its own position pi,est to the mobile node. This radio packet
is called DV (distance vector).
A. Procedure
Initially, the estimated position pi,est of each anchor ai is
placed at the middle of the corresponding anchor cell, but
every other position in the anchor cell would be possible, too.
The mobile node takes a new position and locates itself using
the received DVs from the anchors. The mobile node sends
the newly estimated position back to the anchors, which in
turn buffer this position for their own positioning.
1 while ( true ) {
2
take new position ;
3
measure distances ;
4
calculate pm,est ;
5
broadcast pm,est ;
6 }
/ / change pm,real
/ / using TDoA method
/ / using t r i l a t e r a t i o n (III-B)
If an anchor ai has collected at least three non-collinear
position estimations of the mobile node, it is able to update its
own estimated position pi,est , which offers a smaller position
error on average.
1 while ( true ) {
2
/ / localization dependent parts
3
i f (new position pm,est received ) {
4
store DV;
/ / pm,est and measured distance to m
5
}
6
i f (enough DVs stored ) {
7
update pi,est ; / / using t r i l a t e r a t i o n (III-B)
8
}
9 }
A DV contains an estimated position pm,est or pi,est and
the measured distance between m and the anchor ai . Through
the repeating localization of m and the anchors ai , after a
few (depending on the number of anchors) calibration steps,
a consistent anchor arrangement will be achieved (see section
III-C). One step corresponds to a positional change of m. An
anchor arrangement is called consistent, if the re-localization
of all anchors with perfect distances only confirms the already
estimated positions.
adapted trilateration fulfills these requirements. The adapted
trilateration for a node k ∈ {m, ai , . . . , an } looks as follows:
1 generate j t r i p l e t s ;
2 generate j position estimations ;
3 i f ( position estimations ∈ Ak ≥ 4) {
4
pk,f inal = coordinate−wise median of a l l
estimations ∈ Ak ;
5 }
The adapted trilateration
builds j triplets from the q received DVs. If j < 3q , the triplets that span the largest
triangles are selected. Throughout our tests we found that
j = 12 3q results in a good trade-off between run-time and
accuracy. With each of the j triplets a position is estimated
using a regular trilateration. Only position estimations located
in the area Ak will be considered. By discarding all estimations
∈
/ Ak the average accuracy can be improved. The final position
estimation pk,f inal is calculated using the coordinate-wise
median of all considered position estimations. To achieve
position estimations that are as accurate as possible, the
adapted trilateration requires at least four positions ∈ Ak .
C. Illustration and match operation
Fig. 1 shows the calibration process for a small anchor
plane with 3 × 3 anchors and a grid-length of ≈ 1.3 m1 . The
estimated position of each anchor is located in the middle
of the corresponding cell and the real position is randomly
placed anywhere within the cell. It is obvious that there is
still after 800 steps a significant deviation between pi,est and
pi,real (Fig. 1b). According to the plotted path in Fig. 1b it
seems that the distance between two estimated positions for
an anchor ai was small in the recent steps. The reason for the
small distances is an almost consistent anchor arrangement.
To match the real and the estimated positions two anchors
af ix1 and af ix2 with known real positions are required. But
the match operation is only necessary if absolute coordinates
are desired. With af ix1 the translation values δx and δy can
be calculated:
δx = pf ix1 ,real .x − pf ix1 ,est .x
δy = pf ix1 ,real .y − pf ix1 ,est .y
with pi,real = (pi,real .x, pi,real .y),
Three-dimensional coordinates can
translation matrix

1 0
Atrans = 0 1
0 0
and pi,est respectively.
be translated with the

δx
δy  .
1
B. Localization algorithm
Afterwards, the translated coordinates must be rotated around
the chosen point of origin pf ix1 ,real = (x0 , y0 ). The rotation angle θ is the angle between the straight connection
of pf ix1 ,real and pf ix2 ,real , and the straight connection of
The D&E algorithm requires a localization algorithm, which
tolerates inaccurate anchor positions, but still provides precise
position estimations with accurate anchors. In several tests, an
1 The grid-length was automatically calculated depending on the height of
the room, the US emission angle, and the necessary number of anchors within
the cone.
6
(a) initial anchor arrangement
(b) anchor arrangement after 800 steps
Fig. 1.
(c) anchor arrangement after transformation
Anchor plane during calibration
pf ix1 ,real and the translated coordinate pf ix2 ,est . The rotation
is realized using the transformation matrix


cos(θ) − sin(θ) xθ − xθ · cos(θ) + yθ · sin(θ)
Arot =  sin(θ) cos(θ) yθ − xθ · sin(θ) − yθ · cos(θ)  .
0
0
1
The affine transformation Aat to match all anchors is
Aat = Arot × Atrans .
Fig. 1c shows the matched anchor plane, now offering an
average error of just 0.7 mm.
For three-dimensional calibrations a further rotation around
the axis joining af ix1 and af ix2 is necessary. The corresponding rotation angle can be calculated with a third static anchor
af ix3 with known position pf ix3 ,real .
D. Improvements
The achievable calibration accuracy depends strongly on the
error characteristic of the distance measurement. Therefore, it
can be necessary to improve the accuracy by distance filtering.
Instead of using the first distance measured, the median of 100
distance measurements is used if the variance of the distance
sequence is ≤ 1.0. If the variance is > 1.0, the complete
sequence is discarded. The error probability measured in our
real world localization system could be improved significantly
(see Fig. 2). Note that the error characteristic was measured
under stable environmental conditions.
During development, the accuracy of the calibration can be
determined by the average position error of all anchors
n
X
fa =
|pi,est − pi,real |.
i=1
As the real positions are unknown, a self-calibration algorithm
can not compute fa . Thus, for the localization of node k the
agreementk is defined, which depends on the size of the
adapted trilateration’s scatter plot:
c
1X
agreementk :=
|pk,f inal − pj |
c j=1
Fig. 2.
Frequency density of the error characteristic of the distance
measurement
where pj , j ∈ {1, . . . , c} are the position estimations ∈ Ak
and pk,f inal is the final position estimation. If the resulting
scatter plot is large, the likelihood for an imprecise position
estimation is high, too. In contrast, a small scatter plot is an
indication for a more precise position estimation.
The localization of a node k can also degrade the accuracy,
since the localization is possibly based on faulty position
estimations. To shorten the calibration time, an agreementk
dependent adjustment was implemented. If a new position
pi,est is estimated for an anchor ai , the adjustment vector
xt−1 −xt
from the past estimated position (xt−1 , yt−1 ) to
yt−1 −yt
the new estimated position (xt , yt ) is calculated. Instead of
accepting the new position estimation, a weighted adjustment
is performed with α ∈ (0, 1):
pi,est = (xt−1 , yt−1 )T +
xt−1 −xt
yt−1 −yt
· αagreementi .
A sufficient value of α at system start is 0.9. But as fa
decreases over time, after some calibration steps, a smaller α
value should be chosen. This is the reason, why α is calculated
using the average of the last 100 agreementm values of the
mobile node m.
7
steps to achieve a certain accuracy
40000
fa < 0.1 mm
fa < 0.2 mm
fa < 0.5 mm
fa < 1.0 mm
35000
30000
25000
20000
15000
10000
5000
0
0
50 100 150 200 250 300 350 400 450
anchors
(a) Run of fa with and without weighting
(b) Run of fa for different distance errors
Fig. 3.
Simulated results of the calibration
IV. E XPERIMENTAL RESULTS
Fig. 3a shows the run of fa for a calibration of 11 × 11
anchors using distance filtering with and without weighted adjustment. The advantage of the weighted adjustment becomes
even more obvious for longer calibrations, where unique
distance errors recurrently increasing the average position error
if no weighting is used.
As mentioned in section III-D, the achievable calibration
accuracy depends strongly on the accuracy of the distance
measurement. Fig. 3b shows the average error during calibration of 11 × 11 anchors. With perfect distances, 1200
calibration steps are required to achieve an average error
fa < 1 mm, and 3000 steps for fa ≈ 0.0 mm. Even with
faulty distances an accuracy < 1 mm can be achieved after
1800 steps using distance filtering. Without distance filtering,
large distance errors can increase the average error fa , e.g. the
average error is still > 5 mm even after 3000 steps.
The time to achieve a calibration of a certain accuracy
depends also on the number of anchors to be calibrated. Fig.
3c shows the required steps to calibrate various numbers of
anchors using exact distance measurements.
The most time consuming parts of the calibration are
the movement of m and the data aggregation. Assuming a
localization frequency of 5 Hz, 100 distance measurements
per step for distance filtering, a duration of 10 seconds per
movement of m, and 1800 calibration steps (Fig. 3b), the
calibration of an anchor plane with 11 × 11 anchors takes:
tdue = 1800 × (10 s +
100
) = 15 h
5 Hz
This time can be reduced if several mobile nodes are used, or
if a reduced accuracy is acceptable. As D&E is a progressive
calibration method, the last calibration steps could also be
gained during the operation of the localization system.
As distance errors are unavoidable, and can cause position
errors, a high fault-tolerance is of particular importance for
self-calibration methods. Distribute & Erase purges such position errors as the position error of an anchor is distributed
to its neighboring nodes and is then erased through a match
operation.
8
(c) Necessary steps to achieve a certain accuracy for
a given number of anchors
V. C ONCLUSION
In this paper we introduced Distribute & Erase, a precise
self-calibration approach for US based localization systems.
Some improvements were developed to enhance the accuracy
and speed of the calibration. We showed that the achievable
accuracy highly depends on the accuracy of the distance
measurement system. With the error characteristics measured
in our real world localization system an average position error
fa < 1 mm is reachable. Distribute & Erase can replace
the hard, time-consuming and fault-prone manual calibration,
and operates distributed, autonomously and without further
hardware or special a priori knowledge. Therefore, D&E is
suitable for the fast, cheap and easy calibration of localization
systems during deployment. As D&E calibrates progressively,
it is also suitable for recalibration, especially after changes of
the infrastructure.
R EFERENCES
[1] N. B. Priyantha, A. Chakraborty, and H. Balakrishnan, “The Cricket
Location-Support System,” in 6th ACM International Conference on
Mobile Computing and Networking, 2000.
[2] A. Savvides, C.-C. Han, and M. B. Strivastava, “Dynamic fine-grained
localization in Ad-Hoc networks of sensors,” in MobiCom ’01: Proceedings of the 7th annual international conference on Mobile computing and
networking, 2001, pp. 166–179.
[3] M. Baunach, R. Kolla, and C. Mühlberger, “SNoW Bat: A high precise
WSN based location system,” Universität Würzburg, Lehrstuhl für Informatik V, Tech. Rep. 424, 2007.
[4] S. Capkun, M. Hamdi, and J.-P. Hubaux, “GPS-free positioning in mobile
ad hoc networks,” in Cluster Computing, 2001, pp. 3481–3490.
[5] M. L. Sichitiu and V. Ramadurai, “Localization of Wireless Sensor
Networks with a Mobile Beacon,” in Proceedings of the First IEEE
Conference on Mobile Ad-hoc and Sensor Systems (MASS 2004), 2004.
[6] R. L. Moses, O. L. Moses, D. Krishnamurthy, and R. Patterson, “A SelfLocalization Method for Wireless Sensor Networks,” EURASIP Journal
on Applied Signal Processing, vol. 4, pp. 348–358, 2002.
[7] E. Menegatti, L. Lazzaretto, and A. Zanella, “Self-localization of Wireless
Sensor Nodes by means of Autonomous Mobile Robots,” in Proceedings
of the Tyrrhenian International Workshop on Digital Communication
Wireless Communications (TIWDC 2007), 2007.
[8] M. Baunach, R. Kolla, and C. Mühlberger, “A Method for Self-Organizing
Communication in WSN Based Localization Systems: HashSlot,” in
Second IEEE International Workshop on Practical Issues in Building
Sensor Network Applications, SenseApp 2007, 2007.
Ein adaptives Vorhersagemodell für Signalstärken in
einem Funknetzwerk
Christian Huisinga und Jens Kamenik
OFFIS,
Escherweg 2,
26121 Oldenburg, Germany
Email: [email protected],
[email protected]
Zusammenfassung—Drahtlose Sensornetze kommunizieren
über (Funk-)Antennen und verändern dadurch die Verhältnisse
des elektromagnetischen Feldes. Somit stellt die Antenne beim
Empfangen einen Aktor und beim Senden einen Sensor gegenüber dem elektromagnetischen Feld dar. Dieses Feld steht
in Wechselwirkung mit den Gegenständen und Lebewesen in
seiner Umgebung. An vielen Einsatzorten von drahtlosen Sensornetzwerken ist keine direkte Sichtverbindung der Sensorknoten
untereinander möglich. Auch kann sich die Umgebung am
Einsatzort des Sensornetzwerkes mit der Zeit ändern. Ein einmal
erhobenes Vorhersagemodell zur Ausbreitung der Wellen (auch
Ausbreitungsmodell genannt) kann immer nur eine Momentaufnahme darstellen und wird zur Laufzeit, mit erheblichen
Aufwand und Kosten, angepasst werden müssen. Der Ansatz,
der in dieser Arbeit vorgestellt wird, ermöglicht eine schnelle
und automatische Modellierung durch maschinelles Lernen. Mit
der entwickelten Software namens Evodel können die Parameter
eines Ausbreitungsmodells zur Laufzeit angepasst und optimiert
werden. Evaluiert wird die Methode anhand der Parameteroptimierung eines Multi-Wall-Ausbreitungsmodells sowie anhand der
Lokalisation eines Sensorknotens.
I. E INLEITUNG
Der vorherrschende Übertragungsweg zur Kommunikation
in Sensornetzen ist das Senden und Empfangen elektromagnetischer Wellen mittels Antennen. Eine Antenne kann als Sensor
für die elektrische Feldstärke angesehen werden. Zwischen
dem Aussenden und Empfangen einer Nachricht propagiert
die elektromagnetische Welle durch den Raum und wird von
Gegenständen und Lebewesen in ihrer Umgebung beeinflusst.
In Mobilfunknetzten werden daher, zum Beispiel, Modelle zur
Vorhersage der Ausbreitung der elektromagnetischen Wellen
eingesetzt, um die Netz-Abdeckung zu optimieren. Die Beeinflussung der Umgebung kann mit einem Sender/EmpfängerPaar gemessen werden. So stellt ein Antennen-Paar indirekt
einen Sensor für seine Umgebung dar. Typisch ist der Einsatz
von Sensornetzwerken in Bürogebäuden oder Wohgebäuden in
denen keine direkte Sichtverbindung der Sensorknoten untereinander möglich ist. Außerdem ändert sich die Umgebung am
Einsatzort des Sensornetzwerkes mit der Zeit. Ein detailliertes,
mühevoll erhobenes Vorhersagemodell zur Ausbreitung der
Wellen kann so nur eine Momentaufnahme darstellen. Die
Abweichung der Vorhersagen zur Realität kann deshalb sehr
groß sein.
Der Ansatz, der in dieser Arbeit vorgestellt wird, ermöglicht
eine schnelle und automatische Modellierung durch maschinelles Lernen. Damit können die Parameter eines Ausbreitungsmodells zur Laufzeit optimiert werden und zum Beispiel, die Erreichbarkeit von Sensorknoten im Sensornetzwerk
sichergestellt werden, auch wenn sich die Einsatzumgebung
ändert. Durch permanente Kontrollmessungen und automatische Anpassung der Fitting-Parameter eines Ausbreitungsmodells, wird eine robuste Vorhersage der Signalstärken in
einem Sensornetz erreicht. In [4] wird bereits vorgeführt, dass
sich Modellparameter durch die Evolutionsstrategie anpassen
lassen, um so zu einer Vorhersage der Signalstärken zu gelangen. Bei umgekehrter Anwendung dieses Ansatz, kann mit
ausreichender Anzahl von Messungen, die Umgebung auch
rekonstruiert werden, um z.B. ein Sensorknoten oder eine Person zu lokalisieren. Die implementierte Software Evodel setzt
diesen Ansatz in beiden Anwendungsrichtungen um. Durch
die freie Wahl der Fitting-Parameter entsteht ein flexibles
Werkzeug zur Vermessung, Planung oder Überwachung. Zwei
Anwendungsbeispiele zeigen die Anpassung eines Multi-WallModells [5] und die Lokalisation eines Sensorknotens. Dabei
werden jeweils verschiedene Parameter als zu optimierende
Fitting-Parameter eingesetzt - im ersten Fall sind dies die
Materialeigenschaften der Wände und im zweiten Fall die
Position eines Sensorknotens.
II. G RUNDLAGEN ZU AUSBREITUNGSMODELLEN
Dieser Abschnitt behandelt die Grundlagen zur Freiraumdämpfung, die zur Log-Distanz-Gleichung [3] verallgemeinert wird. Durch die Verallgemeinerung der Freiraumausbreitung, wird die grundlegende Funktion eines FittingParameters erläutert. Des Weiteren wird als zusätzliches Ausbreitungsmodell das Multi-Wall-Modell [5] beschrieben.
A. Freiraumdämpfung
Die Betrachtung der Freiraumdämpfung liefert ein erstes
Modell zur Ausbreitung elektromagnetischer Wellen. Die Freiraumdämpfung F ist der Quotient von Leistung P , die eine
λ2
im Abstand r empfängt,
isotrope Antenne mit der Fläche 4π
zu abgestrahlter Leistung P0 . Gleichung 1 zeigt die Freiraumdämpfung, wobei λ die Wellenlänge der elektromagnetischen Welle ist.
2
P0
4πr
F (r) =
=
(1)
P
λ
In logarithmischer Schreibweise kann die empfangene Leistung durch Gleichung 2 dargestellt werden.
p = p0 − 2 · 10 log r
(2)
Die Gleichung 2 gilt für den freien Raum ohne Wechselwirkungen mit Materie. Sie beschreibt die Verteilung eines
9
Umgebung
Freiraum
Freie Ebene
In Gebäuden mit Sichtverbindung
In Gebäuden abgeschattet
Exponent n
2
<2
1, 6 ... 1, 8
4 ... 6
k =n−2
0
<0
−0, 4... − 0, 2
2...4
Tabelle I
E XPONENTEN IM L OG -D ISTANZ -M ODELL F ÜR VERSCHIEDENE
U MGEBUNGEN [3]
Abbildung 2.
Abbildung 1. Gemessene Signalstärke über den Abstand zwischen Sender
und Empfänger
konstanten Energieflusses auf eine mit dem Abstand immer
größer werdenden Fläche und stellt somit keine Dämpfung
im physikalischen Sinn dar. Während dieses Vorhersagemodell
(Gleichung 2) für den Außenbereich - bei freier Sichtverbindung - noch zufriedenstellende Ergebnisse liefert, hat die
Wechselwirkung mit der Materie für die Ausbreitung innerhalb
von Gebäuden einen nicht zu vernachlässigen Einfluss. Um
die Vorhersagegenauigkeit für die Ausbreitung innerhalb von
Gebäuden zu verbessern, existieren zwei verschiedene Herangehensweisen. Zum einen kann ein Modell durch zusätzlich
betrachtete Effekte präzisiert werden, wie zum Beispiel durch
die Reflexion an Wänden oder durch die Beugung an Kanten.
Diese Effekte können theoretisch hergeleitet werden und in das
Modell eingefügt werden, so dass sich die Effekte überlagern.
B. Log-Distanz-Gleichung
Ein anderer Weg, um die Vorhersagegenauigkeit eines Modells zu verbessern ist es, ein vorliegendes Modell anzupassen. Hierzu werden zunächst eine Anzahl von Messungen durchgeführt. Im gegebenem Vorhersagemodell werden
Fitting-Parameter identifiziert, die es ermöglichen das Modell
anzupassen. Im Fall der Freiraumdämpfung wird der Exponent
in Gleichung 1 als Fitting-Parameter identifiziert. Die Verallgemeinerung von Gleichung 2 führt zur allgemeinen LogDistanz-Beziehung Gleichung 3, wobei p0 eine Konstante und
n der Fitting-Parameter ist.
p(r) = p0 − n · 10 log r
(3)
Der Exponent n setzt sich additiv aus dem Exponent der Freiraumdämpfung 2 und einem Korrekturanteil k, also n = 2 + k
zusammen. Der Wert k repräsentiert alle auftretenden Effekte
außer der Freiraumdämpfung. Tabelle I zeigt die empirisch
ermittelten Exponenten für unterschiedliche Umgebungen aus
[3]. Neben der zu erwartenden Dämpfung durch Abschattung,
stellt man bei der direkten Sichtverbindung in Gebäuden eine
Verstärkung fest. Die Gesamtheit der Reflexionen an den
10
Allgemeiner Ansatz der automatischen Parameteroptimierung
Decken und Wänden führt - im Mittel - zu einer konstruktiven
Überlagerung und somit zur Verstärkung. Durch die richtige
Wahl des Fitting-Parameters n wird diesem Kanalisierungseffekt Rechnung getragen. Die Reflexion als physikalischer
Effekt wird im Modell nicht explizit berücksichtigt. Dennoch
wird der Einfluss der (vielen) Reflexionen durch die Wahl des
Fitting-Parameters gemittelt berücksichtigt. Mit der Messung
der Signalstärken für verschiedene Abstände zum Sender kann
durch lineare Regression der Fitting-Parameter bestimmt werden. Abbildung 1 zeigt eine Messung in einem Wohnraum.
Abbildung 1 zeigt zudem, dass die Freiraumdämpfung mit
n = 2 nur im Fernfeld gilt. Im Nahfeld muss ein höherer
Exponent gefordert werden.
C. Multi-Wall-Modell
Im Wall-Modell werden die Wände eines Gebäudes
berücksichtigt. Dabei geht man von der einfachen Annahme
aus, dass jede Wand, die von einem Signal durchdrungen wird,
das Signal in quantitativ gleicher Weise dämpft - nämlich um
einen Faktor. In der dB-Skala wird der Faktor als Summand
dwall angegeben. Gleichung 4 berechnet die Dämpfung eines
Signals, dass w Wände durchdringt.
fwm = f + w · dwall
(4)
Die Funktion f ist dabei die Dämpfung ohne Hindernisse. Hier
kann z.B. die Freiraumdämpfung verwendet werden. Etwas
detaillierter ist das Multi-Wall-Modell [5]. Es berücksichtigt,
dass verschiedene Wände unterschiedlich stark dämpfen. Es
werden Dämpfungen di aller Wände i definiert. Gleichung 5
zeigt die Berechnung der Dämpfung im Multi-Wall-Modell für
ein Signal, dass w Wände durchdringt.
fmw = f +
w
X
di
(5)
i=1
In diesem Ausbreitungsmodell sind die Dämpfungen di ... dw
die Fitting-Parameter.
III. A NSATZ MIT MASCHINELLEM L ERNEN
Um das Prinzip der Anpassung der Fitting-Parameter automatisiert auf die Ausbreitung elektromagnetischer Wellen
anzuwenden, wurden folgende Teilaspekte verknüpft:
Ein Model, welches Fitting-Parameter enthält, berechnet
die Signalstärken innerhalb des Sensornetzes.
• Die Sensorknoten messen die Signalstärken vor Ort oder
es liegen Messdaten vor.
• Eine Metrik bestimmt den Abstand zwischen Berechnung
und Messung der Signalstärken als reelle Zahl.
• Ein Optimierer nach der Evolutionsstrategie variiert die
Fitting-Parameter mit dem Ziel, den in der Metrik definierten Abstand zwischen Berechnung und Messung zu
minimieren.
Die Dämpfungen zwischen den Sensorknoten im Sensornetz
können als Matrix dargestellt werden (Gleichung 6).


0
d1,2 d1,3 · · · d1,n
0
d2,3 · · · d2,n 
 d2,1
 d
d
0
· · · d3,n 
3,1
3,2


(6)
D=
.
.
.
.. 
..
 ..
..
..
.
. 
dn,1 dn,2 dn,3 · · ·
0
•
Abbildung 2 zeigt den iterativen Optimierungszyklus. Als
Optimierer wird die Evolutionsstrategie eingesetzt, da sie
sich flexibel auf sich ändernde Bedingungen durch eine automatische Schrittweiteregelung anpassen kann. Ein umfassenden Überblick zur Evolutionsstrategie erhält man z.B. in
[1]. Vom Evolutionsalgorithmus werden ständig neue Variationen der Fitting-Parameter generiert und mit der Fitnessfunktion bewertet. Dabei werden die Signalstärken berechnet
und gleichzeitig gemessen. Anhand der Fitness werden die
verschiedenen Varianten verglichen und die Besten werden
ausgewählt. Durch Gleichung 7 wird der Abstand zwischen
zwei Dämpfungsmatrizen hDm , Dw i definiert. Es wird nicht
ausgenutzt, dass es sich um eine symmetrische Matrix handelt.
v
u X
n
u1 n X
2
∆ = hDm , Dw i := t ·
(dm,i,j − dw,i,j )
(7)
s i=1 j=1
Die Zahl s gibt die Anzahl der Einzeldämpfungen an. Der
definierte Abstand multipliziert mit (−1) wird als Bewertungskriterium für die Ähnlichkeit zweier Dämpfungsmatrizen
verwendet. Gleichung 8 zeigt die Fitness bzw. die Qualität,
dessen Maximalwert Null ist.
q = −∆ = −hDm , Dw i = −hM (u), Dw i
(8)
IV. S YSTEMAUFBAU
Abbildung 2 zeigt den funktionellen Aufbau des Vorhersagesystems, dessen Komponenten nun beschrieben werden.
A. Das Ausbreitungsmodell
Das Ausbreitungsmodell, welches aus gegebenen Parameter
die Signalstärken berechnet, berücksichtigt folgende Ausbreitungseffekte:
• Freiraumausbreitung
• Winkel-abhängige Dämpfung durch Wände
• Winkel-abhängige Reflexion an Wänden und Personen
• Beugungseffekte durch eine Person
Die Freiraumausbreitung wird durch die Log-DistanzGleichung (Gleichung 3) berechnet. Die Dämpfung durch die
Wände werden mit dem Multi-Wall-Modell (Gleichung 5)
berechnet. Dem Wert der Dämpfung aus dem Multi-WallModell wird eine Winkel-abhängige Dämpfung überlagert,
Abbildung 3.
modells
Optimierte Umgebung und Berechnungen des Ausbreitungs-
dem Reflexionsvermögen. Das Reflexionsvermögen folgt theoretisch aus den Maxwell’schen Gleichungen [2] und wird
im Ausbreitungsmodell als globale Funktion definiert. Die
Funktion des Reflexionsvermögens wird in mehrere Werte
diskretisiert. Diese Werte, zusammen mit den Parametern aus
der Log-Distanz-Gleichung, den Parametern des Multi-WallModells und den Knotenpositionen bilden eine Zahlenfolge,
die die Umgebung repräsentiert. Die Gesamtheit der Modellparameter ist die Repräsentation der Umgebung.
B. Feldstärkemessung
Es wurde ein Sensornetz aus micaZ-Sensorknoten verwendet. Dieser Sensorknoten verfügt über einen CC2420-Funkchip
[6], der eine Messung der empfangenen Feldstärke durchführt.
Der RSSI-Wert wird ausgelesen und über eine Basisstation an
einen PC übermittelt.
C. Optimierung der Modellparameter
Die Parameter des Ausbreitungsmodells werden durch die
Evolutionsstrategie optimiert. Die Gesamtheit der Parameter
bilden die Repräsentation der Umgebung. Mit der Optimierung sollen jedoch nicht alle Parameter verändert werden.
Die Position einer Wand z.B. sind meist nicht-veränderbare
Parameter. Nur die veränderbaren Parameter bilden zusammen
ein Individuum (= sein Genom) im Kontext der Evolutionsstrategie. Nach der Optimierung werden die Parameter kombiniert
und bilden wieder eine Repräsentation der Umgebung. Welche
Parameter des Modells optimiert werden sollen, kann dabei
frei gewählt werden.
V. S YSTEMANWENDUNG
Die erste Anwendung zeigt die Vorgehensweise zur Vorhersage von Signalstärken in einem Sensornetz. Die zweite Anwendung demonstriert die Lokalisation eines Sensorknotens.
Die implementierte Software trägt den (Titel-) Namen Evodel.
A. Vorhersage von Signalstärken
In dieser Anwendung werden Sensorknoten in einer Wohnung verteilt. Die Abmessungen der Wände und die Positionen
der Sensorknoten wurden vermessen und in Evodel eingegeben. Diese Parameter werden fixiert. Die Materialparameter
für das Multi-Wall-Modell und die Log-Distanz-Parameter
11
Abbildung 4.
Mobiler Sensorknoten auf einer Modellbahn
Abbildung 5. Links: Ermittelte Sensorknotenposition, rechts: Fitness und
Schrittweite der Evolution
werden als veränderbar markiert. Die veränderbaren Parameter
(Fitting-Parameter) werden durch die Evolutionsstrategie variiert und optimiert. Abbildung 3 zeigt die in Evodel angezeigte
Umgebung aus Wänden, Sensorknoten und Verbindungslinien
nach dem Evolutionslauf. Rechts der Verlauf der Fitness und
unten der Verlauf der Schrittweite während der Optimierung skizziert. Die mittlere quadratische Abweichung aller
Messwerte zu den Berechnungen des Ausbreitungsmodells
sinkt von 17,00 dBm vor der Optimierung auf 6,22 dBm
nach der Optimierung. Mit der optimierten Repräsentation der
Umgebung kann das Ausbreitungsmodell nun zur Vorhersage
von Signalstärken eingesetzt werden.
B. Lokalisation eines Sensorknotens
Zunächst werden fünf Sensorknoten ohne den mobilen Knoten auf einem Tisch aufgestellt. Abbildung 4 zeigt den Aufbaus
des Experiments. Vier Sensorknoten wurden in die Ecken des
Tisches und ein Knoten in die Mitte des Tisches platziert. Die
Positionen der Sensorknoten werden ausgemessen und in Evodel eingegeben. Nun misst das Sensornetz die Signalstärken
und sendet diese über die Basisstation an das laufende Programm. Die Verbindungen werden im Programmfenster von
Evodel angezeigt. Bevor der mobile Knoten zum Einsatz
kommt, werden zunächst die vorherrschenden Log-DistanzParameter ermittelt. Dazu werden alle Knotenpositionen über
das Programmfenster fixiert und die Log-Distanz-Parameter
als veränderbar markiert. Wird nun ein Evolutionslauf gestartet, werden die Log-Distanz-Parameter ermittelt. Bei 100
Generationen und 40 Individuen nimmt dies ca. 60 Sekunden
in Anspruch. Das Ergebnis ist hier p0 = 24, 07 dBm und
n = 3, 42, vergleiche Gleichung 3 und Abbildung 1. Die
Log-Distanz-Parameter werden jetzt wieder fixiert. Danach
wird der sechste Sensorknoten in das Sensornetz eingebracht,
dessen Position als veränderbar markiert wird. Die beiden
Koordinaten der Position des mobilen Sensorknoten sind
nun die einzigen veränderbaren Parameter und somit Gene
des Individuums. Die Messung der Signalstärken wird nun
fortgesetzt. Die Signalstärken - inklusive die zum mobilen
Knoten - werden nun kontinuierlich gemessen und angezeigt.
Anschließend wird die Evolution gestartet. Die Position des
mobilen Sensorknotens wird nun variiert mit dem Ziel die
kontinuierlichen Messungen vorhersagen zu können. Nach
jeder Generation der Evolution wird das Ergebnis der Optimierung im Programmfenster angezeigt. Abbildung 5 zeigt
die von Evodel angezeigte Umgebung bei der Lokalisation
12
des Sensorknotens. Es wurde die Spur des mobilen Knotens
für einen Umlauf der Modellbahn aufgezeichnet. Die Rechenzeit für eine Generation der Evolution beträgt Bruchteile
einer Sekunde. Die Fitness von -4,126 bedeutet, dass aktuell
die Messdaten im quadratischem Mittel um 4,126 dBm von
den Berechnungen des Ausbreitungsmodells abweichen. Die
Schrittweite von 117 mm bedeutet, dass das beste Individuum
der letzten Generation 117 mm von seinem Eltern-Individuum
abweicht. Die Schrittweite korrespondiert dabei mit der Bewegungsgeschwindigkeit des Sensorknotens.
VI. R ES ÜMEE
In dieser Arbeit wurde gezeigt, dass man durch Kombination von variablem Ausbreitungsmodell, experimentellen
Feldstärkemessungen und Parameteroptimierung in der Lage
ist, die Parameter eines Ausbreitungsmodells zur Laufzeit
anzupassen und zu optimieren. Damit kann, z.B. die Umgebung eines Sensornetzes rekonstruiert werden. Die gewonnene
Repräsentation der Umgebung kann für weitere Berechnungen
eingesetzt werden, z.B. zur Berechnung des Ausbreitungsverhaltens eines (virtuellen) Senders. Evaluiert wurde die
Methode anhand der Anwendungsbeispiele der Parameteroptimierung eines Multi-Wall-Ausbreitungsmodells sowie anhand
der Lokalisation eines Sensorknotens. Für genaue Vorhersagen
in Bezug auf die Signalstärken muss das verwendete Ausbreitungsmodell noch verbessert werden. Die Lokalisation des
mobilen Sensorknotens dagegen lieferte im Vergleich bessere
Genauigkeiten.
L ITERATUR
[1] Ingo Rechenberg: Evolutionsstrategie ’94 – Werkstatt Bionik und Evo” 1, Friedrich Frommann Verlag, Stuttgart, 1994
lutionstechnik“, Band
[2] Wolfgang Demtröter: Experimentalphysik 2 – Elektrizität und Optik“,
”
2.Auflage Springer-Verlag,
2002
[3] T. S. Rappaport u.a.: Wireless communications: principles and practice“,
”
Prentice Hall PTR, New Jersey, 1996
[4] M. Klepal, D. Pesch und Z.Hradecky: Optimising motif models for
”
indoor radio propagation prediction using evolutionary
computation“, The
Irish Signals and Systems Conference (S. 301-306), 2002
[5] M. Lott und I. Forkel: A multi-wall-and-floor model for indoor radio
propagation“, Vehicular ”Technology Conference, 2001, IEEE, 2002
[6] CC2420 Datasheed. Link (im Juli 2011)
inst.eecs.berkeley.edu/˜cs150/Documents/CC2420.pdf
SuperG: A Multi-Radio Architecture to interconnect
multiple Wireless Sensor Networks
Clemens Mühlberger and Tobias Schäfer
Institute of Computer Science
University of Würzburg
97074 Würzburg, Germany
Email: {muehlberger, schaefer}@informatik.uni-wuerzburg.de
Abstract—On the way to the “Internet of Things” the coexistence of highly adapted but yet deployed sensor networks and
future wireless sensor networks using advanced radio technologies must be considered increasingly crucial. This is the reason
why we do want to interconnect wireless sensor networks using
diverse radio interfaces and communication protocols to form one
homogeneous network from a logical point of view. Therefore,
we developed a modular architecture for multi-layer multi-radio
gateways. We also present our hardware prototype SuperG,
which offers four sub 1-GHz as well as two 2.4 GHz based radio
devices at a single node. To the best of our knowledge, this is
the first paper describing a multi-radio gateway interconnecting
more than two wireless sensor networks, where each of them uses
different communication interfaces.
I. I NTRODUCTION
In recent years, both the number of Wireless Sensor
Networks (WSNs) deployed and the diversity of Sensor
Nodes (SNs) installed has increased. Therefore, the spectrum of radio devices used at such wireless platforms
nowadays ranges from sub 1-GHz transceivers like RFM
TR1000/TR1001 (e.g. at early platforms like EYES, ScatterWeb ESB, and MICA) and Chipcon CC1000/CC1100/CC1101
(e.g. at SNoW5, BTnode, ScatterNode, Mica2, and Mica2Dot),
to 2.4 GHz IEEE 802.15.4/ZigBee compliant transceivers
Chipcon CC2420/CC2520 (e.g. at MicaZ, TelosB, tmote sky,
Sun SPOT, and Imote2) and System-on-Chip radio transceiver
Nordic nRF24 (e.g. at EcoSpire). This very variety of radio
interfaces as well as the offered communication protocols
complicates the interconnection of miscellaneous WSNs.
However, the re-utilization of already installed sensor nodes
is not only cost-efficient, but also inevitable in some cases,
e.g. if nodes are firmly connected to the surroundings or even
encased in concrete. Furthermore, coordination and interoperability between yet established and recently deployed WSNs
using (potentially) incompatible communication interfaces becomes more and more important on the way to “Cooperating
Objects” [1] and the “Internet of Things” [2]. The installation
of one or more auxiliary gateways1 is a simple, fast, and
cost-efficient solution to establish communication links when
incompatible communication interfaces are used within the
heterogeneous network. Indeed, all messages are delayed when
passing such a gateway. More precisely, protocol adaption and
protocol conversion (cf. Sec. III-A2) are causing such a delay,
which mainly depends on additional but specific calculation
efforts as well as a potential waiting time for the next time of
transmission.
In this paper we present our modular architecture for a
multi-layer multi-radio gateway which supports the interconnection of an unlimited number of networks per se. This
approach allows application dependent operation modes, like
repeater, hub, and switch. In principle, our architecture is an
adaption and extension of the IEEE 802.11 WLAN infrastructure [3]. To evaluate the suitability of this multi-radio gateway
under real conditions, we developed the hardware prototype
SuperG which offers four sub 1-GHz and two 2.4 GHz radio
devices. First tests were successful and promising (see Sec.
V), thus we are currently trying to interconnect several networks consisting of SNoW5 [4], and TelosB [5] sensor nodes
respectively, assisted by our SuperG gateway node.
The remainder of this paper is organized as follows. In
Section II, we give a brief overview of related work. Section III
describes in detail our architecture for a multi-layer multi-radio
gateway with a special focus on distribution and integration
services. Section IV outlines potential operation modes of this
multi-radio gateway node, whereas Section V presents our
hardware prototype of such a gateway. A brief summary and
an outlook to future work in Section VI closes this paper.
II. R ELATED W ORK
This section gives a short overview over current research
concerning the interconnection of heterogeneous networks,
and available gateway nodes in particular. General considerations about the interconnection challenges and strategies,
especially when combining a WSN to the Internet, as well
as the need for gateways at all, can be found in Karl et
al. [6]. A good overview of nodes with more computational
power is listed in [7]: these ”large sensor nodes” often offer
more communication interfaces, e.g. an additional Ethernet
connector. Of course, in some cases it is sufficient to just plug
a specific sensor node to a more powerful device like an PC
or PDA, e.g. via RS232 or USB interface. But our goal is
the interconnection of multiple sensor networks, not just the
Internet.
1 Within this paper, the term (communication) gateway means an instrument
forming a homogeneous network out of a heterogeneous network in a logical
point of view, whereat a heterogeneous network is a collection of two or more
homogeneous networks.
13
Due to its modular design, the s-net Mobile Gateway [8] is
very versatile, because it offers up to four Mini PCI Express
slots. Amongst others, cards for s-net, WLAN, UMTS, and
GSM network are yet available. This gateway architecture is
pretty close to our vision of an interconnecting gateway for
multiple WSNs, because it already allows the combination of
up to four (different) networks at once.
One of the rare gateway nodes supporting both IEEE
802.15.4 and sub 1-GHz radio is the NanoRouter Ethernet 2.0
[9]. However, this gateway is just able to interconnect 6LoWPAN based enterprise sensor networks to IPv4/IPv6 Ethernet
networks. Though, our intention is to stay independent of the
used protocols as far as possible.
With respect to the installed radio devices, the sensor node
of Ansari et al. [10] is most similar to our approach, because
it also combines both IEEE 802.15.4 and proprietary sub 1GHz radio units at one extended TelosB sensor node. This
allows an interconnection of a burst radio interface realized
by a CC2420 radio chip, and the low frequency radio chip
CC1100. Indeed, the two different radio interfaces were used
to find energy-efficient MAC operation, i.e. on the one hand a
transmitter for data at high bandwidth, and on the other hand
a sniffer for control messages at lower bandwidth. However,
what we do want is the interconnection of quite different
(wireless) communication interfaces. This also implies that
our architecture has to offer application dependent operation
modes, like repeater, hub, and switch.
III. O UR G ATEWAY A RCHITECTURE
Our gateway architecture mainly was inspired by the IEEE
802.11 WLAN infrastructure [3]: There, a Distribution System
(DS) provides logical support to map addresses to destinations
and to integrate multiple subnetworks seamlessly. That means,
for members of the subnetwork the access to the DS is offered
by an Access Point (AP). Nevertheless, APs are sufficient, if
all members of such a subnetwork use the very same protocol
on both medium access as well as physical layer. Therefore, a
so called portal (a specific AP) is required when integrating an
IEEE 802.x LAN based network. Such a portal has to provide
both distribution and integration services.
A. Our Multiple WSN Architecture
In the context of WSN, several sensor nodes in combination
with a portal form a simple WSN. To interconnect various
WSNs, an Extended Distribution System (EDS) must be installed. This EDS concatenates the portals of the corresponding
WSNs with each other. According to Figure 1, a portal acts
like a sensor node within the corresponding WSN, but offers
access to the EDS. Due to our goal to simplify the integration
of various protocols, the most significant software part relies
on a portal: it should provide an interface for the required protocols without any changes concerning their implementation,
if possible. Please note, the EDS Medium (EDSM) and the
Wireless Medium (WM) must be clearly distinguished from a
logical point of view: First, the EDSM should not be visible for
the sensor nodes because the EDSM is not part of any WSN.
14
Fig. 1.
Schematic of our multiple WSN architecture
Second, the EDSM should be exchangeable, i.e. the EDSM
could be realized in various ways, e.g. at a single device (just
like our SuperG does, cf. Sec. V), as a wired bus between
specific portal nodes, or even wirelessly.
This architecture classifies two subsets of the main services
as follows: Each sensor node basically relies on the Sensor
Node Service (SNS), which is defined by the communication
protocol of the corresponding WSN. In contrast, the EDS
implements the EDS Service (EDSS), which relies on both
main services of the WSN Infrastructure: the Distribution
Service and the Integration Service.
1) Distribution Service: Depending on the functionality of
the entire architecture, the Distribution Service covers two
essential tasks.
First, it has to achieve the message flow throughout the EDS.
To support various architectures, the type of transmission is
not made mandatory. For example, several sensor nodes can
be interconnected via a wired bus system like Serial Peripheral
Interface (SPI) to form an EDS. Obviously, in this case there is
no additional transmission protocol within the EDS required.
Indeed, timings and delays are going to become particularly
critical, e.g. broadcast messages within such a wired EDS will
not arrive at each destination at the very same time. An EDS
could also be implemented for example at a single sensor node
offering more than one radio unit (cf. also Sec. V). Here, the
EDS complies to the controller’s RAM in general. Thus, data
packets have not to be propagated further within the EDSM,
because the controller now serves all radio units. The delay of
broadcast messages is not that critical anymore.
The second task is responsible for the operation mode, like
hub, switch, and repeater. For example, if implemented as
simple hub or repeater, data messages have to be transmitted to
all other portals within the EDS. Whereas, to support switching
or bridging some additional functionality is required, like
providing and maintaining address tables as well as making a
decision to switch.
2) Integration Service: So far, we have not yet discussed
the hard problem of protocol translations. In fact, in some
cases it is even impossible to translate one communication
protocol into another to establish an interconnection between
both networks. Basically, there are two methods for protocol
translation: protocol conversion and protocol adaption.
Protocol conversion addresses the conversion of the complete functionality of protocols at a specific layer in terms
of the provided services, interfaces, and the protocol’s set of
rules. Obviously, protocol conversion is not always applicable
for all scenarios. Therefore S. S. Lam [11] and K. Okamura
[12] developed a formal method to decide, whether a protocol
conversion is possible, or not. They also advice some construction methods, to build a protocol converter when protocol
conversion is possible at all.
In contrast, protocol adaption can be done in various ways.
Addressed by von Bochmann et al. [13], service concatenation tries to install a global communication service which is
built upon several basic communication services. This can be
achieved either by service adaption or interface adaption. In
both cases, protocols need not to be translated completely,
instead the translation of a small subset of services is adequate
to enable data transmission then.
B. Dealing with Dynamic
The multiple WSN architecture described so far is static,
because we have not defined any service which connects newly
entering sensor nodes to an existing WSN. This is sufficient
for simple hub and repeater functionality. Therefore, if the
functionality of a switch is desired and dynamic topologies
shall be supported as well, additional services at both SNS as
well as EDSS are required. That means, the protocol of the
relevant WSN has to offer services for the entering and leaving
of sensor nodes. With it, the EDS in turn has to offer services
for (dis)connection of sensor nodes. When these services are
invoked by those sensor nodes related to portals to introduce
newly added nodes of the corresponding WSN to the EDS,
the underlying protocol of this appropriate WSN must not
be changed. These services allow the EDS to update e.g. its
address translation table.
IV. O PERATION M ODES
Due to the modular and variable design of the EDS architecture (cf. Sec. III), the following operation modes become
feasible. As already mentioned before, these operation modes
are defined within the EDS according to the relationship of its
portals.
First of all, the functionality of a repeater can be implemented. That means, a pair of radio units is fixed permanently
in such a way, that a packet received at one node of this pair
will be transmitted immediately by the other node of that pair.
Due to a shared SPI bus, a short delay has to be accepted.
Next, if any received packet will be propagated over the
remaining radio transceivers without any deeper packet analysis, the functionality of a hub is implemented. Assumed, all
Fig. 2.
SuperG expansion board stacked onto RSK+ SH7203
radio units share the very same SPI bus, the broadcast of such
a message probably will be delayed noticeably.
Also possible is the functionality of a switch. Here, the EDS
has to analyze the MAC address of a received packet and to
store it within a source address table. Entries in this table and
the received MAC address determine, which radio device has
to further transmit this packet. If there are packets addressed to
unknown receivers, these packets are flooded to all remaining
transceivers.
All in all, our gateway architecture not only allows protocol conversion depending on the used MAC protocols, but
even offers some sort of media conversion when connecting
networks of different frequency bands.
V. S UPER G P LATFORM
We developed the SuperG platform, which will be described
within this section in detail, to first evaluate the suitability of
our gateway architecture from Section III and finally to analyze
the functionality of our hardware prototype when using one
of the operation modes named above.
Using a high-performance microcontroller, the handling of
multiple radio devices should become possible. Therefore, our
gateway node SuperG is based upon the Renesas Starter Kit+
(RSK+) for SH7203 [14]. The SH7203 is a superscalar 32bit RISC microcontroller, incorporating an SH2A-FPU core.
The maximum operating frequency is 200 MHz, peripheral
functions such as a CAN controller, a serial communication
interface, an USB host/server module, as well as an I2C bus
interface are already integrated into the microcontroller (cf.
[15]). In addition, the RSK+ evaluation board provides an
Ethernet controller and connector. Besides, we use a migration
of the real-time operating system SmartOS [16].
For wireless interaction, we developed a stackable expansion card consistent with the RSK+ evaluation board (see
Figure 2). Here, we focused on sub 1-GHz radio as well
as 2.4 GHz IEEE 802.15.4/ZigBee compliant radio systems,
because both radio systems can be found at a broad variety
15
of current sensor nodes (cf. Section I). In detail, we assembled four CC1100 radio units [17] and two CC2520 ZigBee
compliant radio devices [18]. For each CC2520 radio device
an inverted-F on-board antenna can be used alternatively. Each
radio unit can be connected to the SH7203 microcontroller via
both installed SPI buses. To provide the accurate timeline with
a temporal resolution of 1 µs as requested by the operating
system (cf. [19]), we attached an external 1 MHz quartz
oscillator onto the expansion board.
A first implementation of the hub (and repeater) functionality upon our prototype gateway was successful and promising:
Beside our SuperG prototype, we used several SNoW5 sensor
nodes at the 915 MHz band for these tests. For medium
access we used a proprietary CSMA protocol. To simulate
incompatible communication interfaces even if the radio units
are configured almost identically, we divided the set of SNoW5
sensor nodes into four disjoint subsets by using four different
frequency channels. According to these subsets, each CC1100
radio unit of the SuperG node was now connected to just
one of these subsets, i.e. it used the very same frequency
channel. Because the relationship of the corresponding portals
defines the operation mode of the gateway node, we just had
to connect there two specific portals with each other (to get
repeater functionality), and one specific portal to the remaining
ones (to get hub functionality) respectively.
VI. C ONCLUSION AND O UTLOOK
In this paper we introduced our approach of a multi-radio
gateway platform. After a short overview of existing gateway
nodes, we described our architecture in detail in Section III. In
Section IV we listed possible operation modes of our gateway
node, whereas we outlined our first hardware prototype in
Section V.
Currently, we are setting up additional (cf. Sec. V) realworld testbeds consisting of SNoW5 [4] and TelosB [5] sensor
nodes. With the help of these testbeds we hope to verify the
feasibility of all operation modes listed in Section IV under
real-world conditions. We also want to analyze and minimize
the delay when a packet passes the EDS of the SuperG
gateway. Additional server tasks, like information processing,
data gathering, or data preparation, could be installed also at
such a high-performance gateway node (cf. Figure 1). The
interconnection of further networks like the Internet (cf. Figure
1 again) or support for other network services, like tunneling
and remote management of data, are also part of our future
research. Finally, we want to analyze and minimize the energy
consumption of this gateway node and its radio chips in
particular.
16
R EFERENCES
[1] Pedro José Marrón, Daniel Minder, Andreas Lachenmann, Olga Saukh,
and Kurt Rothermel, “Generic Model and Architecture for Cooperating
Objects in Sensor Network Environments,” African Journal of Information & Communication Technology, vol. 2, no. 1, pp. 1–11, Mar. 2006.
[2] L. Atzori, A. Iera, and G. Morabito, “The Internet of Things: A survey,”
Comput. Netw., vol. 54, pp. 2787–2805, Oct. 2010.
[3] IEEE, IEEE Standard for Information technology - Telecommunications
and information exchange between systems - Local and metropolitan
area networks - Specific requirements, Part 11: Wireless LAN Medium
Access Control (MAC) and Physical Layer (PHY) Specifications (IEEE
Std 802.11-2007), IEEE Computer Society, New York, NY 10016-5997,
USA, Jun. 2007.
[4] M. Baunach, R. Kolla, and C. Mühlberger, “SNoW5 : a modular platform
for sophisticated real-time wireless sensor networking,” Institut für
Informatik, Universität Würzburg, Tech. Rep. 399, Jan. 2007.
[5] J. Polastre, R. Szewczyk, and D. Culler, “Telos: Enabling Ultra-Low
Power Wireless Research,” in Proceedings of the Fourth International
Conference on Information Processing in Sensor Networks, 25.-27. Apr.
2005.
[6] H. Karl and A. Willig, Protocols and Architectures for Wireless Sensor
Networks. John Wiley & Sons, Ltd, 2005.
[7] M. Yarvis and W. Ye, “Tiered Architectures in Sensor Networks,” in
Handbook of Sensor Networks: Compact Wireless and Wired Sensing
Systems, M. Ilyas and I. Mahgoub, Eds. CRC Press, 2005, ch. 13, pp.
1–22.
[8] Fraunhofer IIS, s-net Mobile Gateway - Produktinformation, FraunhoferInstitut für Integrierte Schaltungen (IIS), 2011.
[9] Sensinode Ltd., NanoRouter Ethernet 2.0 Reference Platform, Sensinode
Ltd., FIN-90100 Oulu, Finland, Mar. 2010.
[10] J. Ansari, X. Zhang, and P. Mähönen, “Multi-radio medium access
control protocol for wireless sensor networks,” IJSNET, vol. 8, no. 1,
pp. 47–61, 2010.
[11] S. S. Lam, “Protocol Conversion,” IEEE Trans. Softw. Eng., vol. 14, pp.
353–362, Mar. 1988.
[12] K. Okumura, “A formal protocol conversion method,” SIGCOMM
Comput. Commun. Rev., vol. 16, pp. 30–37, Aug. 1986.
[13] G. v. Bochmann and P. Mondain Monval, “Design Principles for
Communication Gateways,” IEEE Journal on Selected Areas in Communications, vol. 8, no. 1, pp. 12–21, Jan. 1990.
[14] Renesas Starter Kit+ for SH7203 – User’s Manual, Reg10j00600200 ed., SWRS038D, Renesas Electronics Corporation, Kanagawa
(Japan), 17. Jan. 2009.
[15] SH7203 Group – Hardware Manual, Rej09b0313-0300 ed., SWRS038D,
Renesas Electronics Corporation, Kanagawa (Japan), 28. Sep. 2009.
[16] M. Baunach, “Dynamic Hinting: Real-Time Resource Management in
Wireless Sensor/Actor Networks,” Real-Time Computing Systems and
Applications, International Workshop on, vol. 0, pp. 31–40, 2009.
[17] CC1100 Low-Power Sub-1 GHz RF Transceiver, SWRS038D, Texas
Instruments Inc., Dallas, Texas (USA), May 2009.
[18] CC2520 2.4 GHZ IEEE 802.15.4/ZIGBEE RF TRANSCEIVER,
SWRS038D, Texas Instruments Inc., Dallas, Texas (USA), Dec. 2009.
[19] M. Baunach, R. Kolla, and C. Mühlberger, “Introduction to a Small
Modular Adept Real-Time Operating System,” in 6. GI/ITG KuVS
Fachgespräch Drahtlose Sensornetze. RWTH Aachen University, Jul.
2007.
Wireless Sensor Actor Nodes
for the Building Automation
Hannes Frey, Rafael Funke, and Marcus Autenrieth
Harald Mundinger, Peter Detzner, and Roland Groll
University of Paderborn, Germany
{hannes.frey, rfunke, marcus.autenrieth}@upb.de
Insta Elektro GmbH, Germany
{mundinger, p.detzner, r.groll}@insta.de
Abstract—This work presents a snapshot of a joint industry
and academic research project on wireless sensor actor networks
for the building automation. We briefly present a new developed
generic sensor/actor node and a testbed support node. We further
explain the software parts which have been developed for this
project. This includes the porting of TinyOS on the developed
hardware platform and the additional software needed to control
test deployments.
Our hardware is a ready to use contribution to the wireless
sensor/actor network community working with real world indoor
deployments. The generic sensor/actor node together with the
testbed support node can be plugged into a PoE LAN. This
allows quick indoor deployments and convenient control over
testbed experiments.
I. I NTRODUCTION
Building automation is the monitoring and control of buildings with a network of sensors and actuators. Actuators
control building services like electric lighting, air conditioning, sunblinds, sprinklers, or door/window locking systems.
Sensors measure current physical parameters like temperature,
humidity, luminosity, smoke emission or motion. Furthermore,
simple sensors like switches or buttons allow direct actor
control by the user like lifting sunblinds or just turning on
the light.
The interplay of sensors and actuators requires them to be
networked together. Such sensor/actor network allows sending
control data to the actors and collecting sensor data from the
sensors. Networking can be wired, wireless or a mix of both.
The beauty of wireless networking is that it allows quick and
easy installation of building automation into already existing
buildings.
In this work we summarize the current status of a wireless
building automation communication platform we are developing together with an industry partner. The central part of that
project is a generic wireless network node which can serve as
a host for sensors, which can control actors or which can just
serve as a relay for sensor and control traffic between other
nodes. This device can be attached to a support node which
we developed in this project as well. Together with the support
node, the hardware can be attached to a PoE LAN. This allows
rapid testbed setups in buildings equipped with such LAN.
The remainder of this work is organized as follows. In
the next section we will briefly summarize the state of the
art of wireless building automation. In Section III we briefly
describe the generic wireless sensor/actor node and the support
node. Moreover, we sketch two testbed settings which we
plan to use for evaluating our developed wireless sensor/actor
network. After the hardware description we will then in
Section IV sketch the software parts developed in this project.
This includes the porting of TinyOS on our platform, our
networking approach, and our library to control field trials with
test deployments. Finally, in Section V we conclude this work
with arguments highlighting the benefits for other researchers
to use the hardware and software developed in this project.
II. R ELATED W ORK
A. Single-Hop Networks
KNX [4] is the international standard for wired networked
building automation. The standard describes how sensors
and actors are networked and defines the network protocols
between them. A variant KNX RF allows wireless sensors
or actors at the “last mile”, i.e., messages can be transmitted
wireless from the core wired network to the sensor or actor
device.
The EnOcean alliance [1] focuses on miniaturized energy
converters which allow the energy of a pressed button to be
converted in a short radio signal which can then be received
by an electricity powered base station. This allows an easy
installation of control buttons (e.g. to switch on and off the
light) without the need for external or battery power supply.
The IO-Homecontrol alliance [3] offers products for remote controlling IO-Homecontrol compatible home automation products. The technique is based on a direct communication between controller and actor. The communication range
covers the common private real estate market.
B. Multi-Hop Networks
Z-Wave [8] is a wireless communication standard for the
building automation which also enables wireless multihop
communication. The multihop communication is based on a
combination of link-state and source routing. Mutual connectivity among nodes is first determined and collected at a central
node. Communication paths are computed before routing starts
and stored in the message.
The INSTEON [2] alliance also allows wireless multihop
communication in building automation. Multihop communication is based on plain flooding. Every node repeats a received
message. To increase success rate, nodes repeat this message
several times.
17
Wavenis [6] is a wireless communication platform used
for automatic measurement and monitoring of smart meters.
As shown in a large-scale monitoring case study in Sables,
France, multihop communication from sensors to a data sink
is achieved in networks organized as a tree. With such a
tree a very high scale network (e.g. 25.000 nodes) can be
constructed.
ZigBee [7] is a standard for low powered embedded devices
not specifically focused on building automation. Physical and
link layer including MAC are based on the IEEE802.15.4
standard. ZigBee specifies network and application layer.
Building automation is one application scenario described in
the ZigBee standard. The standard allows multihop wireless
communication with a hierarchical network organization using
so called PAN coordinators to manage a set of wireless
attached devices.
B. Support Nodes
A further requirement in the whole project is to enable
easy experimental evaluation of single nodes and a network of
nodes. This includes flashing of new firmware images, sending
data to and receiving data from already deployed nodes. To
avoid bias of the experimental wireless network evaluation,
all control traffic has to be transmitted over a separate wired
control network.
III. H ARDWARE
A. Generic Network Nodes
(a) Casing
The main requirements for the generic wireless sensor/actor
network nodes are small form factor and low price. In the
current project status we consider nodes with standardized
wall mounted electrical outlet or light switch sizes. Processing
of information on the node is limited to low cost micro
controllers. The micro controller must support 32 kilobyte
flash ROM to store network controller code and 5 kilobyte
RAM for storing network related node status like information
about neighboring nodes. For compatibility of physical layer,
link layer and MAC with other hardware we have to use IEEE
802.15.4. Power consumption is to be limited to less than one
Watt to comply with industry standards for building automation. Energy consumption needs not further be reduced, since
the nodes will finally be attached to the building electricity,
i.e., energy efficiency is not as critical as with battery operated
sensor/actor nodes.
(a) Front side
Fig. 1.
(b) Electronics
Support node prototype
To keep the actual developed sensor/actor nodes independent from additional hard and software needed for the experimental evaluation, we developed a further support node where
the sensor/actor node can be attached to (see Fig. 2). Combined
together the two nodes form a complete experimental node
unit. Communication between both parts in that unit is done
via a UART interface.
The support node is built around an Atmel AT91SAM
micro controller unit and a Davicom DM9161AEP Ethernet
controller. The support node has to be attached to a power over
Ethernet (PoE) LAN. It supports the wireless sensor/actor node
with electricity and allows flashing images, sending data to
and receiving data from the sensor/actor node over a standard
Ethernet. Addressing of the support nodes is done via IP
addresses which are acquired via DHCP.
(b) Back side
Generic network node prototype
The current prototype depicted in Fig. 1 consists of an
Atmel ATMega 1281 micro controller and an Atmel ATRF 231
transceiver unit. It has two LEDs for rudimental debugging
output. It has four user buttons which can be integrated in
standard light switch casings. With exception of the form
factor, the node design is close to the one of the IRIS motes
[5].
18
Fig. 2.
(a) Single PoE attached node unit
Fig. 3.
(b) Grid
Example Deployments
C. Testbed Setups
With their standard Ethernet adapter, the support nodes
allow a rapid deployment of nodes to construct a test network.
We consider two deployments in this project (see Fig. 3). To
evaluate the standard use case, we deploy the node units in a
university building by just utilizing free PoE sockets in each
room. To further evaluate an extreme setting of many nodes
collocated in the same collision domain we assembled six 4x12
grids of 1.3 m × 0.5 m size. In each grid the single units are
attached to a 48 port PoE switch. This allows easy integration
of such grids into an Ethernet LAN.
Fig. 4.
Example Network with MIS Clustering. Filled circles represent
cluster heads, unfilled circles represent cluster members and triangles represent
gateways
IV. S OFTWARE
A. TinyOS Porting
We ported TinyOS to our platform to benefit from its
reusability and transparent programming model. TinyOS enabled us to unit-test central parts of our system in the TinyOS
simulator TOSSIM, as well as produce hardware independent
code.
Our hardware platform closely resembles the Iris platform,
using identical microcontrollers and radio chips. Because of
that, we could reuse much of the existing TinyOS codebase
and only had to write adapter-code where our platform differs.
One large difference to other TinyOS platforms is the onchip bootloader mechanism. Our platform uses the UART1 for
the on-chip bootstrap loader, as well as for communicating
with the connected support nodes. Because of that, we had
to adapt the low level driver code of TinyOS to support both
functionalities in parallel.
To activate the bootloader on the microcontroller two magic
bytes have to be received: the first one writes a flag byte
into EEPROM, the second reboots the microcontroller. Upon
reboot, the bootloader is executed first, looks for the flag byte
in the EEPROM and upon finding it, listens for the incoming
image on the UART. If the bootloader does not find the flag
byte in the EEPROM, it executes the main program.
Since the bootloader is activated by two magic bytes sent
over the UART by the support node, we had to insert a
byte-escaping mechanism into the UART communication stack
of TinyOS. This prevents normal communication data to
accidentally trigger the bootloader.
B. Network Control
As broadcast traffic is our biggest concern, we chose to thin
out the network topology. That reduces redundant retransmissions and the risk of collisions. We realize the thin topology
by building a connected dominating set (CDS) on top of the
network topology. A dominating set (DS) is a subset of nodes
such that each node is either in the subset, or is a neighbor of
a node in the DS. A CDS is a DS where the subset of nodes
forms a connected graph. We realize the CDS by building a
maximal independent set (MIS) clustering and by choosing
gateways to connect the cluster heads. The MIS gives us a
set of nodes, called cluster heads, such that each node is
either cluster head or one-hop neighbor of a cluster head and
no two cluster heads are one-hop neighbors of each other.
The gateways are necessary to build connections between the
cluster heads. Figure 4 shows an example.
We chose a MIS-clustering approach in our project, because
it can be built based on local decisions. Even repairing the
structure upon node failures or link failures can be done
locally. Thus, the approach scales well for large networks.
Building the MIS is done with a simple contention-based
local decision rule. If a node is a one-hop neighbor of a
cluster head, it becomes a member of this cluster head.
Otherwise it becomes cluster head. For finding gateways to
build up connections between clusters, each cluster head starts
a discovery to find the clusters that can be reached with at most
three hops.
The CDS structure may be destroyed if nodes fail due
to depleted batteries or if links fail due to slow fading for
amounts of time that are significantly longer than a packet
transmission time. In these cases the MIS structure and the
gateway paths need to be repaired. To keep up the MIS
structure, nodes can periodically check if they can still reach
their cluster head. If not, they search for other cluster heads
in their one-hop neighborhood. If they find any, they join as
member, otherwise they become cluster heads. Keeping up the
gateway structure is done by periodic rediscovery.
C. Testbed Control
The testbed is controlled by communicating with the support
nodes. As these nodes are powered and interconnected via
Ethernet, PoE switches are needed for the communication
infrastructure.
Upon power-up the support nodes use DHCP to form an
IP network. Once the network is established, the nodes can
be controlled via a custom protocol, encapsulated in UDP
Packets.
To control the nodes, a computer first has to announce
its presence by a broadcast packet, upon which all support
nodes register themselves to that computer, which in turn
assigns them special IDs. These ID’s can later be used by
the controlling computer to send multicast messages to the
network of support nodes.
All messaging over the support node’s IP network happens
via UDP packets, which encapsulate our custom protocol. The
following operations are currently supported by the protocol:
1) Discovery: is the function where the controlling computer sends out a broadcast, upon which support nodes respond
with a registration request which is answered with and ID
assignment by the computer.
19
2) Reset: is a simple software-reset for the whole unit of
support and sensor node.
3) Identify: An LED on the sensor node can be switched
on and off over the network to visually find and identify a
node.
4) UART Tunnel: The sensor nodes are coupled to the
support nodes via a UART bridge which can be used to
communicate with the software on the sensor node.
5) Firmware Update: Via the UART bridge the support
node also puts the sensor nodes into bootloader mode and
sends new firmware images to it.
To control a network of support nodes via this protocol,
we have developed a library in the Python programming
language. The library centers around a language for describing
packet structures in a C-like fashion, which is embedded into
Python. The library realizing this embedded language works
standalone and can also be used for other message protocols.
Figure 5 shows how a message can be specified by using a
simple C struct. The example in Figure 6 shows how such
a message format can then be specified in Python. Once
specified, the message structure can then be used to encode
and decode binary data.
struct message {
uint8_t id;
uint8_t len;
uint8_t data[MAX_LEN];
};
Fig. 5.
A message specified using a C struct
from striptease import Struct, uint8
message = Struct().append(
uint8(’id’),
uint8(’len’),
uint8(’data’)[’len’],
)
Fig. 6.
A message specified using the striptease library
V. C ONCLUSION
In this work we summarized the hard and software developed in the LightOn project, a joint project between the
University of Paderborn and the Insta Elektro GmbH.
Though there are sensor network nodes available on the
market, the specific needs in this project and also a desired
vendor independence of the building automation product produced by the industry partner drove us to develop our own
hardware. The sensor actor node part is close to the IRIS Mote
architecture. The combination of the sensor actor nodes with
the support node goes beyond this architecture. As one node
unit it turns out to be very practicable when it comes to real
testbed deployments.
Though the nodes were developed with the project specific
requirements in mind, they are generic enough to support
20
other research projects as well. We see them as a possible
contribution for other researchers who want to rapidly set
up indoor testbed deployments. The hardware including the
TinyOS port can be ordered by contacting the authors of
this work. Circuit layout and source code can on request be
provided as confidential information.
Our solution requires that Ethernet with PoE is available.
In industry or university buildings a Ethernet infrastructure
is most commonly available. Even if PoE is not supported,
switches in the infrastructure can easily be replaced by PoE
supporting switches. If replacing switches is not an option,
PoE adapters can be used where the node units are plugged
into the infrastructure. This requires however a power plug
close by the node is deployed.
ACKNOWLEDGEMENTS
This work is funded in part by the BMWi/AiF ZIM research
grant LightOn, grant number KF2071406KM9, a cooperative
research project of the University of Paderborn and the Insta
Elektro GmbH.
R EFERENCES
[1]
[2]
[3]
[4]
[5]
EnOcean Alliance. www.enocean-alliance.org.
INSTEON. www.insteon.net.
IO-homecontrol. www.io-homecontrol.com.
KNX Association. www.knx.org.
MEMSIC: Wireless Modules, IRIS, MicaZ, TelosB, Imote2, Cricket.
www.memsic.com.
[6] Wavenis Open Standard Alliance. www.wavenis-osa.org.
[7] ZigBee Alliance. www.zigbee.org.
[8] Z-Wave. www.z-wave.com.
INGA - Architektur eines universell einsetzbaren
Sensorknotens
Ulf Kulau
Felix Büsching
Institut für Betriebssysteme und Rechnerverbund
TU Braunschweig
Email: [email protected]
TU Braunschweig
Wolf-Bastian Pöttner
Lars Wolf
TU Braunschweig
TU Braunschweig
Ausgangspunkt für unsere Arbeit war eine Analyse vorhandener und frei erhältlicher Sensorknoten. Da wir in mehreren
Projekten ”Contiki” als Betriebssystem einsetzen, fiel ein
besonderes Augenmerk bei der Analyse auf den weit verbreiteten TMote Sky und auf den Atmel AVR Raven. Im
FP7-Projekt GINSENG [1] sind wir des Öfteren an die
Grenzen des adressierbaren Speichers des MSP430 Microcontrollers im TMote Sky gestoßen und auch der Energiebedarf
dieses Knotens ist verhältnismäßig hoch. Beim GAL-Projekt
[2] und den dort verwendeten AVR Raven Sensorknoten
störten die Größe, die schlechte Handhabbarkeit und das
ungeeignete Sensorset. Letztendlich haben wir uns für eine
Basis-Architektur bestehend aus einem AVR Amega1284p und
einem AT86RF231 entschieden. In Hinblick auf den Einsatz
des Sensorknotens in Forschung und Lehre, ist die große
AVR Community, welche den Einstieg in die Programmierung
erleichtert, ein weiteres Argument für unsere Entscheidung.
Die Auswahl der Sensorik richtet sich primär an Anforderungen aus dem medizinischen Umfeld: Zum Messen von
Beschleunigungen wird ein Accelerometer eingesetzt, welches
die Kraft, die auf eine seismische Masse wirkt, in drei
Dimensionen quantifiziert. Damit lassen sich Bewegungen
und Bewegungsabläufe erkennen, die ein Körper vollzieht,
an welchem der Sensor befestigt ist. Auf diese Weise lassen
sich Stürze erkennen oder auch Ganganalysen durchführen.
Da jeweils auch die Erdbeschleunigung gemessen wird, lässt
es sich auch für eine Lagebestimmung nutzen. Zur genaueren
Lagebestimmung und Erkennung von Richtungsänderungen
SPI
UART / USB
UART / USB
FTDI232
FTDI232
UART0
Flash Flash Memory
Memory
AT45DBxx1
AT45DBxx1
I/O
MCU / CPU
MCU / CPU
ADC
ADXL345
ADXL345
Pressure / Temp
Pressure / Temp
Sensor
Sensor
BMP085
BMP085
UART0 RX/TX
Gyroscope
Gyroscope
L3G4200D
L3G4200D
GPIO / ADC
Power Power Monitoring
Monitoring
Acceleration
Acceleration
Sensor
Sensor
I²C Bus
ATmega1284p
ATmega1284p
Battery Charger
Battery Charger
MicroSD
MicroSD
Card
Card
MSPI Bus
AREF
I. E INLEITUNG
Transceiver
Transceiver
802.15.4
802.15.4
AT86RF231
AT86RF231
User LEDs
User LEDs
User Switch
User Switch
JTAG Header
JTAG Header
PCB Antenna
PCB Antenna
MSPI Chip Select
Abstract—Nachdem wir einige Erfahrung auf dem Gebiet
der drahtlosen Sensornetze gesammelt haben, haben wir uns
entschieden, einen weiteren – eigenen – Sensorknoten zu entwickeln. Ziel war es dabei, die Stärken vorhandener Sensorknoten
möglichst zu kombinieren und die Schwächen zu minimieren.
Außerdem war es uns wichtig, ein Set an aktuellen Sensoren
anzubinden, welche eine Aktivitäts- und Bewegungsüberwachung
erlauben. Heraus kam dabei INGA - ”Inexpensive Sensor Node
for General Applications”.
Pin Header (2.54mm)
Pin Header (2.54mm)
Fig. 1.
Architektur von INGA.
kommt ein micromechanisches Kreiselinstrument zum Einsatz. Das verwendete Gyroskop kann Änderungen von bis
zu 2000 Grad pro Sekunde in drei Dimensionen detektieren.
Ebenfalls zur Ganganalyse, bzw. zur Aktivitätserkennung kann
der Luftdrucksensor verwendet werden; er ist in der Lage,
Luftdruckänderungen im Bereich von bis zu 0,01 hPa zu registrieren, was einer Höhenänderung im Bereich von wenigen
Zentimetern entspricht. Zur Temperaturkompensation ist ein
Temperatursensor integriert, was auch die Bestimmung des
absoluten Luftdrucks erlaubt.
II. A RCHITEKTUR
In Abbildung 1 ist ein Blockschaltbild des INGA Sensorknotens zu sehen: Herzstück ist die ATmega1284p MCU, die
auch beim Atmel AVR Raven zum Einsatz kommt. Als Funktransceiver kommt hier aber der neuere und leistungsfähigere
AT86RF231 zum Einsatz, der unter anderem auch eine Hardwareunterstützung für AES bietet.
A. PCB-Antenne
Die Sendereichweite der AVR-Raven hat sich in unseren Untersuchungen als sehr gut herausgestellt. Da eine
21
micro SD
micro SD
C. Power Management und Monitoring
Sobald INGA von der USB - Schnittstelle getrennt wird,
besteht keine Notwendigkeit mehr, den FTDI232 weiterhin
mit Spannung zu versorgen. Die kontrollierte Ladung des
Lithium-Ionen-, bzw. Lithium-Polymer-Akkus erfolgt durch
einen Maxim Max1555, welcher maximal 100mA Ladestrom
aus dem USB abzieht, um einen 1 Zellen Akku aufzuladen.
Das Design sieht alternativ eine Versorgung über ’normale’
Batterien bzw. andere externe lineare Spannungsquellen vor,
wobei Batterien durch eine Diode vor parasitären Ladeströmen
geschützt werden. Eine interne Temperaturkontrolle reduziert
bei zu hoher Chiptemperatur den Ladestrom, sodass eine
Beschädigung des Akku vermieden werden kann. Für das
Power-Monitoring werden zwei Kanäle des internen ADC
des ATmega1284p genutzt, um die Akku- / Batteriespannung
sowie den Versorgungsstrom des Sensorknotens über die Zeit
zu ermitteln. Hierfür wurde ein Impedanzwandler bestehend
aus einem Operationsverstärker durchaus Sinn ergeben, doch
in Hinblick auf ein energiesparendes Design würde eine
zusätzliche Belastung des Akkus die Folge sein. Die minimalistische Lösung eines hochohmigen einfachen Spannungsteilers ist durch die hohe Eingangsimpedanz des ADC möglich
und daher vorzuziehen.
D. MSPI-Bus
Der USART des ATmega1284p kann alternativ als MSPI
(Master SPI) genutzt werden. Die MCU (ATmega1284p) dient dabei als Master und hat die Aufgabe den jeweiligen
Kommunikationspartner (Slave) über eine Chip-Select Leitung
(CS) explizit auszuwählen, sowie den Takt (SCK) zur synchronen Datenübertragung zu generieren. Für jeden Slave wird
demnach eine eigene Chip-Select-Leitung benötigt, sodass
der Verdrahtungsaufwand bei 3+n liegt. Um den Aufwand
an GPIOPins der MCU zu reduzieren, wird im INGA ein
22
USART1
MSPI
MCU / CPU MCU / CPU Atmega1284p Atmega1284p SCK
SDO
SDI
CS
SCK
SDO
SDI
CS
SCK
SDI
SDO
CS
Flash Memory
Flash Memory
AT45DBxx1
AT45DBxx1
Acceleration Acceleration Sensor
Sensor
ADXL345
ADXL345
Tri Sate Buffer
Tri Sate Buffer
Enable
MOSI
MOSI
MISO
MISO
SCK
PA5
PA6
1of8 demultiplexer
1of8 demultiplexer
PA7
Ext. SPI Interface
Ext. SPI Interface
Der UART kann zur Kommunikation mit einem HostPC verwendet werden, wovon auch beim INGA Gebrauch
gemacht werden soll. Die Designanforderungen des INGA
sehen deshalb eine Unterstützung der USB Schnittstelle vor,
welche durch ein FTDI232, einem UART-USB-Konverter,
realisiert wird. Diese Lösung findet sich u.A. auch im Tmote
Sky wieder und bietet mehrere Vorteile:Mit der Fähigkeit
des ATmega1284p, den UART mittels eines Bootloaders als
Schnittstelle zur Programmierung des Programmspeichers zu
nutzen, kann somit die USB-Schnittstelle des INGA sowohl
zur Kommunikation (z.B. Debug-Ausgaben printf ) wie auch
als Programmierschnittstelle genutzt werden. Die vom USB
gelieferte Leistung wird außerdem genutzt, um über einen
Laderegler den LiPo-Akku des INGA aufzuladen.
Enable
PORT A
I/O
B. UART/USB Interface
Vcc
’gedruckte’ PCB-Antenne noch dazu billig ist, haben wir
uns entschieden, dieses Antennenlayout einfach aus den Designrichtlinien von Atmel zu übernehmen. Als Nachteil kann
hier jedoch die Größe gesehen werden: knapp die Hälfte des
Sensorknotens ist ”Antenne”.
SCK
CS3
CS4
PA4
Fig. 2.
Der MSPI-Bus.
Demultiplexer eingesetzt, sodass für n Slaves lediglich i =
log2(n) I/O-Pins verwendet werden müssen. Das Logik-IC
74LCX138 leistet das gewünschte Verhalten eines 1-of-8 Demultiplexers mit lowaktiven Ausgangspins zur Selektion der
einzelnen Slaves.
Nach Auswahl des Slave über die Chip-Select Leitung,
wird auf der MOSI Leitung (Master Out Slave In) die
Adresse des Registers übertragen, welches man lesen oder
schreiben möchte. Je nachdem, ob es sich dabei um einen
Lese- oder Schreibzugriff handelt, werden anschließend taktsynchron Daten vom Master an das Slaveregister gesendet
(MOSI), oder der Slave sendet ebenfalls taktsynchron Daten
über die MISO Leitung (Master In Slave Out) an den Master.
Die Übertragung wird durch das lösen der Chip-Select Leitung
beendet. Die auf dem INGA eingesetzten Slaves sind ein
Flash-Speicher (AT45DBxx1 series), ein Beschleunigungssensor ADXL345 und ein Slot zur Verwendung einer microSD
Karte. Zusätzlich sind das MSPI und zwei weitere Chip-Select
Leitungen auf das User-Interface geführt und ermöglichen bei
Bedarf den Anschluss weiterer Slaves (vgl. Abbildung 2) in
Form von Sensoren, Speichern oder anderer SPI kompatibler
Komponenten.
E. Micro-SD-Card
Zusätzlich zum internen Speicher der MCU und des
onboard-Flash-Speichers ist als flexibles Speichermedium die
Möglichkeit zur Verwendung von microSD Karten vorgesehen.
Neben dem Vorteil eines austauschbaren Datenträgers, ist eine
microSD Karte als Consumer-Produkt sehr gut verfügbar und
lässt sich über das integrierte SPI Interface komfortable in ein
Mikrocontrollersystem integrieren. Dennoch ist die Verwendung einer microSD Karte nicht vergleichbar mit anderen SPIfähigen Komponenten und gerade im mobilen Einsatz stellt
sich die Frage, wie man die hohe Leistungsaufnahme (Isd ¡
45mA) der microSD Karte begrenzen kann. Ein Problem mit
dem SPI der microSD Karte entsteht dann, wenn sich mehrere
Slaves den Bus teilen. Zur Initialisierung müssen an die
microSD Karte mindestens 74 Takte auf der SPI Taktleitung
(SCK) gesendet werden, allerdings bei Nichtaktivierung des
Chip-Select[42]. Nun ist es aber so, dass sich klassischerweise
alle am Bus befindlichen Komponenten die Signalleitungen
MOSI, MISO und SCK teilen, sodass der Fall von Takten auf
der SCK-Leitung bei nicht gewählter microSD Karte durchaus
SDA
Ext. SPI Interface
Ext. SPI Interface
Atmega1284p Atmega1284p Pressure and Pressure and Temperature Temperature Sensor
Sensor
BMP085
BMP085
SCL
SCL
TWI
I²C
MCU / CPU MCU / CPU SDA
Gyroscope
Gyroscope
L3G4200D
L3G4200D
SDA
SCL
Fig. 3.
SDA
SCL
Der I2 C-Bus.
eintritt. Eine einfache Möglichkeit, welche auch das Problem
der hohen Leistungsaufnahme löst, ist das Abschalten der
Versorgungsspannung bei Inaktivität. Leider zeigt sich, dass
microSD Karte aufgrund des internen Aufbaus ihres Interfaces
auch über ihre I/O-Leitungen mit Strom versorgt werden kann.
Mit einem Tri-State Buffer ist es möglich, die microSD Karte
komplett vom Bus zu isolieren, da dieser wahlweise einen
hochohmigen Zustand annehmen kann. In Abbildung 2 ist
diese Lösung schematisch illustriert.
F. I2 C-Bus
Der zweite im INGA eingesetzte Peripherie-Bus ist der I2 C.
Im Gegensatz zum MSPI ist der Leitungsaufwand deutlich
geringer, da unabhängig von der Anzahl eingesetzter Slaves,
lediglich zwei Leitungen (Serial Data (SDA), Serial Clock
(SCL)) zur Auswahl eines Slave und zur bidirektionalen
Kommunikation benötigt werden. Ein Slave wird dabei mittels
einer 7 Bit breiten Adresse ausgewählt. Die auf dem INGA
eingesetzten Slaves sind ein 3-Achsen Gyroskop mit integriertem Temperatursensor (L3G4200D) und ein Luftdrucksensor
(BMP085), welcher ebenfalls über einen internen Sensor zur
Temperaturmessung verfügt. Zusätzlich sind SCL und SDA
auf das User-Interface geführt und ermöglichen bei Bedarf
den Anschluss weiterer Slaves (vgl. Abbildung 3) in Form von
Sensoren, Speichern oder anderer kompatibler Komponenten.
III. AVRDUDE KOMPATIBLER B OOTLOADER
Die klassische Variante, ein kompiliertes Programm in den
On-Chip Flash - Programmspeicher eines AVR Mikrocontrollers zu schreiben oder auszulesen (Upload / Download), ist
die Benutzung des ISP (in System Programmer) oder der JTAG
(Joint Test Action Group) Schnittstelle. Beide Methoden setzen jedoch den Einsatz einer separaten Hardware voraus,was
einen zusätzlichen Kostenaufwand und Umstand bedeutet. Des
Weiteren ist ein Update von im Feldversuch eingesetzten Sensorknoten immer mit einem relativen Aufwand verbunden, da
der Sensorknoten und ein entsprechender Programmieradapter
lokal verfügbar sein müssen. Die Fähigkeit von AVR Mikroprozessoren zur Nutzung eines bestimmten Bereiches ihres
Programmspeichers als Bootloader-Section, bietet eine sehr
flexible Basis, um auch zukünftige Anforderungen erfüllen zu
können. Auch das Problem der lokalen Verfügbarkeit eines
Sensorknotens für ein Softwareupdate, lässt sich somit erschlagen, indem zukünftig ein Wireless-Softwareupdates realisiert
werden kann. Ein Anforderung an den Bootloader ist die
Kompatibilität zum Host Programm AVRDUDE. Dies ist ein
plattformunabhängiges Open Source Programm, welches die
Übertragung eines kompilierten Programmes auf dem Mikrocontroller koordiniert und verifiziert. Ein weiterer Vorteil ist
die direkte Integration in eine Entwicklungsumgebung (u.A.
Eclipse), sodass durch den Bootloader ein Programmieren des
INGA via USB direkt aus der Entwicklungsumgebung möglich
wird.
Als eigentlicher Flaschenhals kristallisierte sich die standardmäßig geringe Übertragungsrate des UART heraus. Aufgrund der asynchronen Übertragung ist das Zeitverhalten des
UART wichtig für eine fehlerfreien Übertragung, da lediglich
ein Startsymbol den Beginn einer Übertragung signalisiert
und die Abtastung aufgrund der vereinbarten Baudrate stattfindet. Nicht jede Baudrate wird von einem Host unterstützt,
sodass man sich an den standardisierten Übertragungsraten
orientieren muss, wenn man die Übertragungsgeschwindigkeit
seitens des Mikrocontrollers erhöhen möchte. Genau dabei
entsteht allerdings ein Problem, den die Baudrate des UART
ist abhängig von der Taktfrequenz des Mikrocontrollers.
Unsere Implementierung einer Optimierung im Bootloader bietet eine um den Faktor 6 schnellere UART-Übertragungsrate,
sodass z.B. die Übertragung von Contiki weniger als 5 Sekunden benötigt.
IV. E RGEBNIS
Eine komplette und ausführliche Darstellung aller
Eigenschaften und Besonderheiten von INGA bedarf eines
größeren Raumes und wird in naher Zukunft und auch
mit ersten Messergebnissen folgen. Nach unserem Ermessen
vereint INGA die Vorteile früherer Sensorknoten und ist dabei
klein, kostengünstig und stromsparend. Die umfangreiche
Sensorik eignet sich besonders zur Aktivitätsüberwachung im
medizinischen Umfeld, ist aber genausogut auch universell
einsetzbar. ”Contiki” wird als OpenSource-Betriebssystem
unterstützt und der Sensorknoten ist als OpenHardware
konzipiert, sodass er frei nachgebaut und verändert werden
darf. Es kommen nur bleifreie Materialien zum Einsatz
und auch auf Produkte aus ”seltenen Erden” (Coltan/Tantal)
wurde bewusst verzichtet. Auch wenn wir die Prototypen
bestücken lassen haben ist nicht unmöglich, die einzelnen
Bauteile selbst zu löten, bzw. die 2-Layer-Platine selber zu
ätzen. Alle Pläne und Dateien werden auf den Webseiten des
Projekts zur Verfügung gestellt, sodass ein Nachbau bzw.
eine Anpassung an eigene Projekte möglich ist.
R EFERENCES
[1] B. Srean, J. Silva, L. Wolf, R. Eiras, T. Voigt, U. Roedig, V. Vassiliou, and
G. Hackenbroich, “Performance control in wireless sensor networks: the
ginseng project - [global communications news letter],” Communications
Magazine, IEEE, vol. 47, no. 8, pp. 1 –4, august 2009.
[2] M. Eichelberg, A. Hein, F. Büsching, and L. Wolf, “The gal middleware
platform for aal,” in e-Health Networking Applications and Services
(Healthcom), 2010 12th IEEE International Conference on, 2010, pp.
1 –6.
23
24
We Must Move – We Will Move:
On Mobile Phones as Sensing Platforms
Delphine Christin, Matthias Hollick
Secure Mobile Networking Lab
Technische Universität Darmstadt,
Mornewegstr. 32, 64293 Darmstadt, Germany
{delphine.christin, matthias.hollick}@seemoo.tu-darmstadt.de
Abstract—Even after more than a decade of research in the
field, wireless sensor networks have not yet crossed the chasm:
they are still in the early adoption phase and large scale deployments are missing. Sensor network research has long focussed
on developing (mostly incremental) improvements on platforms
to be, e.g., more simple and/or energy efficient. In this process,
the self-imposed limitations led to mainly static deployments of
small scale sensor networks. As a result, wireless sensor networks
are not yet the commodity envisioned by many researchers in
the field of environmental monitoring or pervasive computing.
This trend has also impeded research into directions such as
mobile sensor networks, which in contrast require platforms with
increased complexity. We argue that mobile sensing platforms
are well suited for a wide variety of tasks, and they are readily
available in the form of mobile phones. We discuss the strengths
and limitations of mobile phones against contemporary dedicated
sensing platforms and highlight pros and cons in light of realistic
application scenarios.
I. I NTRODUCTION
For more than a decade, researchers have been betting on the
imminent deployment of large scale sensor networks and have
designed and developed a plethora of solutions to operate these
networks. Amongst others, the vision of Berkeley researchers
that envisioned ”Smart Dust” [1] has been influencing the
WSN research agenda towards a ”race to the bottom”, i.e.,
constantly decreasing size and energy consumption through
increasing hardware integration. At the same time, research has
investigated an abundance of protocols for more efficient, e.g.,
medium access control or duty cycling of sensor platforms.
However, this development has not yet led to a widespread
deployment of sensor platforms outside highly specialized
niche applications; in brief, WSNs are still not a commodity.
One can even observe a converse effect: the constant push
towards ever more efficient and lightweight sensing platforms
has hindered innovation in terms of functionalities and capabilities. Dseployments are mostly static and small scale to allow
for maintenance of the sensors, retail prices of off-the-shelf
sensing platforms have stagnated, and novel platform designs
merely enter the market.
Recently, a radically different sensing approach has been
proposed: mobile and participatory sensing [2], [3]. Instead
of deploying dedicated sensing platforms, mobile phones
(smartphones) fulfill the sensing role. In contrast to contemporary sensor platforms, mobile phones have been constantly
improving in performance with respect to CPU and memory
resources, and communication capabilities. Most notably, the
sensors integrated in mobile phones are getting more and more
sophisticated.
We argue that mobile sensing platforms are well suited for a
wide variety of sensing tasks. We introduce two representative
scenarios for sensor networks in Section II and discuss the
strengths and limitations of mobile phones as well as of
dedicated sensor platforms in Section III. We find that multiple
factors are in favor of mobile sensing platforms, yet some
limitations and constraints have to be acknowledged and
require further research. In Section IV, we discuss our findings
and conclude this paper.
II. S ENSING S CENARIOS
Among the wide range of applications, we select two representative scenarios for WSN deployments: personal health
monitoring and environmental monitoring. In both scenarios,
we compare the utilization of both wireless sensor networks
and mobile phones as sensing platforms. We provide examples
for deployments for both scenarios and compare the possibilities offered by both kinds of networks.
A. Personal Health Monitoring
Wireless sensors networks, and more particularly, body area
sensor networks (BASNs), are commonly used in healthcare
scenarios. Usually, the monitored person wears specialized
sensors on her body, which measure physiological parameters,
such as blood pressure and body temperature [4], or the body
acceleration. The BASN can be completed by static sensors,
collecting information about the environment of the monitored
person (subject), such as temperature, light, motion, and dust
levels (see [5]), and deployed in rooms frequented by the
subjects. Both worn and external sensors can be tasked to
monitor daily activities, detect movements and track location,
detect critical events such as falls of the subjects, or derive
their medical status [6]. Concrete applications include assisted
living for elderly citizens or home care of recently hospitalized
people, who require constant monitoring, but not necessarily in
hospitals. The remote monitoring allows these persons to stay
in a familiar environment while being kept under observation.
These deployments, however, raise some practical issues.
Typically, the wearable sensors are resource-constrained devices, which are specially designed to be non-invasive, and
25
thus small in size. The resulting limits in processing capabilities require the introduction of base stations to gather
the sensor readings and perform complex event processing.
As a result the coverage of the base stations has to be
planned, or else provides a virtual barrier for the monitored
subject. Moreover, the energy budget of the sensors has to
accommodate for constant transmission of critical parameters
to the nearest base station. Finally, the monitored people are
more likely to reject such additional devices.
In comparison, mobile phones have become everyday objects, which are generally familiar to the subjects carrying
them. By using the embedded sensors or interfaced sensors
(e.g., wearable accelerometers or air pollution sensors), the
mobile phones can also be used to monitor physiological
state and health issues, without limiting the mobility of the
monitored people. One sample application that capitalizes
on mobility is MobAsthma [7], which monitors the asthma
condition of the subjects and their exposure to pollution. A
peak flow meter and a pollution sensor are interfaced to the
mobile phone via a Bluetooth connection, and measure the
volume of air inhaled and expired along with the surrounding
airborne particle concentration. These measurements, coupled
with the patients’ location, are made available to allergists
to investigate the relationships between asthma attacks and
exposure to air pollution.
Another example, DietSense [8], assists people, who want
to lose weight by documenting their dietary choices through
images and sound samples. The mobile phones are worn on
necklaces and automatically take images of the dishes in front
of the users. The images document the food selection and
allow for an estimation of the food weight and waste on
the plates. Moreover, the mobile phones capture the context
during the meals by recording time of day, location, and
sound samples to infer potential relationships between the
user behavior and his context. The captured data are uploaded
to a personal repository and are accessible by doctors and
nutritionists.
B. Environmental Monitoring
In addition to personal health monitoring, both wireless
sensor networks and mobile phones can be tasked to monitor
the environment. For examples, sensor nodes can be deployed
in indoor or outdoor scenarios to monitor the temperature,
brightness, and humidity and measure the ambient conditions.
Such deployments remain, however, static and ensure only
a limited coverage that can only be determined in advance.
Unpredictable events may therefore not be recorded by these
sensors.
In contrast, mobile phones are carried by the users and
hence, offer an unprecedented coverage. This enhanced coverage is particularly of interest to monitor air and noise pollution.
For air quality monitoring, the mobile phones are interfaced
with external pollution sensors to measure the concentration
of e.g., carbon monoxide and ozone in the air [7]. The
measurements are timestamped and geotagged before being
uploaded to a server aggregating the readings and making them
26
TABLE I
OVERVIEW
OF THE INTEGRATED SENSORS
TelosB
Gyroscope
Accelerometer
Digital compass
Proximity/IR sensor
Light sensor
Camera
Microphone
Humidity sensor
Temperature sensor
Sun SPOT
x
x
x
x
x
x
x
x
iPhone 4
x
x
x
x
x
2x
2x
Nexus S
x
x
x
x
x
2x
2x
available to the public. Similarly, the mobile phones capture
sound samples via the embedded microphone to evaluate the
surrounding noise level and detect noise pollution,which can,
e.g., affect human health and behavior [9].
III. A DOPTION A SSETS : A T RILOGY OF FACTORS
In this section, we analyze and discuss the key factors in
favor of an adoption of mobile phones as sensing platforms.
A. Technical Factor
We compare commonly used sensor nodes, TelosB [10] and
Sun SPOT [11], to current mobile phones, iPhone 4 [12] and
Nexus S [13], based on their technological features and their
dissemination1 .
1) Embedded Sensors: Table I lists the sensors integrated
in each platform and shows that the off-the-shelf mobile
phones present a larger number of embedded sensors than
the dedicated sensing platforms. Except for the proximity
sensor, the light sensors, and the accelerometers, the sensor
modalities of the sensor nodes and the mobile phones do not
overlap. While the sensor nodes capture primitive data types,
the mobile phones collect complex data types, such as sound
samples or pictures, able to provide rich information about
their environment. Even if mobile phones are originally not
equipped with sensors required by a particular application,
such as pollution sensors, these sensors can be easily interfaced via Bluetooth. In comparison, extending the sensing
capabilities of the dedicated sensor nodes requires additional
efforts and may be limited or even impossible due to the
scarce resources of the sensor nodes. Furthermore, both mobile
phones include positioning systems (e.g., assisted GPS, digital
compass, Wi-Fi, and cellular triangulation), which enable
automatic annotation of the sensor readings with the location
of their capture without the need for external positioning
systems.
2) Processing, Storage, and Energy Resources: The mobile
phones are resourceful in terms of processing and storage.
They are equipped with powerful processors and a substantial
amount of memory, as shown in Figure 1 and 2. These
resources allow for complex processing on device, which
extends the range of possible sensing applications. Note that
the Sun SPOT can be considered as an exception, since it
1 While no actual deployment numbers where available for the dedicated
sensor nodes, the growth in smartphone sales has been impressive; in Q2/2011
more than 20 million iPhones have been sold according to Apple Inc.
RAM
16 GB
Flash (Data)
16 GB
5GB
Memory
512 MB
512 MB
GSM/CDMA
IEEE 802.11
Bluetooth
NFC
IEEE 802.15.4
50MB
8 MB
1 MB
TelosB
sunspot
iphone 4
nexuss
TABLE II
1,00E+04
1,00E+06
5,12E+08
5,12E+08
S UPPORTED
WIRELESS TECHNOLOGIES
1,00E+06
8,00E+06
1,60E+10
1,60E+10
1 MB
500 kB
TelosB
Sun SPOT
x
x
iPhone 4
x
x
x
Nexus S
x
x
x
x
10 kB
5 kB
TelosB
Sun SPOT
iPhone 4
Nexus S
Platform
Fig. 1.
Comparison of available memory (logarithmic scale)
TelosB [10]
Battery lifetime
Sun SPOT [11]
iPhone 4 [12]
Nexus S [13]
Resources
systems for TelosB platform include the TinyOS and Contiki
operating systems, while the iPhone runs the iOS operating
system. Mobile phones offer thus a similar diversity in terms of
programming languages compared to sensor nodes. Depending
on personal preferences or requirements of the applications,
the developers can therefore select Java-based or C-based
programmable devices. Note that the developer community,
in particular for mobile phone applications, is constantly
increasing and advanced integrated development environments
cater to the developers needs. As a result, the marketplaces of
iOS and Android have been seeing unparalleled growth2 , while
applications for sensor nodes are still mostly available in the
academic domain.
Fig. 2. Comparison of available resources in function of the battery lifetime
B. Human Factor
has been mainly conceived as a research platform with CPU
and memory being substantially more powerful than in other
sensor nodes. However, the computing resources come at
the cost of energy consumption. Typical standby lifetimes of
mobile phones are up to 300 hours for the iPhone 4 and up to
428 hours for the Nexus S in 3G networks, according to the
manufacturers. In comparison, the battery of sensor nodes in
an energy-aware deployment can last up to years. Nevertheless,
mobile phones are functional objects, whose primary function
is to provide telephony or Internet services and not to sense.
The users are already used to frequently recharge them and
perform updates to benefit from their primary functionalities,
thus catering for the provision of energy and basic maintenance
without further efforts. In any case, constantly active sensing
applications on mobile phones should be designed in an energy
efficient fashion to minimize the effects on battery life.
3) Wireless Technologies: Table II illustrates the variety
of the wireless technologies integrated in the surveyed sensing platforms. Both mobile phones support at least three
communication standards that are widely deployed, while
the sensor nodes only support the IEEE 802.15.4 standard,
specially tailored for their scarce resources. Even if solutions
to connect sensor nodes to the Internet have been proposed,
e.g., in [14], they still demand efforts for the developers to
be integrated in the considered deployment. Additionally, the
Bluetooth standard enables to easily extend the set of sensors
by interfacing external sensors.
4) Operating Systems and Programming Languages: Both
the Nexus S, which runs the Android operating system, and
the Sun SPOT are based on the Java programming language
extended by specific libraries. In comparison, the TelosB and
the iPhone are programmed using variants of the C programming language, NesC and Objective-C, respectively. Operating
The technical factor is usually considered as a key criterion
in the development of a new sensing applications, while the
human factor is often relegated to a second rank. This is however a determinant factor for the acceptance of the application
and thus, its overall performance. Indeed, monitored people
might turn off the sensing platform, either unconsciously by
forgetting to charge the battery, or consciously, if, e.g., they
feel their privacy intruded. In this section, we thus examine
how both dedicated sensor nodes and mobile phones impact
on the human factor and discuss their consequences on the
application performance.
1) Acceptance and Unobtrusiveness: With over 5 billion
mobile phone subscriptions worldwide [15], mobile phones
are part of our daily life and have been accepted by the
population at large. This level of acceptance provides for
an unprecedented coverage and mobility. The mobile phones
are commonly carried by their users while, e.g., commuting,
and, hence, naturally follow the flow of the population. In
comparison to static sensor nodes, this allows for additional
coverage and monitoring of unplanned events. Besides, it
opens the doors for novel application scenarios, where the
sensing process is not only focused on a unique person or her
environment, but on relationships between multiple people,
and also their relationships with their environment. People are
used to handle them, charge their batteries, and their utilization
does not demand additional comprehension efforts. On the
other side, the TelosBs and the Sun SPOTs are specialized
devices dedicated to a unique task, namely sensing. The large
public may not be familiar with them, as they are primarily
2 According to the Apple quarterly report in Q2/2011, there are more than
425,000 apps in the iOS App Store, which served more than 15 billion
downloads since its opening in July 2008.
27
deployed in research projects or small scale applications, such
as building and factory automation.
2) Interactivity, Involvement and Visibility: The possibilities offered by dedicated sensor nodes for the users to interact
with are typically insufficient. They mainly consist of, e.g.,
LEDs, switches, or analog inputs, whose usability is inappropriate for non-expert users. Elaborated sensor nodes can be extended by additional displays to increase their usability. They
however require additional design and development efforts
for the application developers and only support unidirectional
information flow, mainly from the sensor node to the users. On
the contrary, mobile phones support off-the-shelf bidirectional
interactions between both the sensors and the users. They
offer multiple usable modalities to interact with, such as touch
screens, keyboards, or vocal recognition. Users can therefore
easily control and get feedbacks from the sensing applications.
Such interaction possibilities allows for involving the users in
the sensing loop. Without even considering active participation
of the users in the sensing process (which may rapidly become
burdensome for the users), the participants can be encouraged to participate and contribute to sensing campaigns by
introducing reward programs. Besides, the online marketplaces
for apps and their exponentially growing market offer an
unprecedented visibility for sensing application sensing. Using
these services, the application developers can easily come
into contact with millions of people and democratize sensing
applications.
C. Economical Factor
Considering the retail prices, TelosB and Sun SPOT appear
to be cheaper than the mobile phones. At the time of writing,
in the German market, their current prices oscillate around 200
EUR for the TelosBs and 300 EUR for the Sun SPOTs (i.e.,
a kit of one base station and two SPOTs), while the Nexus S
and the iPhone 4 cost around 500 EUR and 600 EUR (without
any telephony/Internet subscription), respectively. However,
the deployment of sensor nodes typically requires a specific
investment due to the specialization of the platforms. In
contrast, the mobile phones can be configured to perform
additional tasks: sensing applications can exploit the already
deployed mobile phones for their campaign, thus virtually
reducing the deployment costs to zero.
IV. D ISCUSSION AND C ONCLUSIONS
In this paper, we have compared both dedicated sensor
platforms and mobile phones, according to three factors: the
technical factor, the human factor, and the economical factor.
In summary, we have shown that mobile phones feature a
larger number of embedded sensors, support more wireless
standards, excel in computing resources and have a more
active developing community, the combination of which makes
them ready for mobile sensing application support. The technological features come at the price of the higher energy
consumption, which represents one of the most important
weaknesses of the mobile phones. Despite their interesting
capabilities, they require frequent charges of their batteries,
28
limiting their autonomy and preventing long-term deployments
in hazardous or difficulty accessible zones. The analysis of the
recent mobile phones on the market shows a trend to embed
as much technologies as possible, without regards to energy
consumption. Yet, even if this trend continues, the human
centered design of mobile phones is expected to ensure that the
charging cycle is appropriate and not shorter than once in 24
hours. The role of mobile phone application developers is to
conceive energy-aware applications, algorithms or protocols,
avoiding an exhaustion of the batteries within few hours. Furthermore, the mobile phones are already deployed, accepted
by a large public, and offer interaction possibilities, which
remain impossible with dedicated sensor nodes. In conclusion,
mobile phones represent interesting sensing platforms, which
open new perspectives for sensing applications. Their adoption
is however still in its infancy and requires further research.
We believe that a closer link to the wireless sensor network
community will prove key to the success of mobile sensing
platforms.
ACKNOWLEDGMENT
This work was supported by CASED (www.cased.de).
R EFERENCES
[1] B. Warneke, M. Last, B. Liebowitz, and K. Pister, “Smart Dust:
Communicating with a Cubic-millimeter Computer,” Computer, vol. 34,
no. 1, pp. 44–51, 2001.
[2] J. Burke, D. Estrin, M. Hansen, A. Parker, N. Ramanathan, S. Reddy,
and M. Srivastava, “Participatory Sensing,” in Proceedings of the 1st
Workshop on World-Sensor-Web (WSW), 2006, pp. 1–5.
[3] A. Campbell, S. Eisenman, N. Lane, E. Miluzzo, and R. Peterson,
“People-centric Urban Sensing,” in Proceedings of the 2nd Annual
International Wireless Internet Conference (WICON), 2006, pp. 18–31.
[4] M. Hanson, H. Powell, A. Barth, K. Ringgenberg, B. Calhoun, J. Aylor,
and J. Lach, “Body Area Sensor Networks: Challenges and Opportunities,” Computer, vol. 42, no. 1, pp. 58–65, 2009.
[5] A. Wood et al., “Context-Aware Wireless Sensor Networks for AssistedLiving and Residential Monitoring,” IEEE Network, vol. 22, no. 4, pp.
26–33, 2008.
[6] H. Alemdar and C. Ersoy, “Wireless Sensor Networks for Healthcare:
A Survey,” Computer Networks, vol. 54, no. 15, pp. 2688–2710, 2010.
[7] E. Kanjo, J. Bacon, D. Roberts, and P. Landshoff, “MobSens: Making
Smart Phones Smarter,” IEEE Pervasive Computing, vol. 8, no. 4, pp.
50–57, 2009.
[8] S. Reddy, A. Parker, J. Hyman, J. Burke, D. Estrin, and M. Hansen,
“Image Browsing, Processing, and Clustering for Participatory Sensing:
Lessons from a DietSense Prototype,” in Proceedings of the 4th Workshop on Embedded Networked Sensors (EmNets), 2007, pp. 13–17.
[9] R. Rana, C. Chou, S. Kanhere, N. Bulusu, and W. Hu, “Ear-Phone: An
End-to-end Participatory Urban Noise Mapping System,” in Proceedings
of the 9th ACM/IEEE International Conference on Information Processing in Sensor Networks (IPSN), 2010, pp. 105–116.
[10] “TelosB Datasheet,” Online: http://www.memsic.com (accessed in July
2011).
[11] “Sun SPOT Main Board Technical Datasheet,” Online: http://www.
sunspotworld.com (accessed in July 2011).
[12] “iPhone 4 Technical Specifications,” Online: http://www.apple.com (accessed in July 2011).
[13] “Nexus S Tech Specs,” Online: http://www.google.com (accessed in July
2011).
[14] A. Dunkels, “Full TCP/IP for 8 Bit Architectures,” in Proceedings
of the 1st ACM/Usenix International Conference on Mobile Systems,
Applications and Services (MobiSys), 2003, pp. 85–98.
[15] GSM World, “Global GSM and 3GSM Mobile Connections,” Online: http://www.gsm.com (accessed in July 2011).
Reasons for priority-based Medium Access in
Wireless Sensor Networks
Alexander Klein and Lothar Braun
Lehrstuhl für Netzarchitekturen und Netzdienste
Technische Universität München
Abstract—The trend towards heterogeneous wireless sensor
networks and cyber-physical systems results in new challenges
for the communications protocols. The co-existence of these
networks can result in an unacceptable performance decrease if
they interfere with each other or share the same radio channel.
Especially, in the latter case, priority-based medium access
with Quality of Service (QoS) guarantees is required to assure
that the different networks can accomplish their tasks. In this
paper, we introduce different use cases and priority strategies.
Furthermore, the advantages and drawbacks of current solutions
are discussed.
transmissions of nodes with less important periodic data traffic
affect the performance of the high priority traffic. Therefore,
it is important that the MAC protocol supports priority-based
medium access to mitigate or overcome this issue of varying
traffic load and priority.
This paper is organized as follows. An introduction to
different use cases and priority strategies is given in Section II.
In Section III, the advantages and drawbacks of two different
solutions are discussed. Finally, we conclude in Section IV.
I. I NTRODUCTION
Priority-based medium access mechanisms become more
and more important in the area of Wireless Sensor Networks
(WSN) since networks do not only focus on a single application. The latest generation of WSNs usually performs various
tasks at the same time, e.g. sensing of temperature, pressure
or stress and strain. The sensor nodes either periodically
transmit the sensed data or only start to communicate as
soon as a certain threshold is exceeded. The priority of the
generated data then depends on the corresponding application,
the type of the sensed data and the sensed value. Consider a
sensor network for Structural Health Monitoring where nodes
periodically sense temperature and stress strain of critical
components.
The sensed data can be transmitted with the same priority to
a data sink as long as no threshold is exceeded. However, in the
case that a fire is detected due to high temperature increase,
the data packets containing temperature values should have
a higher priority in order to track the fire. On the other
hand, the stress and strain measurements will be of higher
importance during an earthquake to estimate the lifetime of
critical components or to initiate an alert. Some events, like a
fire, are often limited to certain area and are thus only detected
by a small number of nodes. These nodes should have a higher
medium access priority in case of an emergency to minimize
the time to initiate countermeasures. In addition, it is very
common that nodes start to sense the corresponding phenomena more frequently to provide better knowledge about the
event. This behavior results in a higher data rate which should
be taken into account by the Medium Access Control (MAC)
protocol. Event-driven data traffic [1] represents a serious issue
in dense sensor networks where nodes also transmit periodic
data traffic since the low power transceivers are very limited
in their sensing capabilities [2]. Due to the shared medium,
II. U SE C ASES AND P RIORITY S TRATEGIES
QoS requirements are defined by a WSNs’ target application. In Section I, we briefly introduced several application
examples with different QoS requirements. A more general
view on the requirements of several application scenarios
can lead to basic strategies for prioritized medium access.
We will discuss the general requirements of these classes in
Section II-A, and discuss the basic medium priority access
strategies that emerge from these requirements. Afterwards,
we present QoS strategies that can be used to implement
concrete priority access schemas for several applications in
Section II-B.
A. Medium Access Priority Classes
Priority based medium access requirements and strategies
can be divided into two groups. The first group of application
requirements can be seen in an application that requires Static
Medium Access Priority. Such static requirements can be
found in simple WSNs where many nodes are deployed that
fulfill different tasks which are assigned different priorities.
Task priorities can be assigned during node configuration before the network is deployed. One advantage of static priorities
is that the behavior of the network is highly predictable: The
node with the highest priority is able to access the medium
immediately in case of a free radio channel, or immediately
after the current transmission if the channel is busy.
The second group of applications contain all scenarios
where a priority scheme is not known at configuration time,
but depends on run time parameters. Such applications require
a Dynamic Medium Access Priority scheme to fulfill their
QoS requirements. Dynamic priority strategies are based on
changing conditions, which emerge at run time. Such conditions can be the battery energy level, the waiting queue length,
data rate, buffer level, and distance to the root or number of
29
neighbors. Dynamic medium access typically results in a more
complex network behavior. Estimating parameters for minimum, maximum, or average latencies or other performance
parameters requires a detailed understanding of the encoded
priority metric. Basically, dynamic access strategies can be
used for two purposes: They can be employed to balance the
network load equally on all available nodes, or shift it to nodes
which are capable of handling higher loads. Or they can be
used to guarantee fair medium access. Metrics which consider
the traffic load and buffer level of nodes are of particular
interest in WSNs since nodes are very limited in terms of
energy and memory.
B. QoS Strategies
Several strategies can be used to implement the previously introduced dynamic and static access priority classes.
Unreliable links and varying channel conditions over time
present challenges [3] that are not considered by traditional
QoS-support mechanism like IntServ [4] and DiffServ [5].
Therefore, such traditional schemes can hardly be applied
in the context of WSNs. This is especially true since WSN
nodes have severe resource constraints such as limitations of
computational power, memory and bandwidth. Due to these
additional constraints impact the requirements for the strategies: They should be as simple as possible while meeting the
QoS requirements of the target application. In the following,
we introduce different strategies for priority-based medium
access that can significantly improve the network performance.
One, or several, of these strategies must be chosen before
a WSN is deployed by a WSN administrator. We therefore
discuss the pre-requisites for each strategy and highlight
possible application scenarios which can benefit from these
strategies.
1) Topology-aware access strategy: Some WSNs consist
of several types of nodes: few powerful nodes with little
constraints form a backbone. A lot smaller and constraint
devices are grouped around these backbone nodes, competing
for media access with these non-constrained devices. If a
high priority is assigned to the backbone nodes, the medium
access delay for these nodes is reduced. Hence, the delivery
ratio is increased since the number of nodes with high access
priority is very small. Furthermore, such a strategy gives the
backbone nodes control of the medium access which improves
the support for data aggregation mechanisms.
2) Network-aware access strategy: The self-organizing capability of WSNs have made the technology an attractive
solution for several monitoring tasks: nodes can be randomly
placed in a field or in areas which are or become hardly
accessible, e.g. due to radioactive contamination. This however
can come with a drawback: some scenarios do not allow for
the replacement or removal of network nodes. For example,
asymmetric links or partitioning of the network can make reprogramming or remote shut down of the nodes impossible. If
a new network should be deployed on top of another network,
or an existing network should be upgrade, this can become
a problem due to the shared characteristic of the medium.
30
This can limit the performance of later deployed networks
which operate on the same radio channel, especially if nodes
frequently transmit data until their batteries are drained. A
priority-based medium access strategy which employs network
IDs can mitigate the problem of co-existing networks. Network
IDs can be used to represent the medium access priority of the
WSNs: a higher ID corresponds to a higher access priority
and vice versa. One the one hand, this strategy allows the
deployment of a new high priority WSNs on top of an already
deployed sensor network, which could not be removed or
shut down. On the other hand, a new low priority WSN can
be placed within the area of another sensor network without
having a large impact on the performance of the already
deployed network.
3) Traffic-aware access strategy: More and more sensor
networks perform different tasks at the same time. Trafficawareness within the MAC protocol is required if the tasks
have different priorities. Assume a WSN in which nodes
generate traffic with different priorities, e.g. the stress and
strain measurements of a structural health monitoring application, which has high QoS requirements, and temperature
measurements which can be transmitted as best effort traffic.
An operator may therefore assign different traffic priorities
for these two application types, thus improving performance
metrics for the high-priority application traffic.
4) Service-aware access strategy: Virtualization of networks and services has become very popular in recent years,
with the first implementations already available [6]. These
techniques allow several users to access nodes and their
sensors in a shared manner. Resource allocation for each user
on the device has been the focus of extensive research. To the
best of our knowledge, medium access priorities in conjunction
with virtualization has not been an issue. Assigning priority
classes for medium access for virtualized applications, allows
fair media sharing between the virtualized applications.
5) Distance-aware access strategy: Measured data is typically transmitted from a large number of data sources to a
small number of data sinks. This sinks can process or forward
the data into a non-constrained environment. Such networks
are often organized in a tree structure [7], which allows
taking advantage from data aggregation and data processing
mechanisms. Medium access in such a setup can be a major
performance factor due to the increasing traffic load towards
the sinks. A priority-based medium access procedure that
adopts the access priority depending on the distance to the
sink can support the data aggregation mechanisms or decrease
the energy consumption of the sensing nodes. If nodes that
are closer to the sink have a higher priority, the delay in
event-based WSNs can be reduced since the node which is
triggered by the event and is closest to the sink has the
highest priority. Thus, it can immediately access the medium
to transmit its data, which reduces the event detection time.
On the other hand, assigning a higher priority to nodes that
are further away can reduce the overall energy consumption:
Nodes that are furthest away from the sink can transmit their
data immediately and turn off their transceiver at the end of
the transmission. Furthermore, it improves the potential of data
aggregation due to the fact that all children of a node in the tree
have a higher medium access priority than their parent. As a
result, the children can transmit their data to the parent before
the parent gains access to the medium in order to forward the
data.
6) Energy-aware access strategy: Most wireless sensor
nodes have very limited power supplies. Therefore, designers
of communication protocols try to minimize the energy consumption as much as possible while meeting the requirements
of the target application. Routing protocols, which take energy
consumption into account, typically try not to forward traffic
via nodes that have only a small amount of energy left. Such
mechanisms have proven to balance the traffic load and to
prolong the lifetime of WSNs. However, the access to the
medium can become costly as well in terms of energy if a node
requires several attempts to gain its access. For this reason,
nodes which run low on power should have a high medium
access priority in order to reduce the average number of access
attempts.
7) Buffer-aware access strategy: Limited amount of memory of wireless sensor nodes becomes a serious problem if
the nodes should be able to support the Internet Protocol (IP).
Especially, fragmentation of data packets and forwarding of
packets leads to high memory consumption. It has to be kept
in mind that most sensor nodes, e.g. TelosB, T-Mote and Mica,
only have 8KB or 10KB of ram which makes buffering of
multiple large packets almost impossible. Furthermore, eventdriven traffic patterns in WSNs can lead to temporary high
network load. Routing protocols with load-balancing support
have been designed to mitigate the impact of this issue in
multi-hop networks. However, a buffer-aware MAC protocol
can further improve the performance by taking the length of
the waiting queue into account: Nodes that have more packets
stored in their waiting queue should have a higher medium
access priority. As a consequence, the maximum waiting queue
length and the percentage of dropped packets due to buffer
overflows could be decreased. This strategy also improves the
fairness in dense single hop networks provided that the nodes
generate traffic at the same data rate.
8) Data-rate aware strategy: The latest generation of routing protocols for WSNs, e.g. the Collection Tree Protocol
(CTP) [7], apply adaptive mechanisms to cope with frequent
topology changes. In general, these protocols increase their
beacon transmission rate if they detect changes in their neighborhood. Topology changes usually result from interference or
mobility of the nodes. The latter may lead to frequent topology
changes which significantly increase the routing overhead.
In dense networks, the routing overhead can even result in
temporary congestion of the network. Temporary congestion
can also be caused by applications which generate event-driven
traffic, e.g. intruder detection or structural health monitoring
applications. For these kinds of applications, it is important
to receive information from all nodes which have detected the
event to gain more precise information and to minimize false
positives. The priority of the medium access should depend
on the transmission rate of the nodes. A fair medium access
can be achieved if a higher transmission rate results in a
lower access priority and vice versa. Thus, nodes which rarely
transmit traffic have a high probability of gaining access to the
medium immediately. However, nodes that frequently transmit
traffic can utilize the whole bandwidth as long as no other
nodes need access to the medium.
III. S OLUTIONS
The range of applications for WSNs steadily increases and
so does the demand for flexible and adaptive communication
protocols [8] which suit the requirements of the target application. Current solutions mainly focus on Time Division
Multiple Access (TDMA) based protocols since they provide
a good performance in scenarios where the topology is stable
and traffic patterns are known in advance. However, even in
these cases TDMA based solutions have a high complexity and
suffer from limited hardware resources such as computational
power and precise oscillators. Thus, additional synchronization
mechanisms are required to compensate the clock drift. As a
result, large gaps between consecutive slots should be applied
to avoid collisions due to asynchronous time clocks. The
impact that gaps have on the overall throughput depends on
the duration of the time slots and the duration of the gaps.
Nonetheless, the gaps can only be shortened to some extend
even if perfect synchronization is assumed since low power
transceivers require a significant period of time to switch
between receive and transmit mode and vice versa. Otherwise,
a node cannot listen to its subsequent slot if it has transmitted
in its own time slot. In addition, a node cannot use the full
duration of its own time slot if it was listening to the previous
time slot.
Due to these drawbacks of TDMA based protocols, we
decided to follow a different approach based on the transmission of preambles [10], [11] which is less complex. The
protocol uses the preamble to resolve the contention on the
one hand and provide priority based medium access [12] on
the other hand. The basic idea of the protocol is to transmit
a preamble of variable length to indicate that access to the
medium is desired. After the transmission of the preamble,
the node switches its transceiver back to receive mode and
senses the medium. If it senses a busy medium after the
transmission of its preamble, it assumes that another node
has sent a longer preamble and therefore has a higher access
priority. Thus, only the node with longest preamble senses
an idle medium and starts its data transmission. A collision
can only occur if two or more nodes start their preamble
transmission at the same time and choose the same preamble
length. A detailed description of the collision probability of
the BPS-MAC protocol with different configuration is given
in [11]. Instead of using a single preamble, the protocol can
be configured such that is uses multiple sequential preambles.
In this case, the first preamble corresponds to the access
priority whereas the subsequent preambles are used to resolve
possible contention. This approach is very flexible and does
not require additional mechanisms, e.g. synchronization or
31
complex algorithms for slot allocation. However, the preamble
transmission reduces the maximum throughput. In addition,
the transmission of preambles increases the interference which
has to be taken into account. Therefore, the protocol should
be configured with respect to the maximum expected traffic
load.
IV. C ONCLUSION
Priority-based medium access represents an interesting field
of research since the latest trends in WSNs show that there
is clear demand on this functionality. The mechanisms make
sensor networks more flexible such that they can respond more
quickly to events or to fulfil different sensing tasks at the
same time. Existing TDMA based solution already provide
this functionality to some extent. However, they achieve this
functionality by the price of high complexity. In addition,
they are less flexible due to the fact that the slot duration
cannot be changed dynamically to meet the requirements of
the target application. Preamble-based solutions for prioritybased medium access represent a new fresh approach which is
more flexible compared to their TDMA based counterparts. In
our future work, we will focus on the performance comparison
preamble-based and TDMA-based solutions for multi-hop
WSNs with QoS requirements.
R EFERENCES
[1] Y.C. Tay, K. Jamieson, and H. Balakrishnan, Collision-minimizing CSMA
and its Applications to Wireless Sensor Networks, IEEE Journal on
Selected Areas in Communications, 22(6):1048-1057, August 2004.
[2] M. Bertocco, G. Gamba, and A. Sona, Experimental Optimization of
CCA Thresholds in Wireles Sensor Networks in Presence of Interference,
In Proc. of IEEE EMC Europe 2007 Workshop on Electromagnetic
Compatibility, June 2007.
[3] A. Muneb, U. Saif, A. Dunkels, T. Voigt, K. Römer, K. Langendoen,
J. Polastre, and Z.A. Uzmi, Medium Access Control Issues in Sensor
Networks, SIGCOMM Comput. Commun. Rev., 36(2):33-36, 2006.
[4] R. Braden, D. Clark, S. Shenker, Integrated Srvices in the Internet
Architecture - An Overview, IETF RFC 1663, June 1994.
[5] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, An
Architecture for Differentiated Services, IETF RFC 2475, December 1998.
[6] B.C. Donovan, D.J. Mclaughlin, M. Zink, J. Kurose, Western Massachusetts Off-the-Grid Radar Technology Testbed, Proc. IEEE Int. Geoscience and Remote Sensing Symp. IGARSS 2008, Vol.5, 2008.
[7] O. Gnawali, R. Fonseca, K. Jamieson, D. Moss, P. Levis, Collection
Tree Protocol, SenSys ’09: Proceedings of the 7th ACM Conference on
Embedded Networked Sensor Systems, ACM, pages 1-14, 2009.
[8] M.A. Yigitel, O.D. Incel, C. Ersoy, QoS-aware MAC Protocols for
Wireless Sensor Networks: A Survey, Comput. Netw., Elsevier NorthHolland, Inc., Vol.55, pages 1982-2004, 2011.
[9] D. Chen, P.K. Varshney, QoS Support in Wireless Sensor Networks: A
Survey, In Proc. of the International Conference on Wireless Networks
(ICWN), USA, June 2004.
[10] A. Klein, J. Klaue, and J. Schalk, BP-MAC: A high Reliable Backoff
Preamble MAC Protocol for Wireless Sensor Networks, Electronic Journal
of Structural Engineering(EJSE): Special Issue of Sensor Networks for
Building Monitoring: From Theory to Real Application, -:35-45, December 2009.
[11] A. Klein, Performance Issues of MAC and Routing Protocols in Wireless Sensor Networks, PhD thesis, University of Wuerzburg, Germany,
December 2010.
[12] A. Klein and L. Braun, A Preamble-based Approach for Providing
Quality of Service Support in Wireless Sensor Networks, 4th International
Workshop on Multiple Access Communications (MACOM), Trento, Italy,
September 2011.
32
QoS-Routing und Reservierungen in mobilen
Ad-Hoc-Netzwerken
Anuschka Igel
Reinhard Gotzhein
Computer Science Department
University of Kaiserslautern
D-67653 Kaiserslautern, Germany
Email: {igel,gotzhein}@cs.uni-kl.de
Heutige Sensornetze sind oft nicht mehr statisch aufgebaut,
sondern haben die Charakteristiken eines drahtlosen mobilen
Ad-Hoc-Netzes. Da sie zudem immer komplexer werden und
die Anforderungen an die Kommunikation immer vielfältiger,
ist eine Best-Effort-Übertragung für viele Anwendungen nicht
mehr ausreichend, sondern es muss eine bestimmte Dienstgüte
gewährt werden. Dabei muss garantiert werden, dass der erforderliche Service in einer bestimmten Qualität erbracht wird,
d. h. es werden Verkehrsverträge zwischen Diensterbringer und
Dienstnutzer geschlossen. Beispiele für solche Anwendungen
sind die regelmäßige Übertragung von Sensorwerten oder von
Audio- und Videodaten. In einem Drahtlosmedium sind deterministische Garantien jedoch nur mit zusätzlichen Annahmen
möglich, beispielsweise der „Single Network Assumption“.1
Um Verkehrsverträge schließen zu können, müssen die QoSAnforderungen des Dienstnutzers hinreichend detailliert spezifiziert werden. Dazu werden Metriken verwendet, welche es
ermöglichen, verschiedene Routen zwischen Diensterbringer
(Quelle) und Dienstnutzer (Ziel) miteinander zu vergleichen.
1 Alle
Knoten sind verbunden und es gibt keine weiteren Knoten in
Interferenzreichweite, die im selben Frequenzbereich arbeiten und ein anderes
MAC-Protokoll verwenden.
Solche Metriken können additiv, multiplikativ oder konkav
sein. Am häufigsten wird die konkave Metrik Bandbreite verwendet, weshalb sich viele QoS-Routing-Protokolle auch auf
diese beschränken. Weitere Metriken sind Übertragungsverzögerung, Hopanzahl (beides additiv) oder Verlustwahrscheinlichkeit (multiplikativ). Außerdem gibt es noch die abstrakte
Metrik Kosten, die beliebig definiert werden kann.
I. Q O S-F UNKTIONALITÄTEN
Abb. 1 gibt einen grafischen Überblick über die QoSFunktionalitäten, die zur Erfüllung von QoS-Anforderungen
benötigt werden. Eine detailliertere Beschreibung ist in [1]
zu finden. Der äußere Ring stellt die Funktionalitäten dar,
der innere deren Ausprägungen. Zur QoS-Bereitstellung gehören Maßnahmen zur Umsetzung von QoS-Anforderungen
in eine geeignete Ressourcensituation (Reservierungsaspekt).
Dazu zählt beispielsweise das QoS-Mapping, d. h. die Abbildung von QoS-Anforderungen zwischen den Systemschichten
sowie die Zugangskontrolle, die sicherstellt, dass genügend
Ressourcen zur Verfügung stehen, und diese verwaltet. Die
QoS-Kontrolle umfasst kurzfristige, das QoS-Management dagegen langfristige Maßnahmen, um die vereinbarte Dienstgüte
einzuhalten (Benutzungsaspekt). Zur QoS-Kontrolle gehören
die Verkehrskontrolle, welche dafür sorgt, dass der Verkehrsvertrag eingehalten wird (z. B. Verwerfen von Paketen, wenn
eine Anwendung sich nicht an den Verkehrsvertrag hält),
sowie die Bedienstrategie, welche dafür verantwortlich ist,
QoS
-B
Im Vergleich zu drahtgebundenen Netzen stellen drahtlose
mobile Ad-Hoc-Netzwerke neue Herausforderungen dar. Ein
generelles Problem bei drahtloser Kommunikation besteht
darin, dass äußere Störeinflüsse oft zu Paketverlusten und
damit zu einer Reduktion der Bandbreite sowie Schwankungen
der Reichweite eines Transceivers führen, was unvorhergesehene Effekte haben kann. Im Gegensatz zu kabelgebundenen
Netzen ist es meist nicht möglich, ein drahtloses Netzwerk
gegen solche Einflüsse abzuschirmen, zu denen beispielsweise
Überlagerungen von Signalen, Hintergrundrauschen, plötzlich
auftretende Hindernisse oder ungünstige Wetterbedingungen
zählen.
Ein mobiles Ad-Hoc-Netz ist dadurch gekennzeichnet,
dass es keine zentrale Infrastruktur gibt und sich die Knoten
selbstständig untereinander vernetzen. Diese können ihre
Position über die Zeit verändern, was dazu führen kann, dass
laufende Übertragungen unterbrochen werden und Routen
nicht mehr verfügbar sind. Außerdem werden die Knoten
aufgrund ihrer Mobilität meistens mit Batterien betrieben, was
es erforderlich macht, den Energieverbrauch zu begrenzen.
QoS-Ko
ntro
ung
lle
l
l
e
t
QoSs
Verkehrseit
r
Routing kontrolle
e
QoSBedienMapping
strategie
ZugangsQoS-Anforderungen
QoSkontrolle
Monitoring
ReservierungsQoSprotokoll QoSMaintenance
Skalierung
QoS-Management
Abbildung 1. QoS-Funktionalitäten zur Umsetzung von QoS-Anforderungen.
33
die Aufträge vor Abarbeitung durch eine Bedienstation (z. B.
Transceiver) zu priorisieren. Zum QoS-Management gehören
QoS-Monitoring, d. h. die Erfassung und Kontrolle des aktuellen Netzzustands, QoS-Maintenance, d. h. das Ausführen
von Tuningmaßnahmen auf der Basis des Netzzustands, sowie
QoS-Skalierung, d. h. die Manipulation von Paketfolgen zur
Anpassung an verschiedene Endgeräte und die Anpassung des
Senders an eine schwankende Dienstgüte des Empfängers.
Im Folgenden werden das QoS-Routing und das Reservierungsprotokoll (beides Bestandteile der QoS-Bereitstellung)
näher betrachtet.
A. QoS-Routing
Das QoS-Routing ist Bestandteil der QoS-Bereitstellung.
Da in Multi-Hop-Netzen nicht alle Knoten direkt miteinander
kommunizieren können, muss für eine Übertragung mit Hilfe
eines Routing-Protokolls ein geeigneter Kommunikationspfad
gesucht werden. Herkömmliches Best-Effort-Routing berücksichtigt keine Restriktionen bei der Routensuche. Beim QoSRouting dagegen wird versucht, eine Route zu finden, welche
eine oder mehrere QoS-Anforderungen erfüllt (beispielsweise
eine Mindestbandbreite oder eine maximale Übertragungsverzögerung).
Die meisten existierenden QoS-Routing-Protokolle haben
zwei Kernprobleme. Das erste Problem besteht darin, dass
sich mehrere Routenanforderungen gleichzeitig in Bearbeitung
befinden können. Bei der Suche nach QoS-Routen müssen die
benötigten Netzwerkressourcen bereits vorreserviert werden.
Anderenfalls könnte es sein, dass diese nicht mehr zur Verfügung stehen, wenn die eigentliche Übertragung beginnt. Dies
kann jedoch dazu führen, dass sich die Routenanforderungen
gegenseitig blockieren, obwohl insgesamt für mindestens eine davon eine Route existiert, welche die QoS-Anforderung
erfüllt.
Das zweite Problem besteht darin, dass Routingpakete aufgrund von Rahmenkollisionen verlorengehen können. Reaktive
Routingprotokolle fluten Routenanforderungen üblicherweise
durch das ganze Netzwerk, was zu lokalen Broadcasts der
einzelnen Knoten führt. Diese werden normalerweise mit
wettbewerbsbasiertem Mediumzugriff versendet, so dass eine
erhöhte Anzahl an Kollisionen auftritt. Wegen der Broadcasts
können keine Acknowledgements verwendet werden, so dass
Pakete unbemerkt verlorengehen können. Auf diese Weise
können Routensuchen scheitern, obwohl entsprechende QoSRouten existieren.
Neben diesen beiden Kernproblemen existieren noch weitere Probleme für QoS-Routing. So ist beispielsweise die
Kombination mehrerer QoS-Anforderungen schwierig zu realisieren, da die Suche nach einer QoS-Route, welche zwei
unabhängige Anforderungen erfüllt, NP-vollständig ist [2].
Ein weiteres Problem besteht darin, dass die Erfüllung von
QoS-Anforderungen häufig nicht lokal entscheidbar ist, da die
Metrikwerte der einzelnen Knoten nicht unabhängig voneinander sind. Wird beispielsweise eine maximale Übertragungsverzögerung gefordert, so entscheidet die Summe der Werte
der einzelnen Knoten darüber, ob die gefundene Route die
34
Anforderung erfüllt. Dies führt dazu, dass weitere Nachrichten ausgetauscht oder die benötigten Informationen mit in
die Routing-Pakete aufgenommen werden müssen. Allenfalls
für konkave Metriken ist eine lokale Entscheidung möglich,
beispielsweise wenn man die statistische Reservierung von
Bandbreite betrachtet (siehe Abschnitt I-B). Doch auch für
solche Metriken werden häufig Werte der benachbarten Knoten
benötigt, beispielsweise wenn eine deterministische Reservierung von Bandbreite in Form von Zeitslots vorgenommen
werden soll, da ein Zeitslot nicht verwendet werden kann,
wenn dieser bereits von einem Nachbarknoten verwendet wird.
B. Reservierungsprotokoll
Das Reservierungsprotokoll ist wie das QoS-Routing Bestandteil der QoS-Bereitstellung. Seine Aufgabe ist die Koordinierung der verteilten Reservierung von Ressourcen, um
die kollisionsfreie Übertragung von Daten sicherzustellen. Es
kann eigenständig sein oder in das QoS-Routing-Protokoll
integriert.
Wir betrachten hier zwei Möglichkeiten zu reservieren:
statistisch und deterministisch. Statistische Reservierungen
sind nicht exklusiv; man hat keine Garantie, dass die QoSAnforderungen tatsächlich eingehalten werden. Diese Reservierungen werden im Mittel funktionieren, solange das Netz
nicht zu stark ausgelastet ist. Die verwendete MAC-Schicht ist
nicht festgelegt, d. h. es kann CSMA oder TDMA verwendet
werden. Im Beispiel von Bandbreite als QoS-Anforderung
wird die freie Bandbreite eines Knotens als abstrakter Zahlenwert verwaltet und eine neue QoS-Route durch diesen nur
zugelassen, solange noch Bandbreite zur Verfügung steht.
Im Gegensatz dazu sind deterministische Reservierungen
exklusiv, d. h. es ist – unter bestimmten Annahmen – garantiert, dass die QoS-Anforderungen eingehalten werden.
Aufgrund der Charakteristiken von drahtlosen Netzen (z. B.
Störanfälligkeit, Knotenmobilität) ist es ohne solche Annahmen nicht möglich, harte QoS-Garantien zu geben. Im Beispiel
von Bandbreite werden konkrete Zeitslots reserviert, in denen
kollisionsfreie Übertragungen stattfinden können.
Als Voraussetzung für deterministische Reservierungen werden einige Basisfunktionalitäten benötigt. So ist es i. d. R.
nicht möglich, eine wettbewerbsbasierte Mediumarbitrierung
(z. B. CSMA/CA) zu verwenden. Da auch die Verwendung von
FDMA (Frequency Division Multiple Access) aufgrund der
hohen Hardwareanforderungen oft nicht sinnvoll ist, kommt
vor allem TDMA (Time Division Multiple Access) als Arbitrierungsverfahren auf MAC-Ebene in Frage. Bei diesem
wird die Zeit in Slots eingeteilt, welche dann von den einzelnen Knoten exklusiv für Übertragungen reserviert werden
können. TDMA setzt jedoch eine globale Zeitsynchronisation
mit maximalen Uhrenabweichungen voraus, da Kollisionen
auftreten können, wenn das Zeitverständnis der einzelnen
Knoten zu stark divergiert. Es könnte dann der Fall eintreten,
dass Übertragungen in benachbarten Slots kollidieren, obwohl
jeder Knoten in seinem reservierten Slot sendet. Ein geeignetes
Verfahren mit beschränkter Konvergenzzeit ist BBS [3].
Zusätzlich zu TDMA wird in der Regel SDMA (Spatial
Division Multiple Access) verwendet, d. h. Zeitslots werden
mehrfach genutzt, sofern die entsprechenden Knoten sich nicht
in Reichweite befinden. Hierbei sind das Hidden-Station- und
das Exposed-Node-Problem zu beachten. Die Verwendung von
CDMA (Code Division Multiple Access) zusätzlich zu TDMA
zur Vermeidung des Hidden-Station-Problems wurde in [4]
(Bandwidth Routing) thematisiert. Dabei werden unterschiedliche Codierungen für Datenübertragungen verwendet, die sich
sonst gegenseitig stören würden. Hierfür werden jedoch verschiedene Codierungen sowie ein entsprechender Algorithmus
zu deren Verteilung benötigt, was die Realisierung aufwendig
macht.
Um TDMA und SDMA zu realisieren, wird ein Modell des
Netzwerks benötigt, wobei nicht jeder Knoten die gesamte
Topologie kennen muss, aber zumindest Informationen über
seine Nachbarn und ggf. über weitere Knoten erhalten muss,
um entscheiden zu können, ob ein Slot reserviert werden kann.
Dabei ist auch zu beachten, dass zwischen Kommunikations-,
Interferenz- und Wahrnehmungstopologie unterschieden werden muss. Zwei Knoten sind in der Kommunikationstopologie
benachbart, wenn ein Knoten einen gesendeten Rahmen des
anderen Knotens korrekt empfangen kann. Sie sind in der
Interferenztopologie benachbart, wenn die Interferenz eines
der Knoten Auswirkungen auf den anderen haben kann und
in der Wahrnehmungstopologie benachbart, wenn ein Knoten
einen Sendevorgang des anderen per CCA erkennen kann. In
der Regel ist die Wahrnehmungsreichweite größer als die Interferenzreichweite und diese größer als die Kommunikationsreichweite. Da die Erreichbarkeit zwischen zwei Knoten von
verschiedenen Umweltbedingungen abhängt (z. B. Hindernisse, Überlagerung mit anderen Signalen, Hintergrundrauschen),
kann es auch vorkommen, dass ein Knoten nur einen Teil der
Pakete eines anderen Knotens empfängt. Die Erreichbarkeit
ist also kein binärer Wert. Weiterhin ist zu beachten, dass
sich die Erreichbarkeit aufgrund der Mobilität der Knoten
ändern kann, wodurch beispielsweise Routen brechen oder
neue Interferenzen entstehen können.
Viele vorhandene Reservierungsprotokolle berücksichtigen
zwar, dass die Sendevorgänge verschiedener Knoten sich gegenseitig beeinflussen; jedoch wird oft vernachlässigt, dass die
Interferenzreichweite größer ist als die Kommunikationsreichweite. Wechselwirkungen zwischen zwei Knoten werden nur
dann betrachtet, wenn diese direkt miteinander kommunizieren können (siehe z. B. [4]–[7]). Dies ist problematisch, da
Reservierungen in der Regel „konservativ“ getroffen werden
sollen, d. h. wenn ein Slot für eine Kommunikation reserviert
wird, soll garantiert sein, dass diese nicht durch andere Kommunikationen im selben Slot gestört wird.
Ein weiteres Problem, welches ein Reservierungsprotokoll
lösen muss, ist die Verteilung der zu reservierenden Zeitslots in
den einzelnen Knoten. Es muss nicht nur eine Route gefunden
werden, die die QoS-Anforderung(en) erfüllt, sondern auch
ermittelt werden, welche der freien Zeitslots jeweils reserviert
werden sollen, um an den nächsten Knoten der entsprechenden
Route zu senden. Ziel ist es, die vorhandene Bandbreite
Abbildung 2.
Beispiel für das SSSR- und das SSNR-Problem [7].
möglichst gut auszunutzen. In [5] wurde gezeigt, dass dieses
Problem NP-vollständig ist, weshalb in der Praxis Heuristiken zum Einsatz kommen. Es wird ebenfalls erwähnt, dass
bereits für eine gegebene Route die Bestimmung der maximal
verfügbaren Bandbreite ein NP-vollständiges Problem ist.
Dies führt zu zwei weiteren Problemen, welche in [7]
beschrieben werden, nämlich das Slot Shortage for Self Route
(SSSR) und das Slot Shortage for Neighboring Routes (SSNR)
Problem. Das SSSR-Problem besteht darin, dass für eine Route, welche eigentlich die QoS-Anforderung erfüllt, keine passende Slotverteilung gefunden werden kann, weil am Anfang
der Route die „falschen“ Slots gewählt wurden. Das SSNRProblem besteht darin, dass für eine Route keine passende
Slotverteilung gefunden werden kann, obwohl dies möglich
wäre, wenn für eine andere Route die Slotwahl modifiziert
würde (siehe auch das erste Kernproblem in Abschnitt I-A).
Die beiden Probleme werden durch die folgenden Beispiele
verdeutlicht, welche aus [7] entnommen wurden.
In dem Netzwerk aus Abb. 2 sind nicht verfügbare Slots
schwarz markiert. Für das SSSR-Problem betrachten wir die
Route P : S → B → E → G → D mit einer QoSAnforderung von zwei Slots. Wenn S die Slots {1, 2} zum
Senden an B verwendet und B die Slots {3, 4} zum Senden
an E, so können wegen des Hidden-Station-Problems die Slots
{1, 2} von E nicht zum Senden an G verwendet werden. Damit bleibt nur noch Slot {5} übrig, d. h. die QoS-Anforderung
kann nicht erfüllt werden. Würde S jedoch die Slots {5, 6}
und B die Slots {7, 8} verwenden, so könnte E die Slots
{1, 2} und G die Slots {3, 4} verwenden, womit die QoSAnforderung erfüllt ist.
Für das SSNR-Problem betrachten wir dieselbe QoS-Route
P mit den Sendeslots {5, 6}, {7, 8}, {1, 2} und {3, 4} für die
Knoten S, B, E und G. Wir betrachten nun eine Nachbarroute
P ′ : F → C, welche ebenfalls eine QoS-Anforderung von
zwei Slots hat. Da F zu E, G und D benachbart ist, können
die Slots {7, 8}, {1, 2} und {3, 4} von F nicht zum Senden
verwendet werden. Somit bleiben nicht mehr genug Slots
übrig, um die QoS-Anforderung zu erfüllen. Werden für P
jedoch die Slots {7, 8}, {5, 6}, {3, 4} und {1, 2} verwendet,
so kann {7, 8} für P ′ verwendet werden, und beide QoSAnforderungen können erfüllt werden.
Abschließend sei noch angemerkt, dass Reservierungen
auch im Hinblick auf die Einsparung von Energie Vorteile
bringen können. Beim Duty Cycling wird die Zeit in peri-
35
odische Aktiv- und Schlafphasen eingeteilt, wobei ein Knoten
nur während seiner Aktivphasen an Übertragungen teilnimmt.
Im Gegensatz zu einem CSMA-Verfahren wissen die Knoten
bei Verwendung von TDMA und Reservierungen jeweils, in
welchen Slots sie senden bzw. empfangen, und müssen nur in
diesen wach sein. Duty Cycling auf der Basis einer TDMAMAC-Schicht wird in [8] thematisiert.
II. Z USAMMENFASSUNG
In diesem Beitrag wurden mehrere Probleme bei der Umsetzung von QoS-Anforderungen in mobilen Ad-Hoc-Netzen
dargestellt. Dabei wurden das QoS-Routing sowie das Reservierungsprotokoll näher beleuchtet, und es wurde gezeigt, dass
die auftretenden Probleme von existierenden Protokollen nur
teilweise berücksichtigt werden. Für QoS-Routing-Protokolle
lassen sich zwei Kernprobleme identifizieren, nämlich die gegenseitige Blockierung konkurrierender Routenanforderungen
sowie Kollisionen von Routing-Paketen.
Für Reservierungsprotokolle muss einerseits berücksichtigt
werden, dass Reservierungen sowohl statistisch als auch deterministisch getroffen werden können, wobei statistische Reservierungen keine Kollisionsfreiheit garantieren. Deterministische Reservierungen tun dies, haben jedoch eine Reihe weiterer Anforderungen, beispielsweise eine TDMA-MAC-Schicht
und eine globale Zeitsynchronisation. Auch das HiddenStation- und das Exposed-Node-Problem müssen beim Design
deterministischer Reservierungsprotokolle beachtet werden.
Vorhandene Protokolle vernachlässigen ferner die Tatsache,
36
dass Interferenzen eines Knotens sich auch auf Knoten auswirken können, die sich nicht in Kommunikationsreichweite
zu diesem befinden.
L ITERATUR
[1] A. Campbell, C. Aurrecoechea, and L. Hauw, “A Review of QoS
Architectures,” Multimedia Systems, vol. 6, pp. 138–151, 1996.
[2] S. Chen and K. Nahrstedt, “An Overview of Quality-of-Service Routing
for the Next Generation High-Speed Networks: Problems and Solutions,”
IEEE Network Magazine, Special Issue von Transmission and Distribution
of Digital Video, 1998.
[3] R. Gotzhein and T. Kuhn, “Decentralized Tick Synchronization for MultiHop Medium Slotting in Wireless Ad Hoc Networks Using Black Bursts,”
in 5th Annual IEEE Communications Society Conference on Sensor, Mesh
and Ad Hoc Communications and Networks. SECON’08, San Francisco.
IEEE, June 2008, pp. 422–431.
[4] C. R. Lin and J.-S. Liu, “QoS Routing in Ad Hoc Wireless Networks,”
IEEE Journal on Selected Areas in Communications, vol. 17, no. 8, pp.
1426–1438, August 1999.
[5] C. Zhu and M. S. Corson, “QoS Routing for Mobile Ad Hoc Networks,”
in INFOCOM 2002. Twenty-First Annual Joint Conference of the IEEE
Computer and Communications Societies. Proceedings. IEEE, vol. 2.
IEEE, 2002, pp. 958–967.
[6] W.-H. Liao, Y.-C. Tseng, and K.-P. Shih, “A TDMA-based Bandwidth
Reservation Protocol for QoS Routing in a Wireless Mobile Ad Hoc
Network,” in Proceedings of IEEE ICC, April–May 2002.
[7] K.-P. Shih, C.-Y. Chang, Y.-D. Chen, and T.-H. Chuang, “Dynamic
bandwidth allocation for QoS routing on TDMA-based mobile ad hoc
networks,” Computer Communications, vol. 29, no. 9, pp. 1316–1329,
2006.
[8] D. Christmann, R. Gotzhein, M. Krämer, and M. Winkler, “Flexible and
energy-efficient duty cycling in wireless networks with MacZ,” in Proc.
10th Annual Int New Technologies of Distributed Systems (NOTERE)
Conf, K. Drira, A. H. Kacem, and M. Jmaiel, Eds. IEEE, 2010, pp.
121–128.
Kommunikationsanforderungen in zukünftigen
Ad-Hoc-Netzwerken
Dennis Christmann
Reinhard Gotzhein
Fachbereich Informatik, AG Vernetzte Systeme
Technische Universität Kaiserslautern
D-67653 Kaiserslautern, Deutschland
Email: {christma,gotzhein}@cs.uni-kl.de
I. A NFORDERUNGEN UND L ÖSUNGSKONZEPTE
Abbildung 1 gibt einen grafischen Überblick über die Anforderungen und Lösungskonzepte eines Ad-Hoc-Netzes, die im
Folgenden näher erläutert werden. Der äußere Ring zeigt die
Anforderungen und der innere Ring die jeweiligen Lösungen.
Die Zeitsynchronisation ist als zentrale Anforderung im Mittelpunkt der Grafik dargestellt.
A. Dienstgüte
In vielen Szenarien reicht eine best effort Dienstgüte
(Quality-of-Service, QoS) schon lange nicht mehr aus.
Stattdessen werden verbindlichere Zusicherungen von
Übertragungsraten
oder
Ende-zu-Ende-Verzögerungen
benötigt. Obwohl deterministische Garantien und die
Erfüllung harter Echtzeitanforderungen aufgrund der
reduzierten Kontrollierbarkeit des Mediums in drahtlosen
Sensornetzen kaum vorstellbar sind, gibt es realistische
Anwendungsfälle mit weichen Echtzeitanforderungen, die
die Nicht-Einhaltung von Übertragungsraten oder Fristen bis
g ü te
Energie
SDMA, TDMA
Duty Cycling
Die
nst
eﬃ
zi e
nz
ib
i
virtuelle
Slotregionen
lit
ät
netzweite
Zeitsynchronisation
Topologieunabhängigkeit
th
geringe
ei
t
Komplexität
s
Die Autoren danken der Carl-Zeiss-Stiftung für die finanzielle Unterstützung.
wir die Sonderstellung der Zeitsynchronisation und begründen
die Notwendigkeit einer netzweiten Zeitsynchronisation mit
deterministischer Genauigkeit und Konvergenzzeit. Des Weiteren werden Lösungsansätze zu den Anforderungen beispielhaft
herausgegriffen und einzelne Protokolle betrachtet, in denen
die Lösungskonzepte implementiert wurden. Der Schwerpunkt
liegt hierbei auf dem 802.15.4-Standard [1].
u
Rob
Durch immer kleinere, günstigere und stromsparendere
Hardware erfahren drahtlose Sensornetzwerke in Industrie,
medizinischen Einrichtungen und dem häuslichen Umfeld
eine zunehmende Beliebtheit. Viele früher betrachtete Anwendungsszenarien, zum Beispiel zur Branderkennung in
Gebäuden, gingen von einem stationären Aufbau des Netzwerks aus. Dabei wurden häufig logische Baumstrukturen
angenommen, bei welchen Sensorwerte von den Blättern zur
Senke zu übertragen sind.
Neuere Anwendungsbeispiele haben allerdings gezeigt, dass
sich Sensornetzwerke nicht auf diese einfache Struktur beschränken lassen. Stattdessen bestehen zukünftige Anwendungen aus einer variierenden Anzahl mobiler Knoten, die einem Sensornetzwerk immer häufiger einen Ad-Hoc-Charakter
verleihen. Des Weiteren werden auch die Rollen der Netzwerkknoten und die Kommunikation immer vielfältiger. Sensorknoten überwachen nicht mehr nur ihre Umgebung, sondern
können diese in Form von Aktuatoren auch beeinflussen.
Durch die Eigenschaften vieler Anwendungstopologien und
die beschränkten Hardwareressourcen haben zukünftige Sensornetzwerke zusätzliche Herausforderungen zu meistern. Aufgrund der geringen Sendereichweite der Transceiver bestehen
bereits Netzwerke mit geringer räumlicher Ausdehnung aus
mehreren Broadcast-Domänen, so dass adäquate MAC- und
Routing-Protokolle benötigt werden, bei denen Energieaspekte und die Dynamik des Netzes schon im Design beachtet
werden. Aufgrund der Problematik von transienten Links, die
durch Mobilität und Knoteneintritte/-austritte verschärft wird,
muss auch dem Hidden- und Exposed-Station-Problem eine
hohe Bedeutung gegeben werden.
In dieser Arbeit analysieren wir Anforderungen an
zukünftige drahtlose Ad-Hoc-Sensornetzwerke. Im Konkreten
diskutieren wir in Abschnitt I folgende Aspekte:
• Dienstgüte
• Energieeffizienz
• Flexibilität
• Skalierbarkeit
• Robustheit
• Zeitsynchronisation
Neben der Erläuterung der einzelnen Anforderungen erörtern
x
Fle
Skalierbarkeit
Abbildung 1.
Anforderungen und Lösungen eines Ad-Hoc-Netzwerks.
37
zu einem gewissen Grad tolerieren. Beispiele finden sich in
drahtlos vernetzten Multimedia- oder Regelungssystemen.
Der Schlüssel zum Erreichen von Dienstgüte liegt in der
Organisation des Zugriffs auf das Medium. Falls eine kollisionsfreie Übertragung von Daten zu gewährleisten ist, scheiden
wettbewerbsbasierte Arbitrierungsschemata wie CSMA/CA im
Allgemeinen aus. Stattdessen eignen sich Multiplexverfahren
wie Time Division Multiple Access (TDMA) oder Frequency
Division Multiple Access (FDMA), wobei die Anwendbarkeit
der FDMA-Ansätze aufgrund der höheren Hardwareanforderungen und des Verwaltungsaufwands eingeschränkt ist.
TDMA-Ansätze sind hingegen in nahezu allen QoSProtokollen zu finden. Diese basieren auf der Einteilung der
Zeit in Zeitschlitze, die anschließend exklusiv einem Knoten zum Senden zugewiesen werden. Die Unterteilung in
Zeitschlitze wird in der Regel von einem MAC-Protokoll
vorgenommen, welches hierfür wiederum eine Synchronisation voraussetzt (siehe Abschnitt I-F). Die Zuweisung der
Zeitschlitze an Knoten ist Aufgabe eines Reservierungsprotokolls, welches häufig Teil eines QoS-Routingprotokolls ist
[2]. Zur Erhöhung der Effizienz können gleiche Zeitschlitze an
Knoten, die außerhalb der Interferenzreichweite voneinander
positioniert sind, zugeordnet werden (Spatial Division Multiple Access (SDMA)), wobei das Hidden-Station- und das
Exposed-Station-Problem zu beachten sind. Zu beachten ist
ferner, dass die Interferenzreichweite in der Regel größer ist
als die Sendereichweite.
Im Beacon-Modus des IEEE 802.15.4-Standards sind reservierbare Zeitschlitze in Form der Guaranteed Time Slots
(GTS) zu finden [1].
B. Energieeffizienz
Da Sensorknoten häufig mit Batterien oder Akkus betrieben
werden und der Austausch kostspielig ist, ist die Energieeffizienz oft das primäre Optimierungsziel in drahtlosen Sensornetzwerken. In [3] wurden bezogen auf die Kommunikation 4 Quellen von Energieverschwendung identifiziert: Idle
Listening (Knoten sind empfangsbereit ohne dass empfangen
wird), Overhearing (es werden Daten empfangen, die für
andere Knoten bestimmt sind), Kollisionen und Protokolloverhead. Eine ideale Energieeffizienz liegt vor, wenn Knoten
ausschließlich während Sende-/Empfangsvorgängen im Sende/Empfangsmodus sind.
Um sich diesem Ideal anzunähern, entstanden 2 Ansätze:
Preamble Sampling und Duty Cycling. Preamble Sampling
ist ein asynchrones Verfahren, bei dem der Sender vor der
Übertragung der Daten ein Wecksignal auf das Medium legt.
Empfänger, die ihren Transceiver regelmäßig in den Empfangsmodus schalten, verbleiben bei Erkennung eines Wecksignals im Empfangsmodus bis die Übertragung der Nutzdaten
abgeschlossen ist. Ein Beispiel eines Preamble SamplingProtokolls ist WiseMAC [4].
Bei Duty Cycling wird die Zeit in periodische Aktiv- und
Schlafphasen unterteilt: In Aktivphasen finden Übertragungen
statt, in den Schlafphasen wird der Transceiver der Knoten
in einen stromsparenden idle-Modus versetzt. Um Aktiv-/
38
Exklusive Regionen
Synchronisation
Arbitrierungsregionen
Idle-Regionen
Abbildung 2.
Virtuelle Slotregionen [7].
Schlafphasen aufeinander abzustimmen, ist eine Zeitsynchronisation unerlässlich (siehe Abschnitt I-F). Eines der ersten
Duty Cycling-Protokolle für drahtlose Sensornetzwerke ist
S-MAC [3]. Duty Cycling in Verbindung mit effizienten
Multi-Hop-Übertragungen wurde in RMAC thematisiert [5].
Der IEEE 802.15.4-Standard realisiert Duty Cycling ebenfalls durch eine Unterteilung des sogenannten Superframes in
Aktiv-/Inaktiv-Phasen [1].
C. Flexibilität
Aus Gründen des Entwicklungsaufwands und der Kosten
sollten Protokolle für Sensornetzwerke nicht auf ein bestimmtes Szenario zugeschnitten sein. Stattdessen sollten sie
generischer Natur sein und flexibel per Konfiguration an
unterschiedliche Anwendungen und dynamisch zur Laufzeit
angepasst werden können. Im Konkreten sollten beliebige
Verkehrsmuster (periodische sowie sporadische) unterstützt
und optimiert werden und Kommunikation zwischen allen
Knotenpaaren möglich sein. Letzteres wird beispielsweise von
vielen Protokollen nicht erfüllt, die auf logischen Baumstrukturen beruhen, in der Daten ausschließlich zur Datensenke
fließen [6].
Möglichkeiten zur Erhöhung der Flexibilität bieten virtuelle
Slotregionen [7]. Virtuelle Slotregionen sind ebenfalls eine
Lösung, die wiederum eine Synchronisation voraussetzt (siehe
Abschnitt I-F). Abbildung 2 zeigt hierzu ein Beispiel. Zwischen 2 Synchronisationsphasen können 3 Arten von Regionen
beliebig platziert werden: Exklusive Regionen, die für reservierungsbasierte Übertragungen bestimmt sind (siehe auch
Abschnitt I-A), Arbitrierungsregionen für wettbewerbsbasierten Zugriff auf das Medium (bspw. für Übertragungen ohne
verbindliche Dienstgüteanforderung) und Idle-Regionen zum
Sparen von Energie (siehe auch Abschnitt I-B).
Der IEEE 802.15.4-Standard unterstützt virtuelle Slotregionen nur stark eingeschränkt und bietet daher eine geringe
Flexibilität [1]. Ein Superframe folgt immer dem gleichen Aufbau: Beacon-Übertragung, Aktiv-Phase (bestehend aus Wettbewerbsphase und maximal 7 GTS) und Inaktiv-Phase. Die
Länge der einzelnen Phasen ist zwar konfigurierbar, die Anzahl
und Position der Phasen lässt sich aber nicht ändern. Des
Weiteren kann ein Knoten während eines GTS ausschließlich
mit dem PAN-Koordinator kommunizieren, so dass keine
beliebigen Kommunikationspartner unterstützt werden.
D. Skalierbarkeit
Durch immer günstigere Hardware und kleinere Bauformen
ist in vielen Szenarien eine hohe Knotendichte und eine
komplexe Topologie zu erwarten. Protokolle sollten daher
eine hohe Skalierbarkeit aufweisen, d.h. sie sollten eine große
Knotenanzahl und eine stark ausgeprägte topologische Dynamik bewältigen können. Dabei ist auch die Verwaltung von
Multi-Hop-Topologien und die Eingliederung neuer Knoten
zur Laufzeit in das Netzwerk zu unterstützen.
Um dieses Ziel zu erreichen, müssen die Protokolle eine
geringe Zeit- und Nachrichtenkomplexität hinsichtlich des
Verwaltungsoverheads aufweisen. Verwaltungsoverhead entsteht zum Beispiel bei der Koordination von Reservierungen
siehe auch (Abschnitt I-A) oder bei der Durchführung der
Synchronisation (siehe auch Abschnitt I-F). Für all diese
Verwaltungsaktionen gilt, dass der Overhead maximal linear
von der Knotenanzahl abhängen sollte, d.h. bei n Knoten sollte
die Komplexität O(n) nicht überschreiten.
Des Weiteren besteht eine große Abhängigkeit zwischen
Skalierbarkeit und Flexibilität. Steigt beispielsweise die Anzahl der Knoten, dann ist zu erwarten, dass auch der Bedarf
an reservierbaren Zeitslots wächst. Solange das Medium noch
Kapazitäten aufweist, sollte dieser Bedarf durch Hinzunahme
neuer Reservierungsslots gedeckt werden können.
Eine hohe Skalierbarkeit setzt außerdem voraus, dass die
Effizienz eines Protokolls nicht übermäßig von der Knotenanzahl abhängen darf. Beispielsweise erfüllen viele Duty
Cycling-Protokolle, unter Anderem auch S-MAC [3], dieses
Kriterium nicht, da sie unter einer starken Sensitivität von der
Knotenanzahl leiden. Bei ihnen steigt der Energieverbrauch
einzelner Knoten mit einer wachsenden Anzahl von Nachbarknoten stark an, unabhängig davon, ob die Knoten selbst neue
Kommunikationspartner erhalten.
Auch der IEEE 802.15.4-Standard erlaubt Skalierbarkeit
nur eingeschränkt [1]. Die Gründe hierfür liegen unter Anderem in der beschränkten Anzahl an GTS, die maximal
7 wettbewerbsfreie Übertragungsslots pro PAN-Koordinator
erlaubt, und in der komplexen Verwaltung von Multi-HopNetzwerken. Im Allgemeinen lässt sich festhalten, dass MultiHop-Netzwerke nur unzureichend von dem 802.15.4-Standard
unterstützt werden.
E. Robustheit
Aufgrund der Beschaffenheit von Sensorknoten sind Knotenausfälle und transiente Links in einem drahtlosen Sensornetzwerk häufiger zu erwarten als in herkömmlichen drahtgebundenen Vernetzungen. Protokolle für drahtlose Sensornetzwerke müssen daher robust gegen eine daraus entstehende
topologische Dynamik sein und Knotenausfälle bis zu einem
gewissen Ausmaß verkraften können.
Um dieses Ziel zu erreichen, dürfen die Netzwerke keine
stark ausgeprägte Abhängigkeit von der Topologie besitzen.
Insbesondere darf kein Single-Point-of-Failure existieren, dessen Wegfall zu einem Ausfall des kompletten Systems führt.
Es werden demnach dezentrale Protokolle und dezentral organisierte Netzwerkstrukturen benötigt, die effektiv und schnell
auf einen Knotenausfall reagieren.
Der IEEE 802.15.4-Standard erfüllt diese Ansprüche im
Beacon-Modus nicht, da PAN-Koordinatoren die Achillesfersen eines Netzwerks sind [1]. Der Non-Beacon-Modus ist
tk
Knoten Vk
reservierter Sendeslot für Vk
tr
Uhrenabweichung: | tk - t r | = doffset
Knoten Vr
reservierter Sendeslot für Vr
Abbildung 3.
Auswirkungen von Synchronisationsungenauigkeiten.
hingegen robuster gegen Knotenausfälle, wird aber den anderen oben genannten Anforderungen nicht gerecht. Auch viele
Protokolle, die auf drahtlosen oder drahtgebundenen virtuellen
Backbones basieren, sind wenig robust gegen Knotenausfälle.
[8] stellt diesbezüglich Maßnahmen vor, um Knotenausfälle
vorherzusehen und daraus entstehende Probleme proaktiv zu
verhindern. Bei unerwarteten Knotenausfällen versagen aber
auch solche Ansätze.
Protokolle, in denen kein Knoten eine Sonderrolle einnimmt, sind in der Regel robuster gegen Knotenausfälle.
Beispiele sind MacZ [7] und RMAC [5]. Allerdings ist zu
beachten, dass manche dieser Protokolle für sich betrachtet
zwar dezentral und dadurch robust sind, aber auf weniger robusten Diensten aufsetzen. Beispielsweise wird in RMAC zur
Synchronisation auf TPSN verwiesen [9], welches ausgewählte
Referenzknoten zur Synchronisation verwendet, deren Ausfall
eine Neuwahl der Referenzknoten zur Folge hat. Demnach
ist die Zeitsynchronisation auch hier ein ausschlaggebender
Faktor zum Erreichen einer hohen Robustheit (siehe auch
Abschnitt I-F).
F. Netzweite Zeitsynchronisation
Netzweite Zeitsynchronisation ist aus Kommunikationssicht
Voraussetzung für TDMA-Ansätze zum Mediumzugriff, Duty Cycling und die Bildung virtueller Slotregionen (siehe
Abschnitte I-A, I-B, I-C). Damit besitzt die netzweite Zeitsynchronisation in Ad-Hoc-Netzen eine Sonderstellung (siehe
Abbildung 1). Aus einer Reihe von Gründen ist eine perfekte Zeitsynchronisation nicht möglich, so dass zwischen den
lokalen Uhren immer eine Restabweichung, genannt Clock
Offset, besteht, die möglichst klein zu halten ist. Abbildung 3
zeigt ein TDMA-Szenario, in dem dieser Clock Offset zu einer
Kollision von Nachrichten der Knoten Vk und Vr führt, obwohl
beide Knoten in benachbarten reservierten Slots senden. Solche Kollisionen lassen sich nur dann zuverlässig vermeiden,
wenn die Zeitsynchronisation einen netzweiten maximalen
Clock Offset unter Einhaltung einer geringen und beschränkten
Konvergenzzeit – die Dauer bis zum (Wieder-)Erreichen des
maximalen Clock Offsets – garantieren kann. Die Verwendung
des mittleren Clock Offsets genügt also nicht; vielmehr sind
deterministische Verfahren zur netzweiten Zeitsynchronisation
erforderlich.
Der IEEE 802.15.4-Standard sieht im Beacon-Modus zwar
eine Zeitsynchronisation vor, allerdings beschränkt auf die
Single-Hop-Bereiche der PAN-Koordinatoren [1]. Häufig zitierte Verfahren zur netzweiten Zeitsynchronisation wie RBS
39
[10] oder TPSN [9] arbeiten mit statistischen Ansätzen zur
Ermittlung des Clock Offsets und haben außerdem eine Konvergenzzeit ohne obere Schranke. Lösungen auf der Basis
von GPS haben Nachteile hinsichtlich Hardwarekosten und
Energieverbrauch. Sie eignen sich außerdem nicht für den
Einsatz in Gebäuden. Ein Verfahren, das die erforderlichen
Eigenschaften aufweist, ist BBS [11].
II. Z USAMMENFASSUNG
Die zunehmenden Möglichkeiten von Sensornetzwerken
zeigen, dass Ambient Intelligence und Pervasive Computing
schon lange keine reine Fiktion mehr sind. Mit der Anzahl
der Anwendungsfälle steigt aber auch die Anzahl der Anforderungen an ein drahtloses Sensornetz, welches heute in vielen
Fällen Ähnlichkeiten mit Ad-Hoc-Netzwerken aufweist.
In dieser Arbeit haben wir 6 Anforderungen an zukünftige
Sensornetzwerke analysiert. Dabei wurde gezeigt, dass zwar
zahlreiche Lösungsansätze für die einzelnen Anforderungen
existieren, aber kein existierendes Protokoll alle Anforderungen in Einklang bringt. Insbesondere der IEEE 802.15.4Standard offenbart bei näherer Betrachtung einige Schwächen;
vor Allem fehlende Flexibilität und geringe Robustheit.
Des Weiteren wurde gezeigt, dass die Zeitsynchronisation
eine Sonderrolle unter allen Anforderungen einnimmt, da sie
häufig nicht nur durch die Anwendungen selbst benötigt wird,
sondern auch einen Basisdienst zur Erfüllung anderer Anforderungen bereitstellt. Es wurde verdeutlicht, dass ein Bedarf
an skalierenden Multi-Hop-Synchronisationsprotokollen mit
deterministisch beschränkter Genauigkeit und Konvergenzzeit
besteht, um netzweites Mediumslotting als Grundlage für
Reservierungen und Dienstgüte zu ermöglichen.
40
L ITERATUR
[1] IEEE, Part 15.4: Wireless Medium Access Control (MAC) and
Physical Layer (PHY) Specifications for Low-Rate Wireless Personal
Area Networks (LR-WPANs). New York, NY, USA: IEEE Computer
Society, Oct. 2003. [Online]. Available: http://standards.ieee.org/
getieee802/download/802.15.4-2006.pdf
[2] W.-H. Liao, Y.-C. Tseng, and K.-P. Shih, “A TDMA-based Bandwidth
Reservation Protocol for QoS Routing in a Wireless Mobile Ad Hoc
Network,” in Proceedings of IEEE ICC, April–May 2002.
[3] W. Ye, J. S. Heidemann, and D. Estrin, “An Energy-Efficient MAC
Protocol for Wireless Sensor Networks,” in INFOCOM, June 2002.
[4] A. El-Hoiydi and J.-D. Decotignie, “WiseMAC: an ultra low power
MAC protocol for the downlink of infrastructure wireless sensor networks,” in ISCC. IEEE Computer Society, 2004, pp. 244–251.
[5] S. Du, A. K. Saha, and D. B. Johnson, “RMAC: A routing-enhanced
duty-cycle MAC protocol for wireless sensor networks,” in INFOCOM,
2007, pp. 1478–1486.
[6] G. Lu, B. Krishnamachari, and C. S. Raghavendra, “An adaptive energyefficient and low-latency MAC for data gathering in wireless sensor networks,” Parallel and Distributed Processing Symposium, International,
vol. 13, p. 224a, 2004.
[7] P. Becker, R. Gotzhein, and T. Kuhn, “MacZ – A Quality-of-Service
MAC Layer for Ad-hoc Networks,” in HIS ’07: Proceedings of the
7th International Conference on Hybrid Intelligent Systems.
IEEE
Computer Society, Sept. 2007, pp. 277–282.
[8] M. Ayyash, K. Alzoubi, and Y. Alsbou, “Preemptive Quality of
Service Infrastructure for Wireless Mobile Ad Hoc Networks,”
in Proceedings of the 2006 international conference on Wireless
communications and mobile computing, ser. IWCMC ’06. New
York, NY, USA: ACM, 2006, pp. 707–712. [Online]. Available:
http://doi.acm.org/10.1145/1143549.1143690
[9] S. Ganeriwal, R. Kumar, and M. B. Srivastava, “Timing-sync protocol
for sensor networks,” in SenSys, I. F. Akyildiz, D. Estrin, D. E. Culler,
and M. B. Srivastava, Eds. ACM, 2003, pp. 138–149.
[10] J. Elson, L. Girod, and D. Estrin, “Fine-grained network time synchronization using reference broadcasts,” in OSDI. Proceedings of the Fifth
Symposium on Operating Systems Design and Implementation (OSDI
2002), Boston, MA, USA, 2002.
[11] R. Gotzhein and T. Kuhn, “Decentralized Tick Synchronization for
Multi-Hop Medium Slotting in Wireless Ad Hoc Networks Using Black
Bursts,” in 5th Annual IEEE Communications Society Conference on
Sensor, Mesh and Ad Hoc Communications and Networks. SECON’08,
San Francisco. IEEE, June 2008, pp. 422–431.
Energy Profiling for Wireless Sensor Networks
Oliver Hahm
Stephan Adler
Nicolai Schmittberger
Mesut Güneş
Institute of Computer Science
Computer Systems and Telematics
Distributed Embedded Systems
Freie Universität Berlin, Germany
{ohahm, adler, schmittb, guenes}@inf.fu-berlin.de
Abstract—Energy constraints are one of the most crucial
challenges when designing protocols and algorithms for Wireless
Sensor Networks (WSNs). Thus, a deep understanding of the
energy consumption within a WSN is mandatory. For this
purpose, energy measurements on the real sensor node hardware
provide accurate numbers for a single node. Another method is
employing an abstract energy model that can be used to estimate
the lifetime of the nodes and the whole network. While the
first method is usually hard to deploy for large scale networks,
the second approach might suffer from errors and improper
generalizations of the model. In order to obtain a deeper insight
of energy consumption, it would be desirable to determine the
power demands in a high resolution. In this paper we are
introducing an approach of detailed information reports about
the energy consumption based on a fine-granular measurement
using the integrated coulomb counter sensor of the evaluation
platform, the MSB-A2. We will present a technique to create
statistics of the demand for energy for every single node in the
network in the same way as traditional software profiling is done.
Index Terms—Wireless Sensor Network (WSN), energy consumption, energy measurement
I. I NTRODUCTION
When talking about WSNs Moore’s Law [1] gets a different
meaning. For these devices, the nodes should become smaller,
cheaper and more energy efficient instead of increasing the
CPU speed or enlarging the available memory. Over ten years
have passed by since the idea of Smart Dust was first mentioned [2], but the current available hardware is still not small
enough and the energy consumption is still too high to realize
this vision. While these nodes are usually battery operated
and no breakthroughs in battery technology are expected in
the next years, this aspect is also reflected in the volume and
weight of the device. For many sensor nodes current battery
supply consumes more than half of the device’s dimension.
On the contrary, a lot of improvement has taken place at
the hardware level. New technologies enable high efficient
sleep modes for almost every single part of the sensor node,
particularly for the microcontroller itself and the transceiver. In
addition, modern transceivers are able to communicate with a
surprisingly low amount of energy. Nevertheless, the software
still has to exploit these hardware capabilities.
Therefore, a lot of new protocols at all layers of the ISO
OSI model with a special focus on energy awareness have
been designed during the last decade. Unfortunately, most of
the evaluation of these protocols was based on simulations.
But while the protocols and algorithms have advanced significantly, little work has been done on improving the energy
models used by simulators. One reason for this is that a deep
understanding of how, where, and when energy consumption
takes place is still lacking. Hence, real power consumption
measurements of the communication subsystem of a sensor
node often discloses a severe discrepance to widely cited
energy models. Additionally, some work on the evaluation of
power consumption has been done. This work can be classified
in three different categories: theoretical analysis, simulation
and hardware measurements.
The contribution of this paper is to introduce a novel
technique to estimate real energy consumption of WSNs.
We will present a way to perform real time measurements
of network protocols and algorithms for sensor networks
using a coulomb counter and microkernel based operating
system. While the counter allows high accurate measurements
of the current consumption, the operating systems provides
the capability to exploit per-thread evaluation. Hence, it is
feasible to accumulate power consumption over time as well
as to consider the pattern of power load as proposed by
Shnayder et al. [3]. In addition, this methodology enables
in situ measurement at large scales. In this manner, power
usage can be monitored in a network-wide view which makes
it possible to discover variances that are subject to changes in
network topology or to detect hot spots.
The remainder of this work is structured as follows. In
section II we describe previous work on how energy consumption can be evaluated. The following section III introduces the
energy profiling we have implemented to enable fine-grained
analysis of the energy consumption. Finally, section IV identifies some possible future work on this topic and describes how
the results of our energy profiling could be used for prospective
simulation work. We conclude the paper in section V.
II. R ELATED W ORK
Evaluation of energy consumption traditionally has been
done in three different ways. The theoretical analysis mostly
takes the values for energy demands given by the devices’ data
sheets and generate equations for the single processes. Simulation based experimentation attempts to derive more generic
energy models as input for the simulator. The third approach
finally relies on actual measurements of the hardware.
41
The theoretical approach tries to formalize common hardware operations and create a detailed model to predict energy
consumption. Landsiedel et al., for example, considered real
sensor applications, operating system code, and measurements
to enable accurate prediction of the energy consumption for
their approach called AEON [4]. This work also mentions the
idea of energy profiling. They achieved this by mapping source
code functions to the corresponding object code addresses
for TinyOS [5]. However, since TinyOS is not written in
a common programming language, but its own dialect of
C, nesC [6], this approach unfortunately is not portable to
other platforms. Hence, this work does not provide a general
approach to evaluate energy consumption in a real world
deployment, but presents an interesting idea which is worth
to be extended in a more generic way.
To adapt the often complex models from theoretical analysis, simulation based studies typically use simplified assumptions. They usually describe a state machine and rely on basic
formulas like Equation 1 that was formed by Schmidt et al. [7].
X
X
E=
Pstate · tstate +
Ptrans · ttrans
(1)
state
trans
Here Pstate refers to the consumed power in state and tstate
to the time spent in this state, while Ptrans and ttrans have
the same meaning for the transitions between two states.
For reliable hardware measurements of energy consumption,
the difficulties are threefold. First, it is hard to achieve
accurate results and to prevent getting erroneous results due
to misconfiguration or failure of the measurement devices.
Second, one must think of a way to correlate the results to
the actual program and software flow of the observed node.
Third, measurement is often only feasible for a single node or
at most for a small set of nodes in a lab setup The reason for
that is, that measurement hardware is often expensive, needs
manual configuration or administration, and is much harder to
deploy to a large area.
Keller et al. present one approach by introducing their
own measurement platform SNMD (Sensor Node Management
Device) [8]. By performing real hardware measurement on
this device they try to validate and improve their FSM based
energy model. The core of measurement platform is an ADC
that supports a resolution of up to 76.249µV and a frequency
of up to 500Hz. Nonetheless, it is still possible that data is
lost that way.
Some of the more holistic studies combine the methods.
This can be done by first stating an abstract model for energy
consumption, which then is adapted to a particular simulation
platform. Another quite popular approach is to validate results
gained from a theoretical analysis or simulation by comparing
them to measurements from a prototypical implementation on
real hardware.
III. E NERGY PROFILING ON MSB-A2 WITH µKLEOS
In this section we will first introduce the general idea of
our technique for the estimation of energy consumption. Next,
we will present the hardware platform and operating system
42
we use for our implementation and experiments. However,
our approach in principle is general and not coupled to this
special hardware or system software. Finally, we will describe
implementation details.
A. Energy Profiling
While the previously presented approaches mostly started
by setting up a formal model for energy consumption and
validate it afterwards by prototypical implementations, we try
to gain as much data as possible from real WSN applications.
The results can serve as input parameters for simulations and
to obtain a very precise general energy model.
The starting point of our approach is one of the common
analysis tools during code development for traditional software: code profiling. The idea of profiling intends to present a
very fine granular view to the call tree to the software engineer.
Code profiling provides a detailed insight into the functioning
of a program.
The same technique can also be applied to software for
sensor nodes. In this way, CPU usage can be broken down
to individual routines and blocks in the source code, which
allows for a fine-grained code analysis. The profiling cannot
only display the call tree of a running software but also create
a detailed overview about how much time is spent in each
single function. By the usage of code profiling long running
functions can be revealed as well as possible never called
code fragments. Moreover, this method helps to gain a general
understanding of the code structure and data flow.
The central idea of the methodology we present in this
paper is based on extending this code profiling technique
to include energy measurement. Therefore, we combined the
technique with a hardware measurement device to gain a
deeper understanding of the energy consumption. A closer
look at the actual used measurement device follows in the
next section. The method itself allows for measurement of
the current consumption without doing any changes to the
evaluated code itself.
By capturing the duration and energy consumption of any
function at the same time, it is possible to correlate its
runtime with its power demands. Hence, even though separate
measurements of the single devices within the sensor node
system are not feasible, one can still reveal the parts of
the code where most of the energy is consumed. In turn it
allows for detecting critical components in terms of energy
consumption.
The overall advantage of the energy profiling method is
its generality. It provides a universal approach towards the
evaluation of energy consumption that is not limited to a
particular paradigm or operating system.
B. Hardware and Software
As hardware platform we use the MSB-A2 which is
equipped with a LTC4150 coulomb counter as shown in Figure 1 [9]. This device fits our requirements, since it allows
energy measurements with almost no overhead in terms of
computing time and power demands. Moreover, the coulomb
Fig. 1.
A MSB-A2 sensor node with LTC4150 coulomb counter.
counter method enables a very comprehensive way to observe
power consumption. It provides a sense voltage range of
50mV and a charge count frequency of 32.55Hz. The power
consumption is in the scale of micro-watt.
On important advantage of this platform is the direct integration of the coulomb counter on the sensor node. The benefits
of this composition are twofold. First, direct feedback between
the program running at the sensor node and energy evaluation
is easily achievable. Second, there is no need for additional
measurement hardware. The monitoring device comes directly
on board of the sensor node itself and can therefore be easily
deployed, even for large scale sensor testbeds.
As an operating system we use µkleos, a multi-threaded
operating system for WSNs. µkleos is the successor of the
FireKernel software and exhibits almost the same features in
terms of low latency and overhead-free context switching [10].
The core itself is a microkernel, thus, only containing the most
essential functions like scheduling, interprocess communication, and threading.
A big advantage of this architecture for our purpose was
the possibility to analyze the energy consumption per thread.
In this manner, we can break down the power demands of
different tasks in any arbitrary way.
Since µkleos is written in pure ANSI C, well-known,
matured tools can be used during development, for debugging, and code analysis. This represents a big advantage in
comparison to TinyOS or Contiki [11] which define their own
C like dialects. Even though both programming languages have
a close relationship to C, well established tools like the GNU
Compiler Collection (GCC) are not usable out of the box [12].
C. Implementation
To implement this energy profiler, we made use of a feature
of the GCC C compiler. The GCC offers a compiler flag (finstrument-functions) which allows to define functions to be
called each time any function is entered or completed.
In addition with some small modifications to the scheduler
of µkleos, this enables a detailed analysis of the function
call tree and enables per-thread evaluation of the energy
consumption. The profiling functions that are called at function
entry and exit are very short running with little complexity. By
making timestamps and querying the coulomb counter value
Fig. 2. An example function tree with two running threads and one incoming
interrupt. Each horizontal line represents a tick of the coulomb counter.
it can be exposed where most of the time and energy is spent
within the program.
The Profiler maintains a small stack for each thread and
a struct SInf o with statistical information about each function. These statistics comprises the number of function calls,
the duration of function execution, and energy consumption.
Everytime a function is called, the profiler pushes the index
of SInf o on the stack, increases the stack pointer, and saves
current hardware timer and coulomb counter value. Furthermore, it is checked by a flag if another function within the
same thread is tagged as running. If such a function is found
SInf o for this function is updated, otherwise the flag is set
for the active function. When a function is left, SInf o for this
function is updated, the stack is popped, and stack pointer gets
decreased.
To deal with concurrency and the limited resolution of
the coulomb counter, we added small software hooks at the
interrupt handler of the LTC4150 In this manner, no more
additional effort is required for the software developer of the
sensor node applications. The software is built and executed
as normal. Just the results of the energy evaluation have to be
captured via the serial interface.
Furthermore, it is possible to activate or deactivate the
energy evaluation on a per-source-file base. This is configured
within the build system. Particular functions can be excluded
from being monitored via a specific C attribute in the source
code.
IV. O UTLOOK AND FUTURE WORK
One open task for our approach is caused by the hardware
characteristics of the LTC4150. The resolution of this IC is not
43
sufficient high so that every switch between to threads can
be monitored. Figure 2 depicts the problem. While the two
threads runs some functions, the coulomb counter generates
some ticks. Between two ticks more than one function might
run. Thus, the profiler only detects which functions run but
cannot calculate which function has consumed which fraction
of the coulomb counter tick. However, it can be assumed that
each function runs sufficiently often during an experiment
that a system of equations can be developed to calculate
these fractions. As another improvement a coulomb counter
with a higher resolution could exploit the possibility of even
instruction level granularity.
We plan to formalize the result of experiments using our
methodology as a more general energy model. This model in
turn could serve for more realistic simulations. It can also be
utilized to verify or falsify existing energy models. In case
that an existing model could be validated, the results from
measurements with energy profiling method provide input
parameters for this model.
Due to the generality of energy profiling we are going
to examine of all layers of the network stack and every
application. However, so far many protocols and algorithms
proposed by research for WSNs are not available in open
implementation for real hardware. Examination often is only
done by simulation or at most implemented for Contiki or
TinyOS. More generic implementations for real hardware
is desirable. The algorithm library Wiselib seems to be a
promising effort in this direction. [13] As soon as more
implementations for MAC protocols, routing algorithms and
any other kind of software used for sensor node applications
exist, more detailed evaluation on their energy consumption
can be done due to the energy profiler. Additionally, we are
planning to conduct larger experiments with up to 150 sensor
nodes in large scale testbeds such as the DES-Testbed [14]
[15] to exploit the scalability support of the energy profiling
technique.
In principle not even a coulomb counter is required to make
use of the energy profiling method. Any device that is capable
for accurate measurement of power consumption can serve as
input for the profiler.
V. C ONCLUSION
This paper introduces a novel approach to analyze energy
consumption for WSN. The estimation of energy consumption is a crucial requirement when developing protocols and
applications for sensor nodes to predict the lifetime of a
network during development. The proposed technique provides
real time measurement for sensor networks that scale up to
thousands of nodes. To achieve this, we present an energy
profiler. This tool allows for accurate evaluation of time and
energy spent by each function and, additionally, each thread.
We achieve this by making use of a coulomb counter equipped
directly on each sensor node. We implemented this energy
profiling on µkleos to exploit the benefits of a real multithreading capable microkernel. In this manner, the operating
system enables analysis of power demands per thread.
44
Summarized this methodology allows for the accumulation
of energy consumption over time and considering the pattern
of power load. Furthermore, there exists no limiting factor
for this approach which make in situ measurements feasible
for large scale networks. This work reveals the analysis of
power usage in a network-wide picture which is necessary for
evaluation of variations in energy consumption under changes
in the environment.
R EFERENCES
[1] G. E. Moore, “Cramming More Components onto Integrated Circuits,”
Electronics, vol. 38, no. 8, pp. 114–117, Apr. 1965. [Online]. Available:
http://dx.doi.org/10.1109/JPROC.1998.658762
[2] J. M. Kahn, R. H. Katz, and K. S. J. Pister, “Next century challenges:
mobile networking for ”Smart Dust”,” in MobiCom ’99: Proceedings
of the 5th annual ACM/IEEE international conference on Mobile
computing and networking. New York, NY, USA: ACM Press, 1999, pp.
271–278. [Online]. Available: http://dx.doi.org/10.1145/313451.313558
[3] V. Shnayder, M. Hempstead, B. Chen, G. Werner-Allen, and M. Wels,
“ Simulating the power consumption of large-scale sensor network
applications,” in SenSys ’04: Proceedings of the 2nd international
conference on Embedded networked sensor systems. New York, NY,
USA: ACM Press, Nov. 2004, pp. 188–200.
[4] O. Landsiedel, K. Wehrle, and S. Götz, “Aeon: Accurate prediction
of power consumption in sensor networks,” in In Proceedings of The
Second IEEE Workshop on Embedded Networked Sensors (EmNetS-II,
2004.
[5] P. Levis, S. Madden, J. Polastre, R. Szewczyk, K. Whitehouse, A. Woo,
D. Gay, J. Hill, M. Welsh, E. Brewer, and D. Culler, “TinyOS:
An Operating System for Sensor Networks,” in Ambient Intelligence,
W. Weber, J. M. Rabaey, and E. Aarts, Eds. Berlin/Heidelberg:
Springer-Verlag, 2005, ch. 7, pp. 115–148. [Online]. Available:
http://dx.doi.org/10.1007/3-540-27139-2 7
[6] D. Gay, P. Levis, R. von Behren, M. Welsh, E. Brewer, and D. Culler,
“The nesc language: A holistic approach to networked embedded
systems,” in Proceedings of the ACM SIGPLAN 2003 conference on
Programming language design and implementation, ser. PLDI ’03.
New York, NY, USA: ACM, 2003, pp. 1–11. [Online]. Available:
http://doi.acm.org/10.1145/781131.781133
[7] D. Schmidt, M. Krämer, T. Kuhn, and N. Wehn, “Energy modelling in
sensor networks,” Advances in Radio Science, vol. 3, no. 5, pp. 347–351,
Jun. 2007.
[8] S. Kellner, M. Pink, D. Meier, and E.-O. Blass, “Towards a realistic
energy model for wireless sensor networks,” in The Fifth Annual Conference on Wireless On demand Network Systems and Services (WONS
2008), Garmisch-Partenkirchen, Germany, Jan. 23–25 2008, publication.
[9] M. Baar, H. Will, B. Blywis, A. Liers, G. Wittenburg, and J. Schiller,
“The ScatterWeb MSB-A2 Platform for Wireless Sensor Networks,”
Freie Universität Berlin, Tech. Rep., 2008.
[10] H. Will, K. Schleiser, and J. H. Schiller, “A real-time kernel for wireless
sensor networks employed in rescue scenarios,” in Proc. of the 34th
IEEE Conference on Local Computer Networks (LCN), M. Younis and
C. T. Chou, Eds. Piscataway, NJ, USA: IEEE Press, October 2009, pp.
834–841.
[11] A. Dunkels, B. Grönvall, and T. Voigt, “Contiki - a lightweight and
flexible operating system for tiny networked sensors.” pp. 455–462,
2004. [Online]. Available: http://dblp.uni-trier.de/db/conf/lcn/lcn2004.
html#DunkelsGV04
[12] gnu.org,
“GCC,
the
GNU
Compiler
Collection,”
http://gcc.gnu.org/, 2011. [Online]. Available: http://gcc.
gnu.org/
[13] T. Baumgartner, I. Chatzigiannakis, S. Fekete, C. Koninis, A. Kröller,
and A. Pyrgelis, “Wiselib: A generic algorithm library for heterogeneous
sensor networks,” in Proceedings of EWSN 2010, vol. 5970. Springer,
2010, pp. 162–177.
[14] M. Günes, B. Blywis, and F. Juraschek, “Concept and Design of
the Hybrid Distributed Embedded Systems Testbed,” Freie Universität
Berlin, Tech. Rep. TR-B-08-10, 2008.
[15] M. Guenes, F. Juraschek, B. Blywis, Q. Mushtaq, and J. Schiller, “A
testbed for next generation wireless network research,” 2009, submitted
to PiK - Special Issue on Mobile Ad-hoc Networks.
Simulationsgestützte Algorithmenentwicklung für
drahtlose Sensornetze
Stefan Lange
Oliver Stecklina
Michael Methfessel
IHP
Im Technologiepark 25
D- 15236 Frankfurt (Oder)
Germany
[email protected]
IHP
Germany
[email protected]
IHP
Germany
[email protected]
Abstract— Die technische Entwicklung der letzten Jahre im
Bereich
der
Microcontroller
und
drahtlosen
Sensornetzwerke hat dazu geführt, dass deren
Leistungsfähigkeit und damit deren Einsatzmöglichkeiten
stark angewachsen sind. Diese Entwicklung bildet die
Grundlage für das „Internet der Dinge“, welche aktuell
vielfach Gegenstand der Forschung und Entwicklung von
modernen eingebetteten Systemen ist. Die gestiegene
Leistungsfähigkeit
der
Mikrocontroller-basierten
Sensorknoten und Sensornetzwerk bedingt jedoch eine
stetig steigende Komplexität der eingesetzten SoftwareSysteme. Für den Nachweis der Funktionsfähigkeit von
neuen Algorithmen hat sich der Einsatz von
Simulationswerkzeugen durchgesetzt. Sie ermöglichen eine
Übertragung der Realität in eine Laborumgebung und
beschleunigen maßgeblich die Entwicklungszeiten und
damit die Time-to-Market eines Produktes. Die
Übertragbarkeit der Simulationsergebnisse auf reale
Sensornetze hängt jedoch entscheidend von der
Genauigkeit des Simulationsmodells ab. Einfache
Simulationsmodelle bieten nur ungenaue und mitunter
falsche Ergebnisse. Exakte Modelle sind sehr schwer
Umsetzbar
und
benötigen
meist
sehr
lange
Simulationszeiten. Um diese Lücke zwischen der
Simulation und der realer Welt zu verkleinern,
präsentieren wir in diesem Beitrag einen Ansatz, der die
Spezifika der Simulationsumgebung in die reale
Systemumgebung integriert und damit die Verwendung
von einfachen Simulationsumgebungen möglich macht.
Zum Nachweis der Tragfähigkeit unseres Ansatzes
präsentieren wir ein praktisches Beispiel eines Bluetoothbasierten Multi-Hop-Netzwerkes, wo wir den vorgestellten
Ansatz erfolgreich einsetzen konnten.
I.
Verfügbarkeit und die Zuverlässigkeit des Gesamtsystems
gegenüber der drahtgebundenen Lösung nicht negativ
beeinflusst werden. Zum Erreichen des Ziels wurden
Algorithmen für eine selbstorganisierende, selbstheilende und
autarke Multi-Hop-Netzwerkarchitektur entwickelt.
Da im Rahmen des Projektes die Entwicklung der
Software und der Hardware parallel erfolgen musste, waren
Tests im realen System erst zu einem sehr späten Zeitpunkt
des Projektes möglich. Eine sequenzielle Entwicklung von
Hardware und Software war aufgrund des engen Projektplans
nicht möglich. Aus diesem Grund mussten die Entwicklungsergebnisse zunächst in einer Simulationsumgebung erprobt
werden. Um möglichst große Netzwerke in möglichst kurzer
Zeit simulieren zu können, wurde ein sehr abstraktes
Simulationsmodell verwendet. Um den entwickelten
Algorithmus in der realen Systemumgebung nutzen zu
können, wurde für die Zielplattform ein Framework
entwickelt, dass die Spezifika der Simulationsumgebung in
der Realumgebung erhält.
In diesem Beitrag beschreiben wir den Algorithmus, die
Simulationsumgebung, das von uns entwickelte Framework
und die reale Umgebung, in welche wir die Tragfähigkeit
unseres Ansatzes verifiziert haben. Im nächsten Abschnitt
erfolgt zunächst eine kurze Beschreibung von typischen
Simulationsumgebungen für Sensornetzwerke. Im nachfolgenden Kapitel erläutern wir den von uns für das Solarflex
entwickelten Algorithmus. Anschließend wird die verwendete
Simulationsumgebung vorgestellt. Danach beschreiben wir
unser Framework zu Übertragung der Spezifika der
Simulationsumgebung in das reale System. Im Kapitel 4 wird
der Aufbau der Zielplattform erläutert und die im Rahmen des
Projekts verwendete Testanlage beschrieben. Abschließend
erfolgt eine zusammenfassende Auswertung der Ergebnisse.
EINLEITUNG
Die Entwicklung des in diesem Beitrag vorgestellten
Ansatzes erfolgt im Rahmen des Projektes Solarflex. Ziel des
Projektes war die Entwicklung einer auf Bluetooth[1]
basierende drahtlose Netzwerklösung zur Steuerung mittlerer
und großer Solarkraftwerke. Die Lösung soll als Ersatz für
eine existierende auf Ethernet-basierende Installation
eingesetzt werden. Ziel der Architektur war, dass die
II.
VERWANDTE ARBEITEN
Dem klassischen Ansatz folgend bieten viele
Betriebssysteme für Sensornetze die Möglichkeit als
Zielplattform einen Simulator zu spezifizieren. Anschließend
wird das System speziell für Simulationsumgebung erstellt,
45
d.h. es werden Spezifika der Simulationsumgebung in das
System integriert. Um eine Verwertbarkeit der Ergebnisse zu
gewährleisten, muss die Simulationsumgebung die reale Welt
möglichst genau darstellen, da das Betriebssystem
anschließend weitestgehend unverändert auf die Zielsystem
übertragen werden soll.
OMNeT++ [2] in Verbindung mit dem Castalia
Framework [3] bietet eine Simulationsumgebung für
Sensornetzwerke, welche viele Umweltparameter, wie z.B.
Sendestärke und Energieverbrauch mit einbezieht. Die
Simulation von großen Netzwerken mit mehreren hundert
Knoten ist jedoch sehr rechenintensive und die Einstellung der
Simulationsumgebung sehr aufwendig. Für TinyOS [4]
existiert TOSSIM [5], welches nicht die Mächtigkeit von
OMNET++ erreicht und damit eine abstraktere Abbildung der
realen Welt bedingt. Für Contiki [6] wurde der Simulator
COOJA [7] entwickelt. Speziell für Bluetooth-Netzwerke
existieren für den Simulator NS2 [8] Erweiterungen wie [9]
und [10].
Im Gegensatz zu dem von uns entwickelten Ansatz wird in
den genannten Arbeiten versucht, ein möglichst realistisches
Simulationsmodell zu verwenden. In allen Fällen können die
in der Simulation gewonnenen Ergebnisse nur bedingt auf das
reale System übertragen werden, so dass umfangreiche Tests
im Realsystem weiterhin notwendig sind und mitunter
Anpassungen am Algorithmus zu einem sehr späten
Entwicklungszeitpunkt erforderlich sind.
III.
KONZEPT
A. Netzwerkalgorithmus
Die Datenübertragung in einem Netzwerk kann in drei
Prozesse gegliedert werden:
1. Netformation – Dieser Prozess erstellt direkte
Verbindungen zwischen einzelnen Knoten.
2. Routing – Dieser Prozess stellt Informationen bereit,
wie im Netz bestimmte Zielknoten erreicht werden können.
3. Forwarding – Dieser Prozess führt die Weiterleitung
der Datenpakete auf den einzelnen Knoten des Netzes durch.
Jeder dieser Prozesse greift dabei auf die Ergebnisse seines
Vorgängerprozesses zu. Das Routing nutzt die vom
Netformation erzeugten Verbindungen. Das Forwarding trifft
Entscheidungen auf Grundlage der vom Routing
bereitgestellten Daten über die Pfade im Netzwerk.
In drahtgebundenen Netzen wird die Netformation bereits
implizit bei der Installation der Verkabelung durchgeführt.
Beim Einsatz einer Funktechnologie, die eine BroadcastPrimitive bereitstellt, wie z.B. IEEE802.15.4[11], wird häufig
auf Netformation verzichtet und sämtliche Datenpakete werden
per Broadcast versendet. Dafür werden aufwändigere Routingund Forwarding-Verfahren eingesetzt.
Im Fall von Bluetooth ist dieser Ansatz nicht effektiv.
Bluetooth arbeitet verbindungsorientiert und stellt keinen
Broadcast zur Datenübertragung bereit.
Das Projekt Solarflex (KF2123403DF9) wurde gefördert durch das
Bundesministerium für Wirtschaft und Technologie.
46
Wir entwickelten und implementierten einen NetformationAlgorithmus, der unter Beachtung der Bluetooth-Spezifikation
und der Einschränkungen der Hardware [12] alle Knoten in
einem Netz mit Baumtopologie verbindet. Der Algorithmus
besitzt keine Routing- oder Forwarding-Funktionalität. Diese
Funktionen müssen durch andere Systemkomponenten
realisiert werden.
Als Schnittstelle zwischen Algorithmus und Simulator bzw.
zum Framework wurde ein vereinfachtes Bluetooth-HCI, der
Schnittstelle zum Bluetooth-Baseband-Controller, gewählt. Die
Schnittstelle umfasst Primitive für
•
Suche nach Geräten in der Nachbarschaft,
•
Verbindungsverwaltung,
•
Versand und Empfang von Datenpaketen.
B. Simulator
Für die Simulation verwenden wir den von uns
entwickelten ereignisorientierte Simulator CSIM. Das
Simulationsmodell beinhaltet Gerätesuche, Verbindungsaufbau, Verbindungsabbau sowie Datenübertragung. Von
Verschlüsselung, Autorisierung, Authentifizierung und dem
Bluetooth-Protokollstapel wird vollständig abstrahiert.
Außerdem definiert das Modell eine sterile Umgebung. Es
existieren keine fremden Geräte im Modell. Der Zugriff auf die
Bluetooth-Schnittstelle ist exklusiv und muss nicht mit anderen
Diensten abgestimmt werden.
Durch dieses einfache Modell ist es möglich, den Aufbau
großer Netze mit bis zu 2000 Knoten in wenigen Minuten zu
simulieren.
C. Framework
Für die Abarbeitung des Netzwerkalgorithmus wurde für
die Zielplattform ein Framework entwickelt und implementiert.
Im Framework sind die folgenden Aufgaben implementiert:
1. Das Framework führt den Algorithmus synchronisiert
aus und verwaltet die Queue für eingehende Ereignisse, die der
Algorithmus abarbeitet, und die Queue für ausgehende
Kommandos, welche der Algorithmus aussendet.
2. Der Algorithmus greift beim Verbindungsaufbau,
beim Verbindungsabbau und bei der Datenübertragung
scheinbar direkt auf die Hardware zu und verwendet die
physische Verbindungen für seine Kontrollkanäle. Das
Framework bildet diese Verbindungen auf die BluetoothSerial-Port-Emulation ab, indem die Kommandos vom
Algorithmus in einer Adaptionsschicht abgearbeitet und die
entsprechenden Ereignisse ebenfalls in der Adaptionsschicht
generiert werden. Dadurch können die physischen
Verbindungen von allen Bluetooth-Diensten mitgenutzt
werden.
3. Das Framework filtert die Gerätesuche, so dass die
Umgebung so steril erscheint, wie das Simulationsmodell.
Dazu werden alle Geräte, die nicht am Netz teilnehmen,
während der Gerätesuche ignoriert.
4. Durch die Verwendung der Standardprotokolle
ermöglicht das Framework eine Zertifizierung des
Gesamtsystems.
5. Das Framework verwaltet die Logging- und
Statistikdaten, die das Framework und der Algorithmus
während der Ausführung generieren.
Somit ermöglicht das Framework die unveränderte
Übernahme der Algorithmus-Implementierung direkt aus der
Simulation.
IV.
UMSETZUNG
A. Sensorknoten
Die im Rahmen des Projekts entwickelten Netzknoten
verwenden einen ARM9-basierten Microcontroller von Atmel.
Die Netzknoten verfügen über eine Ethernet-Schnittstelle, eine
serielle Schnittstelle für Debug-Informationen und fünf LEDs
zur Statusanzeige. Das Betriebssystem basiert auf einem
eingebetteten Linux. Auf dem Sensorknoten findet das
Bluetooth-Modul BlueBear [14], auf dem der BluetoothController
BlueCore04-External
[15]
verbaut
wird,
Verwendung. Die Firmware des Controllers unterstützt die
Bluetooth-Spezifikation 2.1+EDR. Als Bluetooth-Stack wird
der bereits in Linux integrierte Bluetooth-StackBlueZ [16]
verwendet.
Das Framework wird als eigenständiger Prozess auf dem
Zielknoten ausgeführt. Zwischen je zwei Knoten, die durch das
Netformation verbunden wurden, wird eine Bluetooth-PANVerbindung für die Übertragung der Ethernet-Rahmen über
Bluetooth aufgebaut. Auf sämtlichen Knoten des Netzes
werden die Endpunkte der PAN-Verbindungen und die lokale
Ethernet-Schnittstelle in einer Software-Bridge registriert. Die
Software-Bridge führt das Routing und Forwarding der
Ethernet-Rahmen, wie in [17] beschrieben, durch. Dadurch
erscheinen die Ethernet-Schnittstellen der einzelnen Knoten als
Ports eines verteilten Ethernet-Switch.
B. Testanlage
Für die Tests des Frameworks und des Algorithmus auf der
Zielplattform wurde im Labor ein Testnetz bestehend aus 30
Knoten aufgebaut. Aufgrund der räumlichen Nähe der Knoten
sind
diese
am
Antennenausgang
mit
20-dBiDämpfungsgliedern versehen, um einen räumlichen Abstand
zu erzwingen. Die Knoten werden durch Netzgeräte mit
Energie versorgt. Ein Knoten des Netzwerkes ist mit einem
Test-LAN verbunden, die Ethernet-Schnittstellen der anderen
Knoten werden nicht verwendet. In diesem Testnetz können
die einzelnen Funktionen des Systems - wie z.B. Aufbauzeit
des Netzes, Reparaturzeit des Netzes, Latenz und Durchsatz
bei der Datenübertragung getestet und gemessen werden.
C. Feldtest
Für die Tests des Frameworks und des Algorithmus auf der
Zielplattform wurde im Labor ein Testnetz bestehend aus 30
Knoten aufgebaut. Aufgrund der räumlichen Nähe der Knoten
sind
diese
am
Antennenausgang
mit
20-dBiDämpfungsgliedern versehen, um einen räumlichen Abstand zu
erzwingen. Die Knoten werden durch Netzgeräte mit Energie
versorgt. Ein Knoten des Netzwerkes ist mit einem Test-LAN
verbunden, die Ethernet-Schnittstellen der anderen Knoten
werden nicht verwendet. In diesem Testnetz können die
einzelnen Funktionen des Systems - wie z.B. Aufbauzeit des
Netzes, Reparaturzeit des Netzes, Latenz und Durchsatz bei der
Datenübertragung getestet und gemessen werden.
Für Tests unter realen Bedingungen wurde in einer
Solaranlage die Ethernet-Verkabelung durch die beschriebene
Lösung ersetzt. Die Solaranlage umfasst 30 Wechselrichter, die
zuvor über einen Switch mit dem Firmennetz und dem Internet
verbunden waren. Auf 29 Wechselrichtern wurden die
Netzknoten installiert. Ein Wechselrichter blieb als Referenz
direkt mit dem Switch verbunden. Darüber hinaus wurde ein
Netzknoten als Datensenke mit dem Switch verbunden. Die
Energieversorgung der Netzknoten erfolgt über die
Wechselrichter.
V.
AUSWERZUNG UND ZUSAMMENFASSUNG
Die Auswertung der Simulations- und Testergebnisse
zeigte, dass das Verhalten der Netzknoten weitestgehend dem
Verhalten der Knoten in der Simulationsumgebung entspricht.
Der entwickelte Algorithmus konnte nahezu unverändert im
Realsystem verwendet werden. Allerdings zeigten die
Feldtests, dass die Dauer der Ereignisbehandlungsroutinen im
Simulator nicht mit Null abstrahiert werden kann. Diese führte
zu Fehlerfällen, welche Anpassungen des Algorithmus
erforderlich machten. Darüber hinaus war die echte Parallelität
im realen Sensornetz, die im Simulator nicht nachgestellt
wurde, Ursache für Probleme beim Auf- und Abbau von
Verbindungen.
Mit der erfolgreichen Übernahme des NetformationAlgorithmus aus der Simulationsumgebung in die Testanlage
konnte die Praktikabilität des vorgestellten Ansatzes gezeigt
werden. Im Feldtest aufgedeckte Probleme konnten leicht
behoben und könnten durch Erweiterung des Frameworks in
zukünftigen Entwicklungen ganz vermieden werden. Es
konnte nachgewiesen werden, dass ein sehr abstraktes
Simulationsmodell mit geeigneten Maßnahmen auf einer
realen Zielplattform nachgestellt werden kann. Damit können
im Simulator entwickelte Algorithmen direkt im Realsystem
verwendet und damit die Entwicklung von neuen Algorithmen
stark beschleunigt werden. Darüber hinaus wird eine parallel
Entwicklung von Hardware und Software möglich, was den
Entwicklungszyklus und damit die Time-to-Market eines
Produktes weiter verkürzt.
REFERENZEN
[1]
[2]
[3]
[4]
[5]
[6]
Specification of the Bluetooth System 2.1+EDR, Bluetooth SIG Std., Jul
2007.
A. Varga, The OMNeT++ Discrete Event Simulation System, the
European Simulation Multiconference, Prague, Czech Republic, 2001
Castalia. A simulator for WSNs. http://castalia.npc.nicta.com.au/.
P. Levis, Sam Madden, Joseph Polastre, Robert Szewczyk, Kamin
Whitehouse, Alec Woo, David Gay, Jason Hill, Matt Welsh, Eric
Brewer, David Culler. Tinyos: An operating system for wireless sensor
networks. In W. Weber, J. Rabaey, and E. Aarts, editors, Ambient
Intelligence. Springer-verlag, 2004.
P. Levis, N. Lee, M. Welsh, D. Culler. TOSSIM: Simulating large
wireless sensor networks of tinyos motes. In Proceedings of the First
ACM Conference on Embedded Networked Sensor Systems (SenSys
2003), 2003.
A. Dunkels, B. Gronvall, T. Voigt. Contiki - a lightweight and flexible
operating system for tiny networked sensors. Local Computer Networks,
Annual IEEE Conference on, 0:455–462, 2004.
47
[7]
Osterlind, F., Dunkels, A., Eriksson, J., Finne, N., Voigt. T. 2006. Crosslevel sensor network simulation with cooja. In Proceedings 2006 31st
IEEE Conference on Local Computer Networks, pages 641--648. IEEE.
[8] The Network Simulator - ns-2. http://www.isi.edu/nsnam/ns/index.html.
[9] G. Tan, Blueware: Bluetooth Simulator for NS, 2002. :MIT Lab.
Comput. Sci.
[10] UCBT - Bluetooth Extention for NS2 at the University of Cincinnati.
http://www.ececs.uc.edu/ cdmc/ucbt/ucbt.html
[11] IEEE 802.15.4, IEEE Standard for Information technology Telecommunications and information exchange between systems - Local
and metropolitan area networks - Specific requirements Part 15.4:
Wireless Medium Access Control (MAC) and Physical Layer (PHY)
48
[12]
[13]
[14]
[15]
[16]
[17]
Specifications for Low Rate Wireless Personal Area Networks (LRWPANs), Sep. 2006.
BlueCore Scatternet Support, CSR, 2005.
The
Bluetooth
Qualification
Program,
Bluetooth
SIG,
https://www.bluetooth.org/Technical/Qualification/home.htm
BlueBear-Datasheet, lesswire AG, 2009
BlueCore4-External Product Data Sheet, CSR, 2005
BlueZ, Bluetooth protocol stack for Linux. http://www.bluez.org/.
IEEE Standard for Local and Metropolitan Area Networks: Media
Access Control (MAC) Bridges, Jun 2004
On the Integration of Wireless Sensor Networks
and Smartphones in the Logistics Domain
Sebastian Zöller, Andreas Reinhardt, Heiko Guckes, Dieter Schuller, Ralf Steinmetz
Multimedia Communications Lab, Technische Universität Darmstadt
Rundeturmstr. 10, 64283 Darmstadt, Germany
Email: {sebastian.zoeller, andreas.reinhardt, heiko.guckes, dieter.schuller, ralf.steinmetz}@KOM.tu-darmstadt.de
Abstract—A promising application domain for wireless sensor
networks is their use for real-time monitoring in logistics transport processes. Through a constant monitoring of environmental
parameters which influence the condition of transported goods,
they allow for early transmission of alert messages in case of
critical situations. The stakeholders however only benefit from
alert messages if they are transmitted in a timely manner, so
that they can initiate countermeasures and adapt their logistics
processes accordingly. For the required connection between a
wireless sensor network and the decision makers’ systems, the
application of smartphones as bridging devices has been identified
as particularly promising. In this paper, we analyze possibilities
to interconnect wireless sensor networks with smartphones to
enable a long-range transmission of alert messages to decision
makers during transport processes. Based on our requirement
analyses, we suggest a particular promising connection concept
and provide a proof-of-concept implementation of this concept.
I. I NTRODUCTION
Wireless sensor network (WSN) technology provides a
promising means to realize real-time monitoring of transport
processes in the logistics domain. Wireless sensor nodes
(motes) can sense diverse parameters (e.g., shock, tilt, temperature, or humidity) related to the condition of transported
goods and thus determine whether critical thresholds have been
reached during a transport. In this case, alert messages can be
wirelessly propagated through the WSN and forwarded to a
logistics provider’s backend system by an appropriate gateway
node. Thus, based on the local detection of events during a
transport, warnings can be conveyed to responsible decision
makers, which can initiate countermeasures in time and adapt
their processes accordingly.
In this paper, we focus on the question how such alert
messages can be efficiently transferred from WSNs to the
responsible decision makers’ systems. We particularly address
WSN deployments in a container during road transportation
with trucks and investigate possibilities to realize the gateway
functionality between the WSN and end user systems in such
an application scenario. In [1], we have already analyzed
different possibilities in this context and identified the application of smartphones as particularly promising. Thus, in
this paper we investigate possibilities to integrate motes and
smartphones in a logistics context to realize a smartphonebased gateway between WSN and end users’ systems. The
contributions of this paper are the following: We shortly revisit
the application potential of WSN technology in the context
of logistics transport processes and present corresponding
requirements to be taken into account (Sec. II). We present
different possibilities to interconnect motes with smartphones
and based on different requirement analyses, we present our
concept (Sec. III). We discuss and analyze a prototypical
proof-of-concept implementation (Sec. IV), and conclude our
paper by presenting conclusions and future work (Sec. V).
II. WSN S IN L OGISTICS T RANSPORT P ROCESSES
Motes are able to monitor various environmental parameters
that may influence the condition of transported goods in real
time, e.g., temperature in the context of temperature-sensitive
transports, gas concentrations during the transport of animals,
or shake and tilt values when transporting shock-sensitive
goods. Thanks to their storage and processing capabilities, they
can locally evaluate the sampled data and wirelessly transmit
corresponding status and alert messages. This enables them
to provide a real-time monitoring of transport processes in
logistics, which can for example support Supply Chain Event
Management (SCEM), as we have pointed out in [1].
A major driving application for real-time monitoring of
goods is in the fields of cold chain transport processes and
food logistics (e.g., [2], [3]), and approaches to realize an
intelligent container, which incorporates such a monitoring
infrastructure [4]. In the work at hand, we focus on transport
processes in the context of road transportation with trucks
and thus on WSN deployments in a container on a truck
or a truck’s load area. For the general application of WSN
technology in such an application context, we have identified
four requirement categories to be considered (cf. [1]):
• Technological requirements comprise properties and constraints of the applied technology, e.g., energy constraints
of WSNs.
• Economical and organizational requirements include economical constraints and integration needs in existing infrastructure, e.g., cost-benefit ratio of WSN deployments.
• Regulatory requirements comprise constraints by law and
standardization bodies, e.g., usable frequency bands for
transmission.
• Logistics market specific requirements comprise properties and constraints of the application domain, e.g., the
prevailing massive cost pressure.
As different interdependencies between these requirement
categories exist, it is important that they are not considered
isolated from each other.
49
III. I NTERCONNECTING M OTES AND S MARTPHONES
For the realization of intelligent transportation systems, it
is essential to transmit alert messages from the WSN to the
decision makers’ systems with low delays. Only when event
notifications are transmitted in a timely manner, the application
potential of WSN technology in logistics transport processes,
and particularly early warnings of responsible decision makers,
can be fully exploited. To realize the required connection
between sensors and stakeholders, we have identified the usage
of smartphones as gateways for data transmission between
a WSN deployed in a container on a truck or a truck’s
load area as particularly promising in [1]. This leads to an
application scenario as depicted in Fig. 1. For this scenario, we
investigate possibilities to interconnect motes and smartphones
to realize the connection between WSN deployment and the
backend systems of decision makers. We therefore analyze
technological platforms that could be used in this context and
how they can be connected.
A. Choosing a Wireless Sensor Platform and a Smartphone
For the selection of an adequate wireless sensor platform
and a smartphone, we have deduced specific requirements
based on the requirement categories presented in Sec. II. A
total number of ten requirements have been determined for
the selection of a wireless sensor platform:
1) Adequate power consumption Motes are supposed to operate for a long time without attendance. Because of their
restricted energy budget resulting from battery-powered
operation, a low power consumption is essential.
2) Sufficient radio communication range To provide communication between the individual motes within a WSN,
their transmission range must be sufficient to reach
at least one neighboring mote, even when transported
goods negatively impact their transmission range.
3) Compliance to law and standards To be able to operate
a WSN deployed in a container on a truck or in a truck’s
load area during an international transport process, adherence to national rules has to be guaranteed.
4) Ease of software development To allow for efficient
software development with reduced development times,
well-established solutions are preferable in this context,
e.g., already available, reusable, and well-tested code.
Fig. 1.
50
The investigated application scenario
5) Adequate interoperability and extendability To be able
to adapt a WSN to changes in the application scenario,
like the need to measure more or other environmental
parameters or to extend the deployed WSN with new
mote platforms, sufficient interoperability and extensibility options have to be provided.
6) Sufficient scaleability and flexibility in topology Because
motes are prone to failures, e.g., due to battery depletion
or physical damage, sufficient scaleability and flexibility
is required to cope with such failures.
7) Adequate price As the logistics domain faces a huge
cost pressure, expenses need to be as low as possible
to provide a sufficient return on investment for a WSN
deployment in this context.
8) Sufficient data security level The data transmitted
through the WSN is usually sensitive data from different
companies, which necessitates a sufficient level of data
security to guarantee that company secrets are protected.
9) Small size and weight To save valuable space in the
container and avoid a negative impact on the truck’s fuel
consumption, the motes deployed should be as small and
lightweight as possible.
10) Adequate wake-up time The wake-up time of a mote
also influences its power consumption, as longer sleep
cycles can be achieved with shorter wake-up times,
which reduces the overall energy consumption of a mote.
For the selection of a WSN platform based on the above
mentioned requirements, we conducted a market analysis and
compared 22 current mote platforms. Based on this comparison, we came to the decision that the TelosB platform [5]
best fits our needs. As current smartphones usually provide
sufficient processing and storage capabilities for our needs,
we have not taken these into account for selecting a suitable
smartphone platform, but identified a different set of four
requirements, particular important in our application scenario:
1) High current and predicted market share For a solution with current and future relevance, the smartphone
platform used must exhibit a high current and predicted
market share to provide a sufficient market penetration.
2) Sufficient support of different communication standards
To be able to interconnect a smartphone and a mote
sufficient support of different communication standards
is required, e.g., the standard Bluetooth profiles to enable
communication with other standard Bluetooth devices.
3) Hardware expandability To support even connection
concepts to motes which require additional hardware,
the opportunity to attach additional hardware to the
smartphone should be provided.
4) Geolocation support To enrich the information transferred by the smartphone and basically enable locationbased services, the smartphone should provide a possibility to determine its current geographic location.
Based on these requirements, we compared currently offered
platforms and decided that an Android-based smartphone best
fits our needs, specifically we used a Google Nexus One [6].
B. Connecting a Wireless Sensor Platform to a Smartphone
One design possibility for a connection between the chosen
TelosB mote platform and the chosen smartphone platform
is to extend the smartphone in a way that enables IEEE
802.15.4 wireless communication as shown in Figure 2. This
requires adding additional hardware to the smartphone to
provide support for IEEE 802.15.4 and a corresponding software support for the additional hardware. Usually, the latter
requires “rooting” the smartphone. A second design option
is to extend the TelosB in a way that enables Bluetooth
communication as shown in Figure 3. A third option is to
use a device with Bluetooth and IEEE 802.15.4 radio as a
bridge between the Android phone and the TelosB mote (cf.
Fig. 4). The device could be deployed in the driver’s cabin
and thus powered directly by the truck. Therefore, this type
of gateway device would not have any constraints with regard
to its power consumption, and it would also allow the usage
of different Android smartphones due to its generic Bluetooth
communication interface.
To assist in the selection between the presented connection
concepts, several application-specific requirements have to be
considered. In this context, we have identified the following
five essential requirements:
1) Reusable, flexible, fault-tolerant, and interoperable solution Since hardware and specifications are prone to
constant change, the solution should not be bound to an
individual device, but rather support a whole category
of devices, like all Android devices, and should be not
prone to errors.
2) Only unobtrusive modifications to the existing software
platform (i.e., no rooting of the phone) Because rooting
the smartphone or heavy kernel modifications might
open up security risks or restrict interoperabilty or
porting of the solution, such modifications should not
be required.
3) Low costs Due to the huge cost pressure prevailing in the
logistics domain, expenses and initial investment costs
should be minimized.
4) No negative influence on the existing hardware A good
solution should not negatively influence the employed
smartphone or motes, e.g., reduce their lifetime by
significantly increased power consumption.
5) Low and easy maintenance The solution should require
only sufficiently low maintenance cycles and should be
easily replaceable in case of failure.
Based on these requirements, and some additional real-life
tests (a set of experiments was conducted on a truck’s load
area as shown in Fig. 5), we propose a connection concept
employing a wireless bridge between mote and smartphone as
depicted in Fig. 4.
Fig. 5.
Experimental setup in the conducted field test
IV. P ROOF - OF -C ONCEPT I MPLEMENTATION
Fig. 2.
Connection using a rooted smartphone with additional hardware
Fig. 3. Connection using a mote extension via UART and a Bluetooth module
Fig. 4.
Connection using a bridging device between smartphone and mote
We have realized the connection concept depicted in Fig.
4 in a proof-of-concept implementation. As wireless bridge
between the chosen TelosB and the Google Nexus One
smartphone we have decided to use a modified TelosB mote.
This results in a prototypical setup as depicted in Fig. 6.
In order to provide Bluetooth functionality to the bridging
TelosB mote, we used a Bluetooth 2.0 to UART adapter from
SURE Electronics1 [7] and soldered it to the 10 pin extension
connector of the TelosB mote. To test the setup and implementation we wrote an Android Activity, which establishes a
connection to the mote and displays various status information.
On the TelosB, we deployed an application, which sends an
increasing counter wrapped in an Active Message over UART
1 This adapter has been chosen for price and availability reasons. Aiming
at a prototypical proof-of-concept implementation, we considered the security
drawbacks inherent to Bluetooth 2.0 as negligible in our context.
51
Fig. 6. Prototype concept for mote and smartphone integration with an
intermediated bridge
to the connected Bluetooth adapter, which afterwards relays
it via Bluetooth to the Android smartphone. After activating Bluetooth on the smartphone and binding the Bluetooth
Adapter, the Android Activity was started. After the manual
connection and pairing with the SURE adapter, the Activity
establishes a connection between the Nexus One smartphone
and the TelosB bridging mote. From this point, status messages
with the increasing counter value are transmitted from the
TelosB mote via the Bluetooth adapter to the Google Nexus
One smartphone, which is shown in Fig. 7. Additionally,
we sent messages from the smartphone to the mote and
remotely controlled the TelosB’s LEDs. Unfortunately, the
TelosB platform uses the same communication port for both
the CC2420 radio and its extension port. Thus, we were not
able to use both the TelosB radio and the Bluetooth adapter at
the same time, but had to make use of resource arbitration in
the TinyOS application in order to switch between those two.
V. C ONCLUSIONS AND O UTLOOK
Wireless sensor networks provide a promising means to
enable real-time monitoring of logistics transport processes.
Nevertheless, the monitored data and corresponding alert
messages have to be transmitted to the responsible decision
makers quickly. For this purpose, a long-range connection
between wireless sensor network and end users’ backend
systems is needed. To provide such a connection, the usage
of smartphones has been proposed as particularly promising.
Fig. 7.
52
Proof-of-concept implementation
Thus, in this paper we have analyzed different possibilities
to interconnect wireless sensor nodes and smartphones in the
context of transport processes employing road transportation
with trucks. On the basis of different requirement analyses,
we have proposed one particular connection concept using
a dedicated wireless bridge device between wireless sensor
network and smartphone and provided a proof-of-concept
implementation for this concept.
As we are currently not able to automatically switch between the communication channel with the smartphone and
the communication channel with the wireless sensor network
on the bridging device in our actual implemented prototype
solution, we plan to test our solution on other hardware
platforms. In the work at hand, we focused on the integration of wireless sensor networks and smartphones. Thus, to
really provide the whole connection between a wireless sensor
network and the end users’ systems, possibilities to efficiently
transmit data from the smartphone to those systems have to be
investigated. Furthermore, security aspects were not part of our
investigation. Hence, necessary and demanded security levels
of the different stakeholders in the envisioned application
scenario of road transportation have to be examined and
possibilities to realize these have to be researched.
ACKNOWLEDGMENT
This work was partially funded by the German Ministry of
Education and Research in the context of the research project
ADiWa (www.adiwa.net).
R EFERENCES
[1] S. Zöller, A. Reinhardt, M. Meyer, and R. Steinmetz, “Deployment of
Wireless Sensor Networks in Logistics - Potential, Requirements, and a
Testbed,” in Proceedings of the 9th GI/ITG KuVS Fachgespräch Drahtlose
Sensornetze, R. Kolla, Ed. Julius-Maximilians-Universität Würzburg,
Sep 2010, pp. 67–70.
[2] L. Ruiz-Garcia, P. Barreiro, J. Rodriguez-Bermejo, and J. I. Robla,
“Review. Monitoring the intermodal, refrigerated transport of fruit using
sensor networks,” Spanish Journal of Agricultural Research, vol. 5, no. 2,
pp. 142–156, 2007.
[3] R. Jedermann and W. Lang, “The Minimum Number of Sensors Interpolation of Spatial Temperature Profiles in Chilled Transports,”
in Proceedings of the 6th European Conference on Wireless Sensor
Networks, 2009, pp. 232–246.
[4] R. Jedermann, J. D. Gehrke, M. Lorenz, O. Herzog, and W. Lang,
“Realisierung lokaler Selbststeuerung in Echtzeit: Der Übergang zum
intelligenten Container,” in Wissenschaft und Praxis im Dialog, H.-C.
Pfohl and T. Wimmer, Eds. Hamburg: Deutscher Verkehrs-Verlag, 2006,
pp. 145–166.
[5] MEMSIC
Inc.,
“TelosB
Mote
Platform,”
Online:
http://memsic.com/support/documentation/wireless-sensornetworks/category/7-datasheets.html?download=152:telosb (last access:
July, 20 2011), 2006.
[6] Google,
“Nexus
One
–
Google
Phone
Gallery,”
Online: http://www.google.com/phone/detail/nexus-one (last access:
July, 20 2011), 2011.
[7] SURE Electronics, “Bluetooth Serial Converter UART Interface 9600bps
User’s Guide,” Online: http://www.sure-electronics.net/download/GPGC021 Ver1.0 EN.pdf (last access: July, 20 2011), 2008.
Implementation and simulation of an energy-efficient
cluster-based wireless sensor network
V. Delport, M. Gessner, T. D. Grossman, A. Singer
Chair of radio and communication technology,
Department of Electrical and Information Engineering, University of Applied Sciences Mittweida,
Technikumplatz 17, 09648 Mittweida, Germany
{volker.delport, gessner, grossman, asinger}@hs-mittweida.de
Abstract—This paper focuses on reducing power consumption in
cluster-based wireless sensor networks. For this purpose we
proposed a new energy-efficient dynamic clustering technique for
wireless sensor networks in [1]. In order to improve the proposed
clustering technique under practical circumstances an energyefficient cluster-based wireless sensor network has been
implemented. The numerical simulations by using our simulation
platform Virtual Wireless Adhoc Networks (ViWiAN) shows that
the proposed dynamic clustering technique is suitable for
increasing the lifetime of the implemented cluster-based wireless
sensor network.
I.
INTRODUCTION
A wireless sensor network generally consists of a large
number of small, low-power sensor nodes with wireless
communication and limited computation capabilities. Sensor
nodes usually operate with limited battery power. In most
applications it may be inconvenient, and in some applications it
is impossible to recharge the node batteries. In order to
maximize the lifetime of the wireless sensor network, both the
node hardware and the communication protocols must be
designed to be energy-efficient.
In terms of the energy-efficient communication in wireless
sensor networks, a cluster-based network organization is
generally considered to be the most favorable approach
(Fig. 1). In a cluster-based wireless sensor network, the sensor
nodes are organized into clusters.
Figure 1.
Cluster-based wireless sensor network
Each cluster has a cluster head, which is one of its sensor
nodes. The cluster heads collect sensor data from their
corresponding cluster nodes and transfer the aggregated data to
a central sink or a base station, respectively.
Obviously energy can be saved if an optimal clustering
solution of the cluster-based wireless sensor network can be
found. Furthermore, since the cluster heads dissipate much
more energy than the ordinary sensor nodes, it makes sense to
rotate the role of the cluster heads (dynamic clustering).
Therefore, the authors introduced a new energy-efficient
dynamic clustering technique for wireless sensor networks in
[1].
II.
IMPLEMENTATION
In order to validate how much energy can be conserved by
employing the proposed energy-efficient dynamic clustering
technique on wireless sensor networks under practical
circumstances we implemented a real cluster-based wireless
sensor network of thirty hardware sensor nodes at our
department.
A. Sensor node hardware
For the implementation we used sensor nodes, which were
manufactured by Texas Instruments and based on the systemon-chip solution CC2430, that combines an 8051
microcontroller unit (128 KB flash memory, 8 KB RAM, 32
MHz system clock) with an integrated 2.4 GHz IEEE 802.15.4
compliant radio transceiver CC2420. The radio transceiver is
especially designed for low-power wireless applications. It
transmits within the industrial, scientific and medical (ISM)
radio bands, i.e. between 2400 and 2483.5 MHz and has a
typical receiver sensitivity of -92 dBm. Figure 2 shows the
sensor node hardware which is used.
Figure 2. Sensor node hardware based on the system-on-chip CC2430
53
B. Network structure and addressing
Obviously, a cluster-based wireless sensor network can be
considered as a collection of independently operating star
networks or clusters, respectively. All sensor nodes in the
cluster-based wireless sensor network communicate at the
same frequency within the ISM frequency bands.
After the first sensor node device is activated, it can
establish its own cluster and become the PAN coordinator as
specified in the IEEE 802.15.4 standard [2], or the cluster head,
respectively. Therefore, we use the 16-bit PAN identifier
specified in the IEEE 802.15.4 standard as the cluster
identifier. A cluster identifier is not currently used by any other
clusters within the radio sphere of influence. Once the cluster
identifier is chosen, the cluster head allows other sensor node
devices to join its cluster. The 16-bit short address specified in
the IEEE 802.15.4 standard is used as the sensor node identifier
for addressing a sensor node within the cluster. Since each
cluster head works as a PAN coordinator, the communication
within a cluster can be handled without needing the
transmission of the cluster head address. The chosen sensor
node hardware includes support for address recognition.
Therefore, energy-efficient addressing can be achieved.
C. Multiple Access Mechanism
We developed a special time division multiple access
(TDMA) mechanism that avoids collisions and is especially for
the target application much more energy-efficient than the
multiple access methods which are specified in the IEEE
802.15.4 standard, like carrier sense multiple access with
collision avoidance (CSMA-CA) [2].
The developed TDMA mechanism operates without a
central time synchronization of the sensor nodes within the
cluster. Each cluster head builds a TDMA frame that is divided
into five parts. Figure 3 shows the message sequence chart of
the developed and implemented TDMA frame.
During the pre-node access period (Pre-NAP) each cluster
head awakes, gets ready-to-receive, captures its own sensor
data (temperature, battery voltage), and calculates the new
TDMA frame of its cluster. In Addition, the pre-node access
period is used to compensate clock variations in order to ensure
that the cluster head is ready-to-receive before the first sensor
node sends data.
During the node access period (NAP) all sensor nodes
within a cluster send their data to the cluster head one by one
according to their sensor node identifiers. The cluster head
acknowledges the successful reception by sending an
acknowledge frame to each sensor node. The acknowledge
frame is a special defined medium access control (MAC)
command that contains the sleeping time for each sensor node
and the received signal strength indication (RSSI) of the
recently received sensor node frame. Each sensor node uses
this echoed RSSI in order to reduce or increase its transmitting
power, if necessary.
During the post-node access period (Post-NAP) the cluster
head could aggregate and compress the data of its cluster for
sending to the base station.
54
Figure 3. TDMA frame message sequence chart
In our special implementation no data compression is
provided. However, we use this time period in order to
compensate clock variations, as in the pre-node access period.
During the access free period (AFP) each cluster head
sends the collected data of its cluster to the base station. The
base station acknowledges the reception by sending a
command to each cluster head. The acknowledge command
depends on the following two possible cases. In the case that
all data of a cluster has been correctly received, the
corresponding cluster head should go into the power down
mode until the next TDMA frame starts (inactive period). In
the case that data of at least one sensor node are not correctly
received the corresponding cluster head should skip the
inactive period and extend the access free period in order to
catch the lost sensor node. In the seldom case that the base
station is not able to send the acknowledge commands to the
cluster heads, because of an error inside the base station or a
power blackout, the cluster heads start the inactive period
autonomously. During the inactive period, meaning most of the
time, the cluster heads are in the power down mode and
conserve energy.
D. Indoor Test bed
Based on the TDMA mechanism a cluster-based wireless
sensor network has been implemented as an indoor test bed for
a long-term test. Thirty CC2430-sensor nodes supplied by two
commercially available Ni-MH accumulators totaling nearly
2600 mAh per sensor node have been arranged in the space of
three rooms of the professorship of radio and communication
technology at the University of Applied Sciences Mittweida. In
order to ensure a completely dynamic clustering of the test bed
the sensor nodes were arranged in ways that a sensor node is
able to reach every other sensor node and the base station of
the test bed without needing any multi hop communications.
The communication protocols, running on the sensor nodes
over the IEEE 802.15.4 layers, have been developed and
programmed without using an operation system like TinyOS or
anything similar.
On the base station server, a relational MS-SQL database
runs that stores all incoming data for analysis during and after
the long-term test. The centralized dynamic clustering of the
test bed is performed on the base station server, too. In order to
execute the dynamic clustering by means of the approach
introduced in [1] the current values of the electrical charge of
the sensor nodes batteries are needed. But, the measurement of
the electrical charge of a sensor node battery without
discharging the battery is impossible. However, the current
sensor node battery voltage can be measured, since each sensor
node has got a battery monitor and is able to transmit its
current battery voltage value into the sensor network.
Therefore, we decided to activate a new clustering of the sensor
network if the battery voltage of at least one of the current
cluster heads is below the weighted battery voltage average of
the whole sensor network. Furthermore, the cluster head
selection is based on the current sensor node battery voltages,
too.
For the long-term test of the indoor test bed the thirty
sensor nodes have been programmed to transmit their payload,
i.e. the temperature value and the battery voltage every ten
seconds to the base station server, i.e. 8640 times daily. Table
I shows some of the essential parameters which have been
defined for the long-term test of the indoor test bed.
TABLE I.
INDOOR TEST BED PARAMETERS
Parameter
Value
Communication cycle time
10 s
Pre-node access period
10 ms
Time interval between two sensor node accesses
5 ms
Post-node access period
10 ms
Access free period
35 ms
Number of clusters
3
Weight of the average battery voltage for
activating a new clustering of the test bed
0,99
III.
SIMULATION
A. Simulation Platform ViWiAN
The indoor test bed is one of the components of a complex
simulation platform named Virtual Wireless Adhoc Networks
(ViWiAN) that has been developed at our professorship since
2009. In addition to the indoor test bed ViWiAN also consists
of a software suite that currently contains the simulation
software ViWiAN Simulator, the base station software
ViWiAN Base Node and the web portal ViWiAN Web. The
web portal has been especially developed for the purpose of
showcasing the work of the indoor test bed for the staff and the
students of the University of Applied Sciences Mittweida via
intranet. All mentioned software components are connected
with a relational MS-SQL database that stores data which
could come from either the indoor test bed or a wireless
network simulation that is carried out by ViWiAN Simulator.
Figure 4. Screenshot of the simulation software ViWiAN Simulator
The simulation software ViWiAN simulator allows a threedimensional simulation of a wireless sensor network and its
environment. Figure 4 shows a screenshot of ViWiAN
Simulator with the implemented indoor test bed.
B. Simulation model
In order to achieve a model that simulates the implemented
wireless sensor network as accurately as possible, we decided
to calculate the typical energy consumption of a sensor node
and a cluster head based on their real, meaning measured
consumption of current within the time of one communication
cycle. Based on the measured electrical voltage drop across a
defined resistor of 4.58 Ω that is connected between the battery
and the sensor node the consumption of current of each time
period can be calculated. Consequently, by involving the
measured time the electrical discharge of the sensor node
battery is computable. Figure 5 shows the typical voltage drop
curve of the implemented sensor node protocol versus its
activity time which has been measured by a digital oscilloscope
(1: awakening, 2: transmitting data to the cluster head and
measuring sensor data of the following cycle, 3: changing from
transmitting into receiving, 4: receiving the acknowledge frame
from the cluster head, 5: going into the power down mode).
With the maximum transmission power of 0 dBm, or 1 mW
respectively, a sensor node consumes about 56 mAms within
the whole activity time of one communication cycle, i.e. within
2 milliseconds.
Figure 5. Voltage drop curve within the sensor node activity time
55
In this manner it is possible to roughly estimate the current
battery voltage of a sensor node by means of the calculated
electrical discharge of the sensor node battery based on the
specific sensor node protocols.
Figure 6. Voltage drop curve within the cluster head activity time
Figure 6 shows the typical voltage drop curve of the
implemented cluster head protocol versus the activity time
(1: pre-node access period, 2: node access period, 3: post-node
access period, 4: access free period, 5: sending a beacon frame,
waiting for association requests of the sensor nodes, and going
into the power down mode). The activity time of a cluster head
depends especially on the number of sensor nodes within its
cluster. In the case that a cluster head has got nine sensor nodes
within its cluster, as shown in Figure 6, it requires about
3224 mAms within its activity time of about 105 milliseconds.
In the inactive period of the TDMA frame, meaning in most
of the communication cycle time all sensor nodes are in the
power down mode and have got about 139 µA consumption of
current. Therefore, sensor nodes need nearly 1390 mAms or
cluster heads need about 1373 mAms within the inactive
period. During the communication cycle time of ten seconds a
cluster head consumes on average nearly three times more
energy than a sensor node.
Figure 5 shows that the consumption of current of a sensor
node that transmits data (period 2) with the maximum
transmission power of 0 dBm, or 1 mW respectively, is not
much higher than the consumption of current that is required
by the sensor node for data receiving (period 4). Furthermore,
compared with the entire communication cycle time the sensor
node transmission time is a very small period. Consequently,
the influence of an optimal clustering of the wireless sensor
network in regard to the distances between cluster heads and
sensor nodes or between the cluster heads and the base station
is less relevant to the energy efficiency than is popularly
assumed.
For the simulation of the implemented wireless sensor
network the current battery voltage has to relate to the
electrical discharge of the sensor node battery. Therefore, we
let a sensor node transmit its current battery voltage every
second until its battery was completely discharged in order to
get a typical voltage vs. discharge curve of the used
accumulators. Since the sensor node was continuously
activated its consumption of current was on average nearly 30
mA. Afterwards, the measured battery voltage vs. discharge
curve was approximated piecewise by using a number of
polynomial functions. These polynomial functions were
implemented into the simulation software ViWiAN Simulator.
56
C. Simulation Results
As mentioned before, the essential purpose of our research
is to maximize the lifetime of wireless sensor networks. But,
obviously the definition of the lifetime depends on the
application service which is provided by the sensor network. In
the current project we have concentrated on applications in
which it is necessary for all sensor nodes to stay alive as long
as possible. Some examples for these application scenarios,
where the service quality decreases considerably as soon as the
first sensor node dies, are fire or housebreaking detection. We
want in particular find out how much the lifetime of all sensor
nodes of a cluster-based wireless sensor network could be
extended by means of the dynamic clustering approach
introduced in [1].
The simulation of the implemented indoor test bed by use
of the simulation software ViWiAN Simulator results in the
following forecasts. Without the dynamic clustering of the
indoor test bed the first sensor node will fail after
approximately 37 days. By means of the dynamic clustering
approach introduced in [1] all sensor nodes will stay alive for
approximately 174 days. According to this forecast the lifetime
of all sensor nodes of the indoor test bed could be increased
nearly fivefold if dynamic clustering is applied. Furthermore,
within these 174 days 12 of the 30 sensor nodes, i.e. 40 percent
of the sensor nodes will fail without applying the dynamic
clustering.
IV. CONCLUSIONS AND FUTURE WORK
A cluster-based energy-efficient wireless sensor network
has been developed and implemented into an indoor test bed of
thirty sensor nodes. Since its launch the indoor test bed has
been working well. The simulation of the indoor test bed
resulted in a nearly fivefold increase of the lifetime of all
sensor nodes by use of a dynamic instead of a static clustering
approach. By means of the implemented indoor test bed we are
looking to improve the dynamic clustering approach by
calculating the sensor node distances based on the received
signal strength indications (RSSI) instead of the sensor node
positions. Furthermore, we are in the process of building an
outdoor test bed at our department.
ACKNOWLEDGMENT
This research is supported by the Ministry for Science and
Culture of the Free State of Saxony in Germany.
REFERENCES
[1]
[2]
V. Delport, M. Gessner, T. D. Grossmann, A. Singer, Deterministic
technique for energy-efficient centralized clustering of wireless sensor
networks, Proceedings 9. Fachgespräch „Sensornetze“ der GI/ITG
Fachgruppe Kommunikation und Verteilte Systeme, 16. - 17. September
2010, Universität Würzburg, S. 75-78.
IEEE Standard 802.15.4-2006, Wireless Medium Access Control
(MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless
Personal Area Networks (WPANs)
Utilizing Voltage Decline for Reaching Lifetime
Goals
André Sieber, Jörg Nolte
Distributed Systems/Operating Systems group, BTU Cottbus
Cottbus, Germany
as, [email protected]
I. I NTRODUCTION
Energy is a mayor concern in wireless sensor networks.
Sensor nodes should run for years with a limited energy budget
providing a high quality of service.
To reach these lifetimes traditional power management
focuses on saving energy and thus extending the lifetime
of sensor nodes. But it is essential that not only a sensor
network reaches the highest possible lifetime, it should also
reach a certain predefined lifetime goal. Especially if nodes
are deployed in harsh environments and can not be reached,
it is necessary that on the one hand no nodes fail early to
guarantee the fulfillment of the network assignment and on
the other hand the available energy is used completely to have
a high application quality. To implement these requirements
the power management not only needs to save energy but
to control the power consumption according to the available
energy. The consequence of controlling the power consumption of the system is that reaching the lifetime goal becomes
more important than a constant application quality [1]. This
ultimately leeds to the sacrifice of certain application work to
system runtime.
Typical sensor nodes are powered by alkaline or lithium
batteries. But these and other battery technologies suffer
from non-linear behavior, e.g. rate capacity, recovery effects
and their strong dependence from environment conditions,
especially temperature [2]. A sensor network performing environmental observations in a sense and send scheme is fully
exposed to these conditions and can suffer from low temperatures accompanied by voltage drops. This can lead to failures
since the voltage could be to low to power sensors or the
whole, because their cutoff-voltage is underrun. Additionally,
the actual delivered capacity depends on the load applied to
A
B
C
voltage
Abstract—The battery dictates the lifetime of many embedded
systems, especially wireless sensor networks. This makes it
necessary to deal with batterie management. In this paper we
present an approach for a battery management which enables a
sensor node to reach a defined lifetime. The presented approach
gives feedback to an energy manager if the current power
consumption must be lowered or can be increased to reach the
runtime goal. In contrast to other systems the battery is handled
as black box to keep the system independent from the battery
type and brand. First experiments yield promising results of this
concept to reach a certain lifetime goal while maintaining a high
application quality.
system cutoff voltage
battery cutoff voltage
time
Fig. 1. Stages of battery discharge (A) fast drop to nominal voltage (B) long
nearly linear curve (C) fast drop to battery cutoff voltage
the battery and can differ significantly from the manufacture
specification.
For most battery types the discharge can be divided into
three phases (figure 1). In phases A and C the voltage drops
at high rates: in A it drops near the battery nominal voltage
and in C to the battery cutoff voltage. Furthermore the battery
cutoff-voltage may be lower than the system cutoff-voltage
resulting in energy that could not be used.
Duty cycling is used by most sensor nodes to save energy by
turning off unused parts of the sensor node and using sleep
modes of the micro controller [3], which results in a pulse
discharge of the battery. On the one hand this behavior opens
the opportunity of using the recovery effect of certain battery
technologies, which, on the other hand, makes a prediction
of the available energy and thus the runtime more complex.
A battery management could be able profit from the recovery
effect, but due to it complexity maybe only implicitly.
The rest of the paper is structured as follows. In section
II the problem is described. In section III the related work is
discussed. Section IV gives a short overview over the ideas
of the feedback based battery management. Early evaluation
results are presented in section V. Finally, a conclusion is given
in section VI.
II. P ROBLEM D ISCRIPTION
The lifetime of the sensor node is divided into T discrete
timeframes, where timeframe T − 1 is the target whose end
must be reached. To reach such a certain predefined lifetime
goal while providing a high quality of service it is essential
to manage the power consumption. As consequence the power
manager needs information about the remaining energy E(t)
at a specific point in time t. The energy which can be
57
spent in each following discrete timeframe is E(t)/(T − t).
However, retrieving information about the state-of-charge and
thus available energy of a battery is a nontrivial problem.
Controller
Configuration
Actor
Battery Voltage
Observer
Feedback
Abstract Battery
Model
Feedback
Power
Manager
Application
Vm(t)
III. R ELATED W ORK
There are three kinds of approaches to estimate the stateof-charge of a battery .
Hardware based approaches like fuel gauges [4] or smart
battery monitors [5] give accurate information of energy left
in batteries but increase the system complexity and the unit
costs in turn. Additionally, they consume energy, which can
have an impact because the sleep modes of modern ultra-lowpower microcontrollers consume in the magnitude of few µA
[6].
Complex battery models [7], [8] are also very accurate but
suffer from high complexity and computation costs, which
makes them unusable for deeply embedded systems. They
also rely on complex parameters which had to be retrieved
via experiments and thus depend on certain batteries.
Lookup table based approaches [9] plot actual battery
discharge charts and store them on the node to estimate the
remaining charge by reading the recorded state-of-charge using
the current voltage. Despite the simplicity of this approach, it
suffers from the variation between the batteries not only in
technology, type and brand, but also in single charges. This
problem occurred in [9] and lead to early node failures which
persisted until the model was adopted to the new discharge
behavior.
While the empiric approach to reach a certain lifetime is to
include a high enough energy overhead, approaches targeting
explicit lifetime goals are few [9], [10].
In [9] different levels are defined, which differ in application
and energy footprints. Depending on the estimated remaining
energy the levels were chosen which allow the node to
reach the lifetime goal while providing the highest possible
application quality. However, the energy footprint of each level
must be obtained in advance.
The terms voltage budget and target oriented energy management in the context of sensor networks were introduced
in [10]. In this approach, the system and its parts are considered as control loops. The battery management loop aims
to force the actual voltage to a target curve computed through
piecewise linearization. To do so, sleep phases are inserted via
duty cycling until the actual voltage meets the targeted one.
The duration of the sleep phases were not computed on the
sensor node but as optimization problem on a connected PC
and sent to the node.
Our approach was inspired by [10], but in contrast uses
feedback to inform the power manager that an adjustment of
the consumption is necessary. Additionally, due to the low
complexity of the approach it runs on the sensor node itself.
The linearization only adopts when certain boundaries are
violated in order to keep the feedback and thus the energy
consumption as stable as possible.
58
Voltage Sensor
Battery
Power Consumption
Fig. 2. Control loop of the battery management system including power
management and application
IV. F EEDBACK BASED BATTERY M ANAGMENT
To overcome the difficulties of determining E(t), our approach uses the current measured voltage Vm (t) as controlling
value. Information about the voltage is available on almost any
sensor nodes with little or no hardware overhead. Although
there is only a poor correlation between voltage and available
energy, it is possible to use the voltage decline as information
about the battery state.
Figure 2 shows the control loop, were the battery management acts as the controller. A significant difference between
the assumed voltage Vref and the measured voltage Vm leads
to feedback to the Power Manager (PM) which than changes
the consumption of the application. This leads to a change in
the voltage decline on which the system reacts.
The battery management consist of two main parts, the
Battery Voltage Observer (BVO) and the Abstract Battery
Model (ABM). Only the BVO is mandatory, it either gives
feedback directly or returns the whole internal state to be
used by the ABM. If a certain behavior of the battery is
known, the feedback can be influenced by the ABM. The
PM which controls the power consumption of the system
and application according to the feedback is not part of the
battery management and can have different characteristics, eg.
a simple change of the duty cycle or more complex behavior.
A. The Battery Voltage Observer
The BVO monitors the measurred voltage Vm (t) and compares it with the computed reference voltage Vref (t). If the
upper U (t) or lower L(t) boundaries, which mark the tolerated
difference between the assumed and the measured voltage, are
breached, the BVO gives feedback. These are calculated as
fraction of the remaining voltage budget, where B+ and B−
are predefined constants and Vref (0) = Vm (0):
U (t) = Vref (t) + (Vref (t) − Vcutof f ) ∗ B+
L(t) = Vref (t) − (Vref (t) − Vcutof f ) ∗ B−
In each timeframe the voltage is assumed to be ∆V (t)
lower than in the timeframe before, where ∆V (t) is computed
by splitting the remaining voltage budget over the remaining
timeframes. ∆V (t) is only recomputed if U (t) or L(t) are
breached:

∆V (t)
∆V (t + 1) = Vm (t) − Vcutof f

T −t
L(t) < Vm (t) < U (t)
else
•
U(t)
voltage
Vref(t)
•
Vm(t)
L(t)
time
•
Fig. 3. System behavior with boundary violation resulting in updating ∆V (t)
and adoption of the power consumption
Vref (t + 1) represents the assumed voltage at the next
timeframe. It is computed from the measured voltage if the
boundaries are breached, otherwise using the assumed voltage
of the current timeframe:
(
Vref (t) − ∆V (t) L(t) < Vm (t) < U (t)
Vref (t + 1) =
Vm (t) − ∆V (t)
else
If U (t) or L(t) are breached the power consumption must
be adopted. The BVO computes the feedback which indicates
how strong the boundary was breached and is rounded to the
nearest integer value:

Vm (t) − Vref (t)


− L(t) − V (t) Vm (t) < L(t)


ref
F (t) = Vm (t) − Vref (t)
Vm (t) > U (t)


U (t) − Vref (t)



0
else
The system behavior is shown in figure 3. In the second
timeframe the current voltage drops below L(t), resulting in
a negative feedback and the update of ∆V (t). In this figure
the feedback results in an adoption of the power consumption
and thus the voltage declines less in the third timeframe.
Configuration parameters defined before the deployment of
the system are the boundaries B+ and B− , the length and
number of timeframes and Vcutof f . While Vcutof f is system
dependent, the boundaries and the length and thus the number
of the timeframes define the responsiveness of the system.
While running, the BVO only depends on Vm and t.
B. The Abstract Battery Model
Using the raw feedback from the BVO to change the
consumption may not lead to the intended application quality
For example, the high drop of the voltage in phase A of figure
1 would lead to a negative feedback in the first timeframes,
resulting in less work done by the node since it takes time
until positive feedback cancels the negative one. To increase
the feedback quality and thus the overall application quality
it seams reasonable to benefit from basic information about
battery behavior. Assuming the discharge behavior of figure 1,
the ABM changes the feedback to adopt more to that behavior:
•
To prevent negative feedback due to the high voltage
drop in phase A, negative feedback is ignored in the first
timeframes.
If the remaining voltage budget is low (phase C), negative
feedback will be increased while positive feedback is
bound to a low value to ensure that the voltage does
not fall below the system cutoff-voltage under any circumstances. Positive feedback is ignored in the last timeframes, since an increased energy consumption results in
a rapid decline in phase C.
Experiments have shown that the BVO feedback in case
of disturbances from temperature etc. leads to slow reaction times after these disturbances and can result in a
continuously decreased power consumption. To increase
the reactivity, the feedback is summed up, changes in the
direction of the feedback resulting in additional increased
feedback and thus a rapid convergence towards the power
consumption defined at t0 .
Since the battery recovery effect leads to rising voltage
after higher negative feedback, a positive feedback would
be generated. To prevent oscillation of the feedback, the
positive feedback is restriced if the previous feedback was
negative.
V. E VALUATION & R ESULTS
A. Evaluation Setup
The battery manager was implemented using the REFLEX
operating system [12] for the Texas Instruments eZ430Chronos development system [13], equipped with an MSP
CC430F637 [6]. The application measures the battery voltage
periodically using the built-in Analog-to-Digital Converter,
sets the radio to receive mode for 250ms, and sends the system
parameters to an access point. A simple power manager was
implemented, which only changes the application duty cycle
(DC) according to the feedback. With each point of feedback
the duty cycle is increased or decreased by 10% with an initial
duty cycle of 1.1s.
CR2032 coin cells [14] were used to power the sensor
nodes for T = 120 timeframes with 12 minutes length. Under
stable conditions the battery is able to power the system for
≈29 hours before Vcutof f = 2.2V is reached, making a 20%
overhead for the experiment which normally would not be
used. The 24 hour experiment includes two 4 hour periods
exposing the nodes to ≈6◦ C, otherwise room temperature with
≈22◦ C.
B+ and B− were set to 0.5 and 0.1, resulting in a higher
U (t) than L(t). This is motivated by the fact that a fast
reaction to a lower than expected voltage is essential to reach
T , but a positive feedback resulting in a higher application
quality is only optional. A lower B+ could also lead to a too
often increased power consumption which exhausts the battery
to much and can only be compensated by a high negative
feedback and thus a low application quality towards T . The
timeframes for phase A where set to 10% of T and phase C
begins at 20% of the remaining voltage budget. These values
should be general enough to fit most battery types.
59
3.2
Feedback
Vm
Vm Reference Node
2.8
2.6
2.4
Battery Voltage [V]
DC
3.0
1.2
1.1
DC [s]
1.0
0.9
0.8
1.0
Feedback
0.0
-1.0
-2.0
0
Fig. 4.
t0
5
10
Time [hour]
15
t2
20
Experiment running 24 hours using EZ-Chronos sensor nodes and CR2032 coin cells, a high DC results in a lower power consumption
B. Results
The results of the experiment are shown in figure 4. The
lower voltage caused by the lower temperature is clearly
visible at t0 and t1 . The reference node with a stable DC
of 1.1s which does not adopt its power consumption starts to
reset at t2 due to low voltage and thus delivered only 73.6%
of the possible messages. The node adopting its consumption
not only reached T , but also delivered 6.2% more messages
than a node running a stable DC of 1.1s for 24 hours.
As shown in figure 4, no feedback was given to the PM in
the high voltage decline at the beginning of the experiment,
because of the rules of the ABM. In the first low temperature
phase starting at t0 , L(t) was not exceeded and the DC is
stable. After 11 hours U (t) was exceeded and a positive
feedback was given. After the beginning of the 2nd low
temperature phase at t1 the system reacts to the declined
voltage and gives a negative feedback, due to the ABM the
feedback was increased since a positive feedback was given
before. After the voltage stabilizes again, the DC is increased
constantly, except on positive feedback which was reversed in
the following timeframe, but repeated after the recovery effect
occurred.
Generally, a high reactivity of the coin cells with a strong
recovery effect occurred, which was so not observed on other
battery types.
VI. C ONCLUSION AND F UTURE W ORK
In this paper we presented a battery management approach
which avoids the complex computation of the state-of-charge
of batteries. It uses the voltage decline to give feedback
to an energy manager that adopts the power consumption.
Treating the battery as black box and using only the voltage
as information showed promising results in reaching lifetime
goals. Furthermore, the feedback allows the power manager
and battery manager to be completely independent from each
other.
60
t1
To further evaluate the approach longer lasting evaluations
with real world applications are necessary. Additionally, we
are planning to couple the battery management with an energy
manager which allocates the available energy budget to the
specific devices of a sensor node according to the battery
managers feedback and certain policies. Another planed future
work is to extend the approach to harvesting scenarios and to
different energy storage technologies, e.g. super capacitors.
R EFERENCES
[1] Madden, Samuel R. and Franklin, Michael J. and Hellerstein, Joseph M.
and Hong, Wei, TinyDB: an acquisitional query processing system for
sensor networks, ACM Transactions on Database Systems, 2005
[2] D. Linden, Handbook of batteries, second edition, McGraw-Hill Companies, 1995
[3] André Sieber, Karsten Walther, Stefan Nürnberger, Jörg Nolte, Implicit
Sleep Mode Determination in Power Management of Event-driven Deeply
Embedded Systems, 7th International Conference on Wired / Wireless
Internet Communications, University of Twente, The Netherlands, 2009
[4] Texas Instruments, BQ2023 Single-Wire Advanced Battery Monitor
Datasheet, Webpage http://www.ti.com
[5] Maxim Integrated Products, DS2438 Smart Battery Monitor Datasheet,
Webpage http://maxim-ic.com
[6] Texas Instruments, CC430F6xx 16-Bit Ultra-Low-Power MCU Datasheet,
Webpage http://www.ti.com
[7] Daler Rakhmatov, Battery voltage prediction for portable systems Circuits
and Systems, 2005
[8] Venkat Rao, Gaurav Singhal, Anshul Kumar, Nicolas Navet, Battery
Model for Embedded Systems, VLSI Design, 2005
[9] A Lachenmann, P Marrn, D Minder, Meeting lifetime goals with energy
levels, Proceedings of the 5th international conference on Embedded
networked sensor systems, 2007
[10] Christian Decker, Prozessorganisation in eingebetteten, ubiquitären
Rechnersystemen, Disseration, 2009
[11] C. Park, K. Lahiri, and A. Raghunathan, Batterydischarge characteristics
of wireless sensor nodes: An experimental analysis, In Proceedings of
the IEEE Conf. on Sensor and Ad-hoc Communications and Networks
(SECON). Santa Clara, pp. 430 440, 2005
[12] Karsten Walther, Jörg Nolte, A Flexible Scheduling Framework for
Deeply Embedded Systems, In Proc. of 4th IEEE International Symposium
on Embedded Computing, Niagara Falls, 2007
[13] Texas Instruments, eZ430-Chronos Development Tool Datasheet, Webpage http://www.ti.com
[14] Procter & Gamble, Duracell CR2032 Lithium Manganese Dioxide
Battery Datasheet, Webpage http://www.duracell.com
A Secure Monitoring and Control System for
Wireless Sensor Networks
Michael Riecker, Walther Müller, Matthias Hollick
Karsten Saller
Secure Mobile Networking Lab
Technische Universität Darmstadt
Mornewegstr. 32, 64293 Darmstadt, Germany
{michael.riecker, matthias.hollick}@seemoo.tu-darmstadt.de
Real-Time Systems Lab
Technische Universität Darmstadt
Merckstr. 25, 64283 Darmstadt, Germany
[email protected]
Abstract—The maintenance of Wireless Sensor Networks
(WSN) can carry high or prohibitive costs, particularly, if the
WSN is deployed in unattended areas. Secure monitoring and
control of the WSN is vital, however, practical systems are
rare and limited with respect to their capabilities. We present
a monitoring and control system for WSN that is secure and
additionally equipped with intrusion detection functionality. It
allows to reliably assess the actual status of the network, to
configure the sensor nodes, and to further use this data to
highlight suspicious events.
I. I NTRODUCTION
Wireless sensor networks (WSN) have become an established technology able to support a wide range of applications.
For example, WSN are used in military, home, health, environmental, and logistics applications. A lot of effort has been
put into securing these networks, for example [1]:
1) symmetric and asymmetric cryptography have been analyzed and optimized
2) specific key management protocols have been developed
3) secure routing protocols have been designed
4) intrusion detection schemes have been presented
What currently misses is a monitoring and control system
that is secured by appropriate cryptographic means1 . In this
paper we propose a secure monitoring and control system
enriched with intrusion detection capabilities. The goal is
twofold, we want to be able to control the network and to
monitor the WSN itself. In addition, the collected monitoring
data is used to discover anomalous events. The remainder
is organized as follows. After pointing to related work, we
present the architecture of our system as well as some implementation aspects. Then we show first evaluation results
before concluding our work.
II. R ELATED WORK
With .Sense [2] a secure framework for monitoring and
controlling WSN has been proposed. This system implements
security mechanisms that allow for a cryptographically secure
end-to-end communication. Users can send control messages
to the sensor network, influencing for example the routing or
1 The
focus of this work is on monitoring, hence, in the remainder of this
document we use the terms secure monitoring and control system as well as
secure monitoring system interchangeably.
the reporting interval. Sensed data is transmitted together with
the monitoring data, thus a separation of the actual task and
the monitoring of the sensor network is not possible. We are
unaware of a real implementation of this system.
In [3] the so-called poller-pollee structure is used for
monitoring purposes. The sensor nodes are divided into poller
and pollees, with pollers collecting the monitoring data of its
assigned pollees. The poller processes this data and decides
independently, which of the data should be forwarded to the
base station. The system—similar to other traditional network
monitoring systems—has not been tailored for the special
requirements of WSN.
Another approach to monitoring is called self-monitoring,
which is used in [4]. It is based on local monitoring and
the Watchdog [5] approach, having a sensor node monitor its
direct neighbors. Status data of individual sensor nodes cannot
be collected, the monitoring is restricted to the exchanged
messages in the network.
MOTE-VIEW [6] is a framework to manage, monitor,
and visualize sensor network deployments with a focus on
presenting the sensor node data in a highly usable form.
Security issues are not taken into account.
III. A RCHITECTURE
The intention behind our monitoring system (WSNMonitor)
is to allow the network administrator to obtain a holistic view
of the network. While the nodes observe the environment, we
monitor the nodes and their condition. This has to be done
securely, as we not only monitor the network, but also try to
detect intrusions based on the collected data. Besides security
and intrusion detection capabilities we require our system to be
as efficient and flexible as possible. When switched off, the
system shall add no overhead to the network. WSNMonitor
consists of a monitoring and control system with additional
intrusion detection module.
The control system issues commands to a real deployment
or to a simulated sensor network (WSNSim), which in turn
sends reports to the monitoring system. These reports are then
evaluated by the intrusion detection module (see Figure 1).
A. Security mechanisms
A monitoring system that shall also be used as intrusion detection system (IDS) requires security mechanisms to perform
61
key, a sensor node can calculate the MAC of its message and
append it, ensuring integrity during transmission. In addition,
this key can optionally be used to encrypt the message.
Diffie-Hellman key exchange: In the Diffie-Hellman key
exchange, the parameters p, g and A (where A = g a mod(p))
are determined by the base station and broadcasted to the
sensor nodes. A sensor node x replies to this message with its
Bx (Bx = g bx mod(p)), enabling both parties to calculate the
common key Sx (Sx = Abx mod(p) = Bx a mod(p)). This key
exchange takes place during the start-up, in which we assume
that no attacker is present (otherwise a man-in-the-middleattack would be possible). In order to update the symmetric
keys, the Diffie-Hellman key exchange is repeated, signing the
broadcast message with the ECC public key and protecting the
messages of the sensor nodes with a MAC value (generated
with the last valid key Sx ).
Fig. 1.
Sending a report to the monitoring system
its task reliably. In this section, we state our protection goals
and explain methods used to ensure confidentiality, integrity,
and authenticity.
Protection goals: An attacker shall neither be able to send
manipulated messages to the base station nor to impersonate
the base station. Messages originating from the base station
have to be authentic but need not to be confidential (in case
of a broadcast message). Reports by the sensor nodes are
confidential and have to be protected appropriately.
Assumptions: For the crypto system to be used we impose
the following assumptions:
• The first start-up of the system takes place in a secure
environment, i.e. no attacker is present
• An attacker may be able to read, change, or insert
messages into the network, but cannot break crypto
• The sensor nodes can be compromised during operation
In the next subsections we give details on how we provide
broadcast authentication and message confidentiality.
Broadcast authentication: Symmetric schemes can have
some serious drawbacks providing broadcast authentication.
It is desirable to use asymmetric encryption instead, taking
into account that more complex operations and thus computing
power, memory, etc. are required. Great progress has been
achieved in making public key cryptography suitable for
sensor networks [7]. In this work we decided to apply the
ECC crypto system to authenticate the broadcast messages of
the base station.
The ECC public key (192 bit) is generated by the base station and broadcasted to the nodes that can use it subsequently
to verify the authenticity of incoming control messages. If the
key needs to be updated, the start-up is executed again, signing
the broadcast message with the current valid key.
Message confidentiality: Symmetric encryption (AES-128)
is used for messages exchanged between each sensor node and
the base station, they share a pairwise key generated during
the start-up with a Diffie-Hellman key exchange. Using this
62
B. WSNMonitor
The user has to choose which information should be reported by which nodes in a specified time interval. For this
purpose, a control message is sent from WSNMonitor to the
sensor network, activating the desired behavior. An example
of the running WSNMonitor is shown in Figure 2.
Fig. 2.
WSNMonitor
A control message provides different options:
Broadcast Start-Up This option (re)calculates and negotiates the cryptographic keys. Besides, a sensor node replies
to this message with a list of all of its neighbors and the
corresponding link quality. Based on this data the monitoring
system builds a network graph, which is later on used in the
intrusion detection system to detect anomalies.
Ignore Nodes It is possible to exclude nodes from the
network, for instance if an attacker has been spotted in a
certain area. These nodes will not receive messages any longer.
Enable Nodes Disabled sensor nodes can be re-enabled
with this option.
Report Request The user can specify which information
should be reported by the sensor nodes, he sets the reporting
interval and may choose to encrypt the reports. Figure 1 shows
two sensor nodes sending a report to the monitoring system.
Data that is collectable includes:
• Status: Indicates the energy status of the battery, thus this
information allows the monitoring system to analyze the
energy consumption.
• Routing table: Contains all known destinations, the next
hop and the hop count to this destination as well as the
destination’s sequence number. Our system is not limited
to a particular routing protocol, the only requirement is
that the routing protocol makes use of routing tables.
• Number of messages: The sensor node counts all sent
and received messages within the reporting interval, distinguishing between monitoring, routing (route requests,
route replies, route errors), and other messages.
• All received/sent messages: For each message received/sent the sensor nodes collect the message type,
the ID of the node that forwarded this message, the ID
and the sequence number of the sender, and the ID of the
destination.
Intrusion Detection
The intrusion detection system is integrated into the monitoring and control system and as such is also centralized.
The data collected by the monitoring system is analyzed for
anomalies using a rule-based approach. These rules are splitted
into five modules, as depicted in Figure 3.
Fig. 3.
Structure of the Intrusion Detection System
The modules work independently of each other. Some
require the reports of the sensor nodes to contain certain
information like the routing table. Since we assume that
an attacker is able to compromise nodes and inject/remove
arbitrary messages, but is unable to break the cryptographic
algorithms, he cannot alter reports of non-compromised nodes.
At the current stage of implementation, our system can detect
attacks according to the rules we present in the following.
InsideNetwork module The InsideNetwork module checks
all available routing tables and the reports of the sent/received
messages for unknown IDs in the fields Next hop, Destination,
and Originator. This is to detect nodes that should not be part
of the network, i.e. that were absent during the start-up phase.
NodeReporting module This module knows the status and
the specified reporting interval of all nodes. If some report
is missing, it will throw a warning. To account for delays
during the transmission, we added a tolerance of two reporting
intervals.
MsgConfirmation module The MsgConfirmation module
is the most complex module of the intrusion detection system.
If summaries of the sent/received messages are included in
the report, this module checks whether a forwarded message
has been received by the next hop and whether the message
finally reached the destination. Besides that, we check whether
a received message is really originating from the supposed
sender. As reporting intervals can differ from node to node,
messages that cannot be analyzed due to missing reports
are stored for later evaluation, having a retention period of
three reporting intervals. Furthermore, using the sequence
number this module determines if a message appears multiple
times, signifying a replay or ping-pong attack. To summarize,
the whole message exchange is monitored trying to detect
anomalies and attacks targeted at the network layer and the
routing protocol (for instance blackhole, wormhole, selective
forwarding, etc.).
NoOfMsgsCheck module A profile of the average sending/receiving rate is calculated for each node. Strong deviations are reported to the intrusion detection system. A
deviation is not necessarily caused by an attack, but could have
other reasons, e.g. a certain phenomenon is only triggered at
night.
CheckRoutingTable module This module has access to
data gathered during the start-up of the sensor network. Based
on the neighbor relationships a graph of the network topology
is built. The CheckRoutingTable module checks whether the
reported routing tables are in compliance with the topology
graph. A message forwarded to a hop which is not directly
reachable indicates an attack on the routing table or a spoofing
attack. In addition, we check whether the next hop is indeed
closer to the destination than the sending node, otherwise a
blackhole or wormhole attack might be ongoing. Detecting
ping-pong attacks is possible by comparing the routing tables
of neighboring nodes, looking for messages with a certain
destination sent back and forth, without eventually reaching
the destination.
C. WSNSim
The focus of this paper is the WSNMonitor. While the monitoring system is ready to be used in real sensor networks, we
have currently implemented the monitoring components in a
Java-based network simulator, WSNSim, only. In WSNSim, we
use AODV as the routing protocol, the ruleset of our IDS has
been tailored accordingly to identify attacks against AODV.
After adding nodes and running the start-up phase (triggered
by WSNMonitor), random traffic can be generated. We implemented different kinds of misbehavior in the simulator that can
be selectively applied to the sensor nodes. In particular, we are
able to simulate blackhole, ping-pong, denial-of-service, and
replay attacks. Figure 4 shows a screenshot of WSNSim.
63
Fig. 5.
Fig. 4.
WSNSim
IV. E VALUATION
We performed extensive simulations regarding for instance
the detection probability and the time until detection. In
the following we present some selected results. In order
to measure the overhead of the monitoring system we executed 50 simulations. The simulated network consists of
100 sensor nodes and 2 base stations, randomly distributed
in each simulation run. The reports of the nodes are not
encrypted. We analyze the influence of the number of reporting
nodes on the message overhead. Therefore we simulated a
blackhole attacker with the setup as described above, having
the following constants:
• Reporting interval: 60 seconds
• Reported information: routing table
• Simulation time: 10 minutes
• Messages in the network per second: 3
• Attacker: 1 blackhole attacker
The results show that overall approx. 22.000 messages were
created and forwarded during a single simulation run. As observable in Figure 5, the usage of 20% reporting nodes causes
an overhead of about 1200 additional messages, constituting
5.4% of the total number of messages. We found that this
number of reporting nodes leads to good results with regard to
detection probability and detection time. For instance, the false
positive rate was always 0% during all simulations while the
false negative rate dropped to 0% with at least 20% reporting
nodes.
V. C ONCLUSION AND O UTLOOK
We have designed and implemented a monitoring and
control system able to analyze the status of a sensor network
by instrumenting nodes to send reports to the base station.
These reports serve as the basis to detect intrusions. Sending
appropriate control messages, attacked regions can then be
excluded from routing. The communication is protected using
cryptographic means guaranteeing integrity, authenticity, and
optional confidentiality. As a proof-of-concept, we have tested
64
Message overhead
our system in combination with a sensor network simulator.
First results on the performance of our system indicate that its
performance strongly depends on the user settings (reporting
interval, reported information). The implementation of the
monitoring component on real sensor nodes is ongoing work,
to allow for validation of the obtained performance in realworld WSN deployments. As future work, to further increase
the efficiency of the system, research on how to reduce the
report size is needed (e.g. compression, data aggregation, or
selective forwarding of suspicious events).
ACKNOWLEDGEMENTS
The work presented in this paper was performed in
the context of the Software-Cluster project EMERGENT
(www.software-cluster.org). It was partially funded by the
German Federal Ministry of Education and Research (BMBF)
under grant no. ”01IC10S01” and was supported by LOEWE
CASED (www.cased.de). The authors assume responsibility
for the content.
R EFERENCES
[1] Y. Wang, G. Attebury, and B. Ramamurthy, “A survey of security issues
in wireless sensor networks,” IEEE Communications Surveys & Tutorials,
vol. 8(2), 2006.
[2] M. Salajegheh, H. Soroush, A. Thomos, T. Dimitriou, and I. Krontiris,
“.Sense, A Secure Framework for Sensor Network Data Acquisition,
Monitoring and Command,” in ACM Workshop on Real-World Wireless
Sensor Networks, 2006.
[3] L. Li, M. Thottan, B. Yao, and S. Paul, “Distributed Network Monitoring with Bounded Link Utilization in IP Networks,” INFOCOM 2003.
Twenty-Second Annual Joint Conference of the IEEE Computer and
Communications. IEEE Societies, vol. 2, pp. 1189 – 1198, 2003.
[4] D. Dong, Y. Liu, and X. Liao, “Self-Monitoring for Sensor Networks,”
Proceedings of the 9th ACM international symposium on Mobile ad hoc
networking and computing, vol. 9, pp. 431 – 440, 2008.
[5] S. Marti, T. Giuli, K. Lai, and M. Baker, “Mitigating Routing Misbehavior
in Mobile Ad Hoc Networks,” MobiCom ’00: Proceedings of the 6th
annual international conference on Mobile computing and networking,
vol. 6, pp. 255 – 265, 2000.
[6] M. Turon, “Mote-view: A sensor network monitoring and management
tool,” in Proceedings of the Second IEEE Workshop on Embedded
Networked Sensors, 2005.
[7] A. Liu and P. Ning, “Tinyecc: A configurable library for elliptic curve
cryptography in wireless sensor networks,” in Information Processing in
Sensor Networks, 2008. IPSN ’08. International Conference on, 2008, pp.
245–256.
Vertrauenswürdige drahtlose Sensornetze in
sicherheitsrelevanten Einsatzszenarien
Björn Stelte
Institut für Technische Informatik
Universität der Bundeswehr München
85577 Neubiberg, Germany
Zusammenfassung—Obwohl drahtlose Sensornetze vermehrt
in sicherheitsrelevanten Einsatzszenarien Verwendung finden,
sind kaum ausreichende und effiziente Sicherheitsprotokolle bekannt. So sind vertrauenswürdige Ereignismeldungen meist nur
unter der Voraussetzung garantiert, dass Angreifer keinen physikalischen Kontakt zu Sensorknoten haben. In diesem Beitrag
wird ein Vorschlag zur Berechnung der Vertrauenswürdigkeit
einzelner Knoten auf der Grundlage von redundanten Meldungen
gemacht.
I. E INF ÜHRUNG
In den letzten Jahren haben drahtlose Sensornetze viel
Beachtung gefunden und es verwundert nicht, dass diese in
immer mehr Bereichen zu finden sind die sicherheitsrelevante
Informationen beinhalten. Sensornetze wurden ursprünglich
für militärische Zwecke konzipiert, die an sich bereits ein
Bedürfnis nach Informationssicherheit mitbringen. Im Laufe
der Zeit sind Sensornetze für zivile Szenarien hinzugekommen, wie etwa Umweltbeobachtungen, Katastrophenschutz,
Gesundheitswesen, Grenz- und Liegenschaftsüberwachung. Je
nach Einsatzszenario ergeben sich dabei unterschiedliche Ausprägungen bzgl. des Schutzbedarfes [1].
Trotz eines Bedarfs an Sicherheitslösungen für Sensornetze
stellen wir fest, dass nur ungenügende Lösungen existieren,
die Sicherheitsanforderungen offen lassen oder zu aufwendig bzgl. eines realistischen Einsatzes sind. Oftmals werden
hier als Gründe die leistungsschwache Hardware und zum
anderen der Batterieverbrauch genannt [1], [2], [3]. So sind
viele etablierte Schutzmechanismen bekannt aus klassischen
Rechnernetzen nicht direkt auf Sensornetze anwendbar. Hierzu
zählen bspw. eine Reihe von kryptographische Maßnahmen,
die entweder einen zu hohen Ressourcenbedarf aufweisen und
daher nicht eingesetzt werden können, erst durch zusätzliche
Hardware möglich werden [4], oder es werden hochgradig
optimierte Verfahren mit begrenzten Schlüssellängen und geringe Entropie der Zufallsquelle verwendet. Auch vermeintlich
starke Kryptoverfahren für Sensornetze, wie etwa die häufig
diskutierte Elliptic Curve Cryptography (ECC), werden in
der Forschung zur sicheren Kommunikation diskutiert, nur
sind u.a. Probleme wie die sichere Schlüsselverteilung nicht
geklärt und klassische Verfahren erhöhen den Energiebedarf
auf Kosten der Lebenszeit enorm.
Wie bereits in [1] beschrieben ist das Spektrum der Anwendungen für Sensornetze groß und somit der Schutzbedarf meist
individuell für das spezielle Einsatzszenario zu untersuchen.
Wir werden in diesem Beitrag von einem militärisch geprägten Szenario mit einem sehr hohem Schutzprofil ausgehen.
Hierbei ist, wie wir später noch zeigen werden, vor allem
das Vertrauen der Knoten untereinander bzw. die Frage “wie
vertrauenswürdig sind die gemeldeten Informationen” von
besonderer Bedeutung. Gehen wir im Weiteren davon aus,
dass Sensorknoten durch potenzielle Angreifer aufgesammelt,
analysiert und einfach manipuliert werden können (Stichwort:
missing tamper protection), so haben wir es hier mit dem
Innen-Täter zu tun. Dies bedeutet, dass trotz Verwendung
bspw. kryptographisch gesicherte Methoden authentifizierte
und autorisierte Knoten durch Angreifer erfolgreich manipuliert werden können und der Netz-Operator keine direkte
Möglichkeit hat manipulierte von loyalen Knoten zu unterscheiden. Wir werden im Weiteren eine Methode vorschlagen
die Auswirkungen zu reduzieren unter der Annahme, dass nur
ein relativ kleiner Teil des Netzes durch einen Innen-Täter
kontrolliert wird.
II. E INSATZSZENARIEN UND IHRE AUSPR ÄGUNGEN
So mannigfaltig das Einsatzspektrum für Sensornetze ist, so
sind auch die Designmerkmale realisierter Systeme zahlreich.
In [1] wurden Einsatzszenarien betrachtet und die folgenden
wesentlichen technischen Merkmale identifiziert: Kommunikationstopologie, Heterogenität der Knotenhardware, Kommunikationsrichtung, Aktivitätszyklus, Größe des Netzes, Vorhandene Infrastruktur, Mobilität der Knoten, Vorhandene Aktorik,
Datenaggregation, Netzdynamik, Zeitmessung, Lokalisierung
und Rekonfigurierbarkeit (für detaillierte Informationen zu den
Merkmalen sei hier auf [1] verwiesen). Je nach Szenario in
dem ein Sensornetz eingesetzt werden soll, spielen Sicherheitsfragestellungen eine mehr oder minder wichtige Rolle.
Dies betrifft sowohl die Informationssicherheit, wie auch die
Ausfallsicherheit gleichermaßen. Wie in [1] beschrieben hat
die Ausprägung der technischen Merkmale einen Einfluss auf
die zu verwendenden Sicherheitsmechanismen. So sind in der
Fachliteratur bereits generelle Sicherheitsmechanismen und
Protokolle vorgeschlagen worden, die oftmals auf einander
aufbauen und nur unter Einhaltung einiger Annahmen zur
Informationssicherheit betragen können. So wird bspw. beim
häufig zitierten µTESLA Verfahren eine zeitliche Synchronität
der Sensorknoten vorausgesetzt. Andere Verfahren wie etwa
65
SPINS beruhen wiederum auf µTESLA, da dieses Verfahren
zur Authentifizierung genutzt wird. Bei einem Versagen einer Komponente bspw. weil eine getroffene Annahme nicht
eingehalten werden kann, wird daher das gesamte eingesetzte
Verfahren bzgl. der angestrebten Sicherheit fraglich. Da die
Ausfallsicherheit ebenfalls ein wichtiges Thema in Sensornetzen ist - Knoten können jederzeit ausfallen - stellt sich
uns die Frage, warum die offensichtlich benötigte Redundanz
nicht auch zur Steigerung der Informationssicherheit dienlich
sein könnte. Wenn viele Knoten ein detektiertes Ereignis
über mehrere Ausbreitungswege einer Datensenke melden,
so kann diese Datensenke mittels redundanter Informationen
einen Wert bzgl. der Vertraulichkeit der einzelnen Knoten
bestimmen.
Zunächst möchten wir allerdings ein Szenario mit erhöhten
Sicherheitsbedarf vorstellen und diese Einsatzszenario als
Ausgangspunkt für eine anschauliche Erklärung unseres Verfahrens verwenden. In der Literatur findet man nur bedingt
gute sicherheitsrelevante Szenerien mit realen Hintergrund, ein
Ausnahme stellt hier das von Roberts et al. in [5] vorgestellte Holistan Szenario dar. Das militärisch geprägte Szenario
ist Teil der im Militär “International Coaltion Operations”
genannten Ausprägung von Einsätzen bei dem verschiedene
Kooperationspartner (Bsp. NATO) eine gemeinsame Mission absolvieren. Anders als das in diesem Umfeld häufig
verwendete Binni Szenario (End-War Szenario) werden in
Holistan realistische und einsatznahe Missionen beschrieben,
die große Ähnlichkeiten zu den aktuellen realen Einsätzen
aufweisen. In diesem Szenario werden Sensornetze in einem
unkontrollierbaren und nicht vertrauenswürdigen Umfeld zur
Unterstützung bei einer gemeinsamen Entscheidungsfindung
genutzt.
Roberts et al. beschreiben in [5] den fiktiven Staat “Malek
Republic of Holistan” als Ausgangspunkt für eine militärische
Stabilisierungsmission. Es wird als Hintergrund von einem
Bürgerkrieg ausgegangen, der großen Einfluss auf die Region
(hier Naher Osten) haben könnte. Da der Staat Holistan Massenvernichtungswaffen besitzt und die Kontrolle dieser Waffen
nicht in den Besitz von religiösen Militanten fallen soll, ist ein
Eingreifen einer internationalen Schutztruppe unausweichlich.
Genau diese internationale Schutztruppe jedoch steht vor einer
Anzahl von technischen Problemen:
•
•
•
•
•
Umgang mit Risiko und beschränktem Vertrauen unter
Koalitionspartnern
Einsatz von drahtlosen Netzen in feindlichen Umgebungen
Innovativer Einsatz von Sensoren in parasitären Moden
Entscheidungsfindungen mit Teilinformationen
Synthese von Umgebungsdaten in einfachen situativem
Kontext
Roberts et al. beschreiben insg. drei Missionen, wobei verschieden technische Herausforderungen bzgl. Rechnernetze,
Sicherheit, Sensor Informationsverarbeitung und Einsatzplanung herausgestellt werden. Wir werden im Weiteren das
von Roberts et al. beschriebene Teil-Szenario der Vereit-
66
lung eines terroristischen Aktes mittels einer “schmutzigen
Bombe” betrachten. Hierbei wird angenommen, dass Terroristen versuchen in den Besitz von radioaktiven Material
eines in Holistan befindlichen Kernkraftwerkes zu kommen
und dieses hochbrisante Material nutzen möchten, um eine
Anschlag vorzubereiten. Da die Geheimdienste davon ausgehen, dass die Terroristen über “Insider-Wissen” verfügen und
möglicherweise direkte Unterstützung von Regierungsbeamten
erhalten, sind gesicherte und vertrauenswürdige Informationen
nicht per se verfügbar. Die von den Koalitionstruppen zu
erfüllende Mission lautet (1) Aufspüren des aus der Anlage
geschmuggelten radioaktiven Materials und (2) Verhinderung
des Anschlages. Neben weiteren Maßnahmen sollen hierzu
drahtlose Sensornetze genutzt werden, um mittels spezieller
Sensorik radioaktives Material in der Umgebung der Anlagen aufzuspüren und ihren Weg weiterzuverfolgen. Da die
Infrastruktur für ein ortsgebundenes Netz nicht gegeben ist
und auch die Vertraulichkeit und Integrität der Informationen
gewährleistet werden soll, muss ein autarkes eigenes Sensornetz aufgebaut werden. Dieses soll den Koalitionstruppen
bei der Entscheidungsfindung und letztendlich Erfüllung ihrer Mission unterstützen. Nur ein zuverlässiges und vertrauenswürdiges Netz kann dies gewährleisten.
III. E TABLIERTE S ICHERHEITSARCHITEKTUREN UND IHRE
S CHW ÄCHEN
Der Aufwand eine nahezu vollständige Absicherung
von Sensornetzen hinsichtlich aller Anforderungen zu
gewährleisten wird allgemein als zu hoch angesehen. So
hat der Netz-Operator bei der Planung des Netzes die Entscheidung bzgl. einer Priorisierung der Kriterien zu treffen
und muss bspw. die Lebenszeit des Netzes gegenüber einem höheren Ressourcenbedarf für Sicherheitsmechanismen
abwägen [2].
Im Folgenden möchten wir kurz die bekanntesten
Sicherheits-Protokolle für drahtlose Sensornetze vorstellen
und bezogen auf das gegebene Szenario eine Einschätzung
bzgl. der Verwendbarkeit geben. Für weitergehende Informationen zu den Protokollen und einem detaillierteren Vergleich
sei auf die Ergebnisse in [2] und [6] verwiesen. Die bekanntesten und oft zitierten Protokolle sind TinySec, SPINS
(bzw. SNEP und µTESLA) und das Lightweight Security
Protocol for Wireless Sensor Networks (LiSP).
TinySec wurde von Karlof et al. bereits 2003 vorgeschlagen
und gilt als eines der ersten Sicherheits-Protokolle für drahtlose Sensornetze [7]. Das Protokoll baut auf dem TinyOS Betriebssystem auf und ist für die Applikation transparent. Daher
kann es ohne Anpassungen mit weiteren Sicherheitsmaßnahmen kombiniert werden. Zu den bereitgestellten Leistungen
des Protokolls zählen sichere Authentifizierung, Sicherstellung der Integrität der gesendeten Nachrichten und die Verschlüsselung von Übertragungen. Bzgl. der Verschlüsselung
wird in der Standard-Installation die veralteten kryptografischen Verfahren RC5 und Skipjack angeboten, jedoch ist
TinySec unabhängig von diesen Verfahren, so dass auch neuere
Verfahren eingesetzt werden können [8]. Das Protokoll bietet
Protocol
Typ
Schlüsselmgmt
Skalierbarkeit
In-network processing
Location aware
DoS
Paket Manipulation
Replay
Node capture
TinySec
Hop-to-Hop
Nein
Teilweise
Ja
Nein
Gering
-
SPINS
Node-to-Base
Ja
Gering
Nein
Nein
Teilweise
Ja
-
LiSP
Node-to-GH
Ja
Teilweise
Teilweise
Teilweise
Teilweise
Mittel
Ja
Teilweise
Tabelle I
I MPLEMENTIERTE S CHUTZMECHANISMEN ETABLIERTER P ROTOKOLLE
lediglich eine Hop-to-Hop Sicherheit an. Daher eignet sich
das Protokoll für größere Netze in multi-Hop Szenarien nicht
ohne eine entsprechende Kombination mit einem weiteren
Sicherungsmechanismus.
Das Protokoll SPINS basiert auf den beiden Verfahren
SNEP und µTESLA, wobei SNEP bzgl. Vertraulichkeit, Authentisierung und Aktualität des Datenverkehrs zuständig ist
und µTESLA einen authentifizierenden Broadcast bereitstellt
[9]. Die Kommunikation wird pro Kommunikationspartner
gesichert, daher muss pro Verbindung zusätzlicher Speicherbereich reserviert werden. So nutzt bspw. µTESLA zur Sicherung der Kommunikation aufgrund des Ressourcenbedarfes
eine symmetrische Verschlüsselung. Hierdurch ergeben sich
jedoch Probleme bzgl. der Synchronität bei großen Netzen.
LiSP wurde 2004 von Park et al. insbesondere hinsichtlich
zur Lösung des Problems eines sicheren Schüleraustausches
vorgeschlagen [10]. Anders als bspw. in TinySec wird ein
“rekeying” Mechanismus angeboten, um periodisch den verteilten Schlüssel zu erneuern. Zum Schutz des Netzes wird das
Netz in kleinere Cluster zerteilt. Jeder Cluster wird durch einen
“group head (GH)” Knoten verwaltet. Dieser GH Knoten teilt
den Mitgliedern des Clusters nach erfolgreicher Authentifizierung einen Master Key mit. Dieser Schlüssel wird benötigt, um
die periodisch erneuerten und per Broadcast versendeten Temporal Key zu entschlüsseln. Der Temporal Key ist der kryptographische Schlüssel bzgl. des Kommunikation innerhalb
des Clusters. Das Verfahren kann als gebrochen angesehen
werden, sobald der Angreifer im Besitzt des statischen Master
Key ist. Bspw. kann durch ein Auslesen des internen Speichers
(node capture) der Master Key verloren gehen und neue
Temporal Key Übertragungen jederzeit entschlüsselt werden.
Bezogen auf unser Holistian Szenario benötigen wir ein
drahtloses Sensornetz zur Abdeckung eines größeren Gebietes,
somit ist die erwartete nötige Anzahl von Knoten hoch. Des
Weiteren muss davon ausgegangen werden, dass Terroristen
physikalischen Zugang zu Sensorknoten haben könnten (node
capture) und somit den Vertrauenswürdigkeit einzelner Knoten
fragwürdig ist. Ein physikalischer Schutz der Knoten (Tamper Protection) kommt aufgrund der immensen Kosten nicht
infrage, es wird aber im Weiteren davon ausgegangen, dass
die Terroristen nur relativ wenige Sensorknoten unbemerkt
manipulieren können. Die Protokolle TinySec und SPINS
sind für größere Netze ungeeignet, da die Skalierung nicht
geben ist. LiSP dagegen ist durch die Aufteilung in Cluster
auch für größere Netze geeignet. Der bei TinySec und SNEP
(bzw. SPINS) verwendete kryptografischen Schlüssel für die
Kommunikation im Netz wird auf den Konten gespeichert
und ist daher leicht auslesbar. Lediglich LiSP sieht einen
leichten Schutz vor diesen Angriffen vor indem innerhalb
des Clusters ein individueller und periodisch wechselnder
Schlüssel verwendet wird. Jedoch ist auch hier der Master
Key auf den Knoten gespeichert, so dass ein Auslesen dieses
Schlüssels zur Komprimierung des Netzes führt.
Es bleibt festzustellen, dass wegen den besonderen Eigenschaften eines drahtlosen Sensornetze ein vollständig vertrauenswürdiges Netz nicht zu implementieren ist. Da aber
von einer geringen Zahl von manipulierten Knoten ausgegangen werden kann, besteht die Möglichkeit einen anderen
Ansatz zur Lösung des Problems der Überprüfung der Vertrauenswürdigkeit (hier bei der Detektion von radioaktiven
Material) zu wählen. Im nächsten Abschnitt möchten wir
kurz die Idee skizzieren und erste Ergebnisse einer TestImplementierung präsentieren.
IV. W IE VERTRAUENSW ÜRDIG IST EIN NACHBARKNOTEN ?
Da jedes Sicherheitssystem seine Grenzen hat, überwindbar
oder umgehbar ist stellt sich die Frage nach einer Lösung
zu unserem Problem. Wenn die Sicherheit der Knoten nicht
garantiert werden kann, so kann möglicherweise die Auswertung der kontinuierlich ausgelieferten Daten vieler Knoten bei
der Problematik helfen zu entscheiden ob ein Sensorknoten
als vertrauenswürdig und somit auch seine Daten als vertrauenswürdig angesehen werden können. Dies bedeutet, dass
wir zwar mehr Knoten als eigentlich erforderlich ausbringen
müssen, jedoch steigt hierdurch ebenfalls die Ausfallsicherheit
des gesamten Systems zu überschaubaren Kosten. Die Idee
ist also redundante Informationen über möglichst verschieden
Wege zu erhalten, um mittels geeigneter stochastischer Methoden einen Wert bzgl. der Vertrauenswürdigkeit der Knoten
zu erlangen. Da nur wenige Konten in der Nähe des lokalen
Ereignisses manipuliert oder zerstört wurden kann davon ausgegangen werden, dass mehrere lokale Knoten einen ähnlichen
Messwert liefern werden. Dieses machen wir uns zu nutzten
und können einen Wert der die Vertrauenswürdigkeit des
Knotens widerspiegelt berechnen. Unser gewähltes Verfahren
basiert hierzu auf der folgenden Gleichung zur Berechnung
eines Wertes bzgl. der Vertrauenswürdigkeit zwischen zwei
Konten (i und j) basierend auf den kontinuierlich gesendeten
Messwerten:
− µi,j
− µi,j
(1)
) − φ(
)
σ
σ
mit φ als die kumulative Verteilungsfunktion der Normalverteilung N (0, 1), µi,j und σ 2 als Erwartungswert und Varianz.
Bzgl. der Frage wie viele Knoten manipuliert sein dürfen
ohne Einfluss auf den Prozess der Entscheidungsfindung zu
haben, nehmen wir uns die Überlegungen Lamports zur Hilfe,
formuliert als Byzantinisches Entscheidungproblem. Hiernach
dürfen maximal (nonodes /3) Knoten betrügen [11].
Basierend auf den berechneten Wert Ti,j werden die folgenden Schritte angewendet:
Ti,j = φ(
67
1000
trust level node A
trust level node B
trust level node C
trust level node D
trust level node E
trust level node F
trust level node G
1
800
600
0.6
mean value
probability
0.8
trusted mean value
0.4
400
0.2
200
0
0
0
10000
20000
30000
40000
50000
60000
70000
time in ms
(a) Errechneter Grad der Vertrauenswürdigkeit.
Abbildung 1.
10000
20000
30000
40000
50000
60000
time in ms
(b) Kumulativer Wert errechnet aus vertrauenswürdigen Werten.
Gegenseitiges Vertrauen wird aufgebaut durch Bestätigung ähnlicher Messwerte der Nachbarn. (fage = 0.75; r = 0.5; = 500; σ = 100)
1) ‘aging factor’, um Schwankungen auszugleichen:
old
Ti,j = Ti,j
∗ fage + Ti,j ∗ (1 − fage )
mit fage zwischen 0 und 1.
2) Bestimmung der Vertrauenswürdigkeit anhand von vorherigen Werten:
trusti = trustoldi + (Ti,j ∗ Tj,i ), ∀j wobei i! = j.
3) Der schlechteste Fall bzgl. der Anzahl von illoyalen
Knoten wird angenommen:
trusti
trusti = nonodes −1−(no
.
nodes /3)
4) Falls der Schwellwert r überschritten ist, wird Knoten i
in dieser Runde als vertrauenswürdig eingestuft.
Hierbei sind die folgenden Parameter an das reale Szenario
anzupassen: Aging factor fage , Schwellwert r, Standardabweichung und Varianz σ.
Wir haben als Demonstrator die TinyOS Beispielapplikation
“Oscilloscope” um das präsentiertes Verfahren erweitert und
können erste Messergebnisse präsentieren. Hierbei hat ein
zentraler Knoten die Aufgabe von assoziierten Knoten Messergebnisse einzuholen und entsprechend einer Java Anwendung
auf dem Host zur Verfügung zu stellen. Die Abbildungen
1(a) und 1(b) zeigen die Messungen des Versuches. In dem
gewählten Szenario waren sieben Knoten zur Messungen der
Lichtstärke (anstelle eines Geigerzählers) eingesetzt, wobei
zwei Knoten vorsätzlich falsche Werte ausgeliefert haben.
Zu Anfang der Messung wurden alle Knoten als nicht vertrauenswürdig eingestuft und erst im Laufe des Versuches
zeigte sich welche Knoten vertrauenswürdige Werte ausliefern und welche nicht. Nach 42 Sekunden waren genügend
vertrauenswürdige Messwerte vorhanden, um einen ersten
kumulierten Wert auszugeben. In weiteren Messreihen konnte
gezeigt werden, dass das System sich innerhalb einer kurzen
Zeitspanne auf eine veränderte Umgebung anpassen kann und
kontinuierlich vertrauenswürdige Messwerte liefert.
Bzgl. des Ressourcenbedarfs wurde der Aufwand zur
Ausführung einer Runde analysiert. Insgesamt sind 5221396
CPU-Zyklen nötig, dies entspricht einem Strombedarf von
0,016076146 Joul. Dies kann als vertretbar angesehen werden,
zumal die Implementierung noch nicht für die verwendete
Plattform optimiert war.
68
0
V. Z USAMMENFASSUNG
Das in diesem Beitrag angeführte Szenario einer militärischen Operation stellt ohne Zweifel besondere Anforderungen an die Vertrauenswürdigkeit. Die erwähnten etablierten
Sicherheitsprotokolle können diese nicht garantieren. Der zur
Diskussion gestellte Vorschlag einer redundanten Ereignismeldung mit späterer Ereigniskorrelation zur Bestimmung des
Grades der Vertrauenswürdigkeit kann unter der Annahme, nur
ein kleiner Anteil von Knoten steht unter der Kontrolle eines
Angreifers, zur Lösung des Problems beitragen.
L ITERATUR
[1] C. Wieschebrink and M. Ullmann, “Klassifikation von sicherheitsrelevanten Einsatzszenarios für drahtlose Sensornetze,” GI/KuVS Fachgespräch Drahtlose Sensornetze 2008, p. 53, 2008.
[2] E. Cayirci, “Sensor Network Applications Implemented by Industry and
Their Security Challenges,” Autonomic and Trusted Computing, pp. 1–6,
2010.
[3] ——, “Deployed sensor networks and their security challenges in
practice,” in Proceedings of the 2nd international conference on Security
of information and networks. ACM, 2009, pp. 104–110.
[4] B. Stelte, “Toward development of high secure sensor network nodes
using an fpga-based architecture,” in Proceedings of the 6th International
Wireless Communications and Mobile Computing Conference. ACM,
2010, pp. 539–543.
[5] D. Roberts, G. Lock, and D. Verma, “Holistan: A futuristic scenario for
international coalition operations,” in Integration of Knowledge Intensive
Multi-Agent Systems, 2007. KIMAS 2007. International Conference on.
IEEE, 2007, pp. 423–427.
[6] A. Ahmed, “An Evaluation of Security Protocols on Wireless Sensor
Network,” 2009.
[7] C. Karlof, N. Sastry, and D. Wagner, “TinySec: a link layer security
architecture for wireless sensor networks,” in Proceedings of the 2nd international conference on Embedded networked sensor systems. ACM,
2004, pp. 162–175.
[8] B. Stelte and B. Saxe, “State-of-the-Art Kryptoverfahren fur drahtlose
Sensornetze–Eine Krypto-Bibliothek fur MantisOS,” Gesellschaft für
Informatik (GI) Konferenz Sicherheit 2010, p. 217, 2010.
[9] A. Perrig, R. Szewczyk, J. Tygar, V. Wen, and D. Culler, “SPINS:
Security protocols for sensor networks,” Wireless networks, vol. 8, no. 5,
pp. 521–534, 2002.
[10] T. Park and K. Shin, “LiSP: A lightweight security protocol for wireless
sensor networks,” ACM Transactions on Embedded Computing Systems
(TECS), vol. 3, no. 3, pp. 634–660, 2004.
[11] L. Lamport, R. Shostak, and M. Pease, “The Byzantine Generals
Problem,” ACM Trans. Program. Lang. Syst., vol. 4, pp. 382–401, July
1982.
Security for Practical CoAP Applications:
Issues and Solution Approaches
Martina Brachmann and Oscar Garcia-Morchon
Michael Kirsche
Philips Research
Distributed Sensor Systems
Eindhoven, Netherlands
eMail: {martina.brachmann, oscar.garcia}@philips.com
Brandenburg University of Technology Cottbus
Computer Networks and Communication Systems Group
Cottbus, Germany
eMail: [email protected]
Abstract—Protocols like 6LoWPAN and CoAP allow for an
integration of smart objects into an IP-driven Internet of Things,
thus enabling new applications such as pervasive health care or
intelligent building control automation. Providing security services (e.g., confidentiality, authentication, authorization) for these
applications is essential, as they affect our personal daily life.
However, established standard protocols and solutions cannot be
directly used in 6LoWPAN/CoAP networks, due to the resource
constrained nature of smart objects and new operation challenges
in practical deployments. This work presents a compact overview
of the current state-of-the-art in the IP-based Internet of Things;
details practical security issues that need to be solved, namely
end-to-end security and secure multicast based on (D)TLS; and
discusses further work.
I. I NTRODUCTION
The expression ‘The Internet of Things’ (IoT) was first
mentioned by Kevin Ashton in 1999 [1]. It combines the
general meaning of the term ‘Internet’ with (smart) objects,
such as sensors, localization systems or RFID tags, called
‘Things’, and denotes a network of objects, identifiable by
a unique address [2], [3].
The intention is to enable such objects to gather information
in a more accurate and efficient way than humans do. The
captured information can be used to improve peoples lifestyle
and well-being [1], as well as to protect the environment,
or to automate designated processes (industrial automation).
One possible deployment scenario for IoT, described in [4],
is pervasive health care, where wireless medical sensors can
be associated to different personal area networks and used for
health monitoring independent of location or time. Another
widely discussed example is building control automation in
order to directly manipulate lighting, heating, or security
settings in a building through a mobile phone [5]. There are
also efforts to use wireless sensor nodes to monitor tunnels [6]
and dikes [7], to observe birds [8], or control freight during
transportation in cargo containers [9].
Devices behind these use cases are typically battery powered
and equipped with slow micro-controllers and small RAMs
and ROMs. The data transfer is performed over wireless links
with low bandwidth and high packet error rates [3]. Unlike the
Internet, there are high scalability requirements with trillions
of nodes [10] and the communication is either Human-toMachine (H2M) or Machine-to-Machine(s) (M2M) [2].
The Internet Engineering Task Force (IETF) is currently
defining and standardizing an IP-based Internet of Things.
Several working groups (WG) are involved in this task [3]:
(i) The IPv6 over Low-Power Wireless Personal Area Networks
(6LoWPAN) WG is concerned with the adaptation of IPv6 to
IEEE 802.15.4, since IPv6 addressing is envisioned for the
enormous amount of nodes that might be interconnected in
the IoT [3]. Goals of the WG are the inclusion of neighbor
discovery methodologies and the compression of IPv6 packets
[11]. The latter is relevant, since the Maximum Transfer Unit
(MTU) of an IPv6 packet is minimum 1280 Bytes while IEEE
802.15.4’s maximum packet size is 127 Bytes [12]. (ii) The
Routing Over Low power and Lossy networks (ROLL) WG
focuses on the design of routing approaches for networks with
resource constrained devices, slow links, and a high packet
drop rate [13]. (iii) The Constrained RESTful Environment
(CoRE) WG defines an application layer protocol for resource
constrained devices, called Constrained Application Protocol
(CoAP) [14]. CoAP is related to HTTP, since both depend
on the fundamental Representational State Transfer (REST)
architecture of the web. Thus, CoAP allows, for example,
accessing the resources of a CoAP server from the Internet
(see Figure 1) by using certain HTTP methods and a similar
URI scheme to identify resources. UDP is used to prevent
message overhead. Reliability is added again by CoAP through
mechanisms like message ID’s, for duplicate detection, or
confirmable messages that require an acknowledgment [15].
HTTP
Client
HTTP
Server
CoAP
CoAP
HTTP
CoAP
6LBR
CoAP
Client
Constrained Environment
Server
Internet
Figure 1.
The CoRE architecture (cf. ([16])
69
So far, the 6LoWPAN, ROLL, and CoRE WGs have defined
a number of protocols. Some of them are already RFCs,
while others are still Internet Drafts at a very advanced state
(e.g. CoAP [15], 6LoWPAN-HC [17], RPL [18]). Rolling
out the protocols developed by the three WGs offer many
application areas. For example, it will be possible to setup light
configurations in large-scale systems [19]. Another use case
is requesting temperature or humidity in cargo containers via
Internet during transportation [9]. This enables an advanced
monitoring of the cooling chain for vendors and transportation operators. However, these scenarios require high security
needs [20]. For instance, an entity (e.g. a person, a device, or
an application) requiring access to specific resources in a thing
needs to be authenticated first. To prevent attacks the users
identity should be protected and the exchanged information
must be secured. In case the protection measures fail, changes
should be traceable and reparable. Another important demand
is system availability to ensure that authorized subjects can
use their access privileges at any time. Thus, these networks
should be resilient to Denial-of-Service (DoS) attacks.
II. P ROBLEM STATEMENT
Despite the work performed by the involved IETF working
groups, adequate solutions for a secure IP-based Internet of
Things are still not available.
[21] and [22] describe existing security solutions for the
Internet and give reasons why these solutions do not suit
the needs of constrained networks. The required security
mechanisms for the IoT can be grouped into five categories
[21]. The first one, network security, refers to the defense of
the lower layers in the OSI model, namely physical layer, data
link layer and network layer. The second category, application
security, aims at protecting applications and the exchange of
data between two or more entities. The third refers to the
secure bootstrapping [21] of the network while the other ones
aim at the security model of the ‘object’ itself and the security
architecture behind the object and its interconnection with
other objects and the Internet. Regarding application security, CoAP [15] describes four security modes to accomplish
different security requirements for varying goals: (i) NoSec,
no security; (ii) SharedKey, one key for all communication
partners of a node; (iii) MultiKey, one key per communication
partner; and (iv) Certificate, when a X.509 certificate is used.
In the following, we discuss two security issues related to the
use of the security modes ‘SharedKey’ and ‘MultiKey’ when
targeting end-to-end security and secure group communication, respectively.
a) End-to-End Security: Devices relying on CoAP’s
‘SharedKey’ or ‘MultiKey’ mode after bootstrapping can
secure their communication using a pre-shared key (PSK) and
DTLS [15], which is the datagram oriented version of TLS
(Transport Layer Security) [23]. CoAP runs over UDP, which
is the reason why DTLS [24] is used. It provides mechanisms
for a reliable negotiation of a session secret and additional
measures to verify exchanged packages. For that reason DTLS
packets cannot be directly translated to TLS and vice versa.
70
In this context, a first issue concerns the fact that a proxy is
needed to translate packets, when, for instance, an HTTP client
wants to access the resources from a CoAP server in the backend. The proxy can be a 6LoWPAN Border Router (6LBR),
as depicted in Figure 2. In addition, a mapping between HTTP
and CoAP in the application layer is required. To ensure that
no malicious code will be added, the proxy/6LBR has to be
a trusted instance. Until now, there is no solution to ensure
end-to-end security for this use case.
HTTP
CoAP
6LBR
Client/Server
Constrained Environment
Internet
Figure 2.
Possible scenario for end-to-end security
However, a couple of related security methods from other
use cases outside the IoT scope are available for adaptation
and inclusion into IoT security. For instance, one approach is a
TLS-DTLS tunnel [25], where DTLS packets are encapsulated
in TLS packets and vice versa. Another strategy was chosen
for ITLS (Integrated Transport Layer Security) [26]. The
sender encrypts a packet with two keys. The proxy owns the
first key, decrypts the packet with the key and forwards it
to the receiver. This method can be used in case the proxy
is not trustworthy. Both TLS-DTLS tunnel and ITLS require
additional source code on sender and receiver side. This can
be a disadvantage in constrained networks and, especially,
for devices with scarce memory. A different approach that
may be adapted for the problem is the method chosen for
dynamic tunneling over either TCP/TLS or UDP/DTLS based
on network conditions, as described in [27]. Nevertheless,
further analyses and comparisons of this and other approaches
are needed. Examples for further analyses concern the memory
consumption or the induced message overhead for negotiation
of the session secrets.
b) Secure group communication: Multicast messages are
used in CoAP to manipulate resources in a group of devices
at the same time (e.g., turning off all light bulbs in a building
floor). While unicast messages can be secured using DTLS
with PSK, providing secure multicast messages is still an open
issue, since DTLS does not support multicast. A solution is
necessary to ensure secure multicast within a group of nodes
and to fulfill the multicast (security) requirements for CoAP, as
listed in [19]. Similar to unicast, no end-to-end security can be
provided when using the Internet for manipulating a resource
in a group. In addition, TCP does not support multicast.
Like in the end-to-end security problem, a proxy/6LoBR
has to map HTTP onto CoAP and TLS to DTLS in both
directions. Additionally, a mapping from the unicast address
in the destination field of the UDP header to a multicast
address is required. Here, the proxy has to decide whether
a message’s destination address is multi- or unicast. To our
keen knowledge, there is no possibility to mark a message as
a multicast message in HTTP and the underlying protocols.
A solution approach for the described problems can be the
use of IPsec ESP [28] as an alternative to DTLS. As mentioned
in the Internet Draft of CoAP [15], IPsec is not recommended
by the CoRE WG, because it is not supported for all IP stacks.
However, there is a multicast extension for this protocol [29]
available. [21] suggests to consider the MIKEY architecture
[30] as a solution for negotiating a group key in the IoT.
III. S TEPS TOWARDS A SECURE IP- BASED I OT
Solving the problems described in Section II, namely endto-end security and secure group communication, is the key
to ensure a secure IP-based Internet of Things. In this section,
we introduce preliminary ideas to overcome them. The first
one concentrates on the problem when using both HTTP and
CoAP and hence, TLS and DTLS for a connection. The second
part is to find solutions for exchanging messages in a group
of CoAP nodes by using DTLS.
The goal for the first stated problem is to achieve a fully
secured communication between an HTTP and a CoAP entity.
Due to the resource-constrained nature of the nodes, the
usage of (D)TLS-PSK is assumed [15]. Figure 3 illustrates
the involved protocols for achieving end-to-end security. It
contains one HTTP and CoAP entity each and a 6LoWPAN
Border Router (6LBR), which acts as a proxy. A translation of
the message headers created by the (D)TLS record layer and
the protocols laying on top of it (handshake, alert, cipher suite,
application data), depicted in Figure 4, must be implemented.
HTTP
Client/Server
6LoWPAN
Border Router
internet
HTTP
TLS
TCP
Figure 3.
HTTP - CoAP
TLS - DTLS
TCP - UDP
CoAP
Server/Client
6LoWPAN
CoAP
DTLS
UDP
Architecture to achieve end-to-end security
For the development of a proper solution, a number of
factors need to be analyzed, e.g., whether the HTTP or the
CoAP client starts the communication, whether the proxy is
within the CoAP network, or if the proxy is a trusted instance.
Application
Transport
Network
HTTP
CoAP
Handshake Alert Change Cipher Spec Application Data
(D)TLS
Record Layer
TCP
UDP
IP
Figure 4.
(D)TLS in protocol stack
Further, the steps to extend DTLS support to secure multicast have to be analyzed. Two entities using DTLS negotiate
a session key for the communication. This key is determined
by a PSK and a pair of nonces created by both client and
server. That is why only two entities can negotiate one unique
session key. For the second issue, a solution has to be found,
to establish a secure connection by means of DTLS within a
group of devices with a single session key.
For group communication, different approaches are available that need to be analyzed. The first one concerns the possible communication topologies, illustrated in Figure 5. There
are distributed, centralized and hybrid topologies. Several use
cases, advantages, and disadvantages are described in [21].
This leads to a number of open issues, e.g., when to build a
group, how to determine group members, and when to close
it. For example, a membership in a group can be defined and
fixed during device bootstrapping. Another unsolved aspect is
when and how to refresh session keys.
6LoBR
(a) Distributed
Figure 5.
(b) Hybrid
6LoBR
(c) Centralized
Different communication topologies for group communication
In conclusion, this paper presented a short outline of the
current state-of-the-art in the IP-based Internet of Things. With
our focus on security, we have identified and discussed two
issues that need to be solved to ensure secure communication
links. In our future research, we will further study these and
other security gaps and will develop adequate solutions.
R EFERENCES
[1] K. Ashton, “That ’Internet of Things’ Thing,” online, http://www.
rfidjournal.com/article/view/4986, 2009.
[2] “Internet of Things in 2020: Roadmap for the Future,” online, http:
//www.iot-visitthefuture.eu/index.php?id=57, 2008.
[3] C. Bormann, J. Vasseur, and Z. Shelby, “The Internet of Things,” online,
http://isoc.org/wp/ietfjournal/?p=2066, 2010.
[4] O. Garcia-Morchon, T. Falck, T. Heer, and K. Wehrle, “Security for
Pervasive Medical Sensor Networks,” in 6th Int. Conference on Mobile
and Ubiquitous Systems (MobiQuitous 2009), July 2009.
[5] G. Derene, “How to Control Your Home with your Cell Phone,” online,
http://www.popularmechanics.com/home/improvement/4301977, 2009.
[6] Tunnel Sensors Ltd., “Tunnel Sensors - Monitors for the Tunnel Environment,” online, http://www.tunnelsensors.com/, 2011.
[7] URBANFLOOD CONSORTIUM, “About UrbanFlood,” online, http://
urbanflood.eu/aboutus.aspx, 2010.
[8] T. Bari, “BirdTracking: A Wireless Sensor Network to Observe Bird
Life,” M.Sc. Thesis, Embedded Software Group, Delft University of
Technology, The Netherlands, August 2010.
[9] K. Kuladinithi, O. Bergmann, T. Poetsch, M. Becker, and C. Goerg,
“Implementation of CoAP and its Application in Transport Logistics,”
in Extending the Internet to Low power and Lossy Networks, 2011.
[10] N. Kushalnagar, G. Montenegro, and C. Schumacher, “IPv6 over LowPower Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals,” IETF 6LoWPAN, RFC 4919,
2007.
[11] 6LoWPAN WG, “Description of Working Group,” online, https://
datatracker.ietf.org/wg/6lowpan/charter/, 2011.
[12] G. Montenegro, N. Kushalnagar, J. Hui, and D. Culler, “Transmission
of IPv6 Packets over IEEE 802.15.4 Networks,” IETF 6LoWPAN, RFC
4944, 2007.
[13] ROLL WG, “Description of Working Group,” online, https://datatracker.
ietf.org/wg/roll/charter/, 2011.
71
[14] CoRE WG, “Description of Working Group,” online, https://datatracker.
ietf.org/wg/core/charter/, 2011.
[15] Z. Shelby, K. Hartke, C. Bormann, and B. Frank, “Constrained Application Protocol (CoAP),” IETF CoRE, draft-ietf-core-coap-05 (work in
progress), 2011.
[16] Z. Shelby, “Introduction to Resource-Oriented Applications in Constrained Networks,” 2011.
[17] J. Hui and P. Thubert, “Compression Format for IPv6 Datagrams in Low
Power and Lossy Networks (6LoWPAN),” IETF 6LoWPAN, draft-ietf6lowpan-hc-15 (work in progress), 2011.
[18] P. Thubert, A. Brandt, T. Clausen, J. Hui, R. Kelsey, P. Levis, K. Pister,
R. Struik, and J. Vasseur, “RPL: IPv6 Routing Protocol for Low
power and Lossy Networks,” IETF ROLL, draft-ietf-roll-rpl-19 (work
in progress), 2011.
[19] A. Rahman and E. Dijk, “Group Communication for CoAP,” IETF
CoRE, draft-rahman-core-groupcomm-05 (work in progress), 2011.
[20] R. H. Weber, “Internet of things - new security and privacy challenges,”
in Legal discourse in cyberlaw and trade, S. M. Kierkegaard, Ed., 2009,
pp. 1–15, proceedings from the 4th International Conference on Legal,
Security and Privacy issues in IT.
[21] O. Garcia-Morchon, S. Keoh, S. Kumar, R. Hummen, and R. Struik,
“Security Considerations for the IoT,” IETF CoRE, draft-garcia-coresecurity-01 (work in progress), 2011.
[22] R. Hummen, T. Heer, and K. Wehrle, “A security protocol adaptation
layer for the ip-based internet of things,” Interconnecting Smart Objects
with the Internet Workshop, 3 2011, without peer-review.
[23] T. Dierks and E. Rescorla, “The Transport Layer Security (TLS) Protocol
Version 1.2,” IETF TLS, RFC 5246, 2008.
[24] E. Rescorla and N. Modadugu, “Datagram Transport Layer Security,”
IETF TLS, RFC 4347, 2006.
[25] J. Reardon, “Improving Tor using a TCP-over-DTLS Tunnel,” M.Sc.
Thesis, University of Waterloo, Canada, 2008.
[26] E.-K. Kwon, Y.-G. Cho, and K.-J. Chae, “Integrated transport layer security: End-to-end security model between wtls and tls,” in Proceedings
of the The 15th International Conference on Information Networking,
ser. ICOIN ’01. IEEE Computer Society, 2001.
[27] T. Short, H.-C. Chen, V. Parla, and M. Tardif, “Method for dynamically
tunneling over an unreliable protocol or a reliable protocol, based on
network conditions,” April 2007.
[28] S. Kent, “IP Encapsulating Security Payload (ESP),” IETF IPsec, RFC
4303, 2005.
[29] B. Weis, G. Gross, and D. Ignjatic, “Multicast Extension to the Security
Architecture for the Internet Protocol,” IETF MSEC, RFC 5374, 2008.
[30] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, and K. Norrman,
“MIKEY: Multimedia Internet KEYing,” IETF MSEC, RFC 3830, 2004.
72
Zellenweiser Messbetrieb, Vorverarbeitung und
drahtlose Kommunikation bei Fahrzeugbatterien
Sergej Ilgin, Niels Jegenhorst, Raik Kube, Simon Püttjer, K.-R. Riemschneider, Matthias Schneider, Jürgen Vollmer
Hochschule für Angewandte Wissenschaften Hamburg
[email protected] [email protected]
Kurzfassung—Heutige Systeme zur Überwachung von Starterund Traktionsbatterien betrachten stets die gesamte Batterie. Bei
Lithium-Antriebsbatterien wird mit verdrahtenen Messlösungen
gearbeitet, wobei Datenbusse mit aufwändiger und robuster
Anschluss- und Verbindungstechnik sowie komplizierter Potentialtrennung notwendig werden. Im Forschungsprojekt BATSEN
(Drahtlose Zellensensoren für Fahrzeugbatterien) wird ein alternativer Ansatz verfolgt, bei dem jede Zelle der Batterie einzeln
überwacht wird. Hierfür werden drahtlose Sensoren in jeder
der Zellen platziert, um dort Spannung und Temperatur zu
messen. Zusammen mit einem zentralen Batteriesteuergerät soll
eine Überwachung und eine Aussage über Ladezustand sowie
Alterungszustand der Batterie ermöglicht werden. Zunächst wird
die Anwendung der drahtlosen Sensoren bei Bleibatterien untersucht, später sollen damit insbesondere große Lithiumbatterien
überwacht werden.
I. E INF ÜHRUNG
Sowohl bei Fahrzeugen mit Verbrennungsmotor als auch
bei Elektrofahrzeugen (Flurförderzeuge, Hybrid- und Elektromobile) werden mehrzellige Fahrzeugbatterien verwendet.
Für den Betrieb dieser Fahrzeuge muss eine zuverlässige
Stromversorgung gewährleistet sein. Dazu werden bereits
heute Batterieüberwachungssysteme eingesetzt. Hierbei wird
häufig nur die Batterie als Ganzes betrachtet. Strom aber
auch Spannung und Temperatur werden nur an den äußeren
Anschlüssen der Batterien gemessen. Aufgrund von Toleranzen bei der Fertigung und verschiedenartigen Betriebsbedingungen treten Unterschiede im Lade- und Alterungszustand
der Zellen auf. Diese Unterschiede vergrößern sich im Laufe
des Batterielebens. Daraus resultiert eine verstärkte Belastung
der ’schwächeren’ Zellen, wodurch sich die Lebensdauer der
Batterie deutlich verkürzt. Es ist daher sinnvoll, die wichtigen
Betriebsgrößen Spannung und Temperatur jeder Zelle einzeln
zu messen, siehe Abbildung 1. Der Batteriestrom kann an den
äußeren Polen der Batterie zentral gemessen werden.
Abbildung 1.
Starterbatterie mit Versuchssensoren der Klasse 1
durch, um eine möglichst geringe Belastung des Funkkanals
zu gewährleisten, siehe Abbildung 2.
Die Messwerte werden von einem zentralen Batteriesteuergerät empfangen. Die Temperatur- und Spannungsdaten
der Zellen werden zusammen mit Messwerten des Batteriestromes weiterverarbeitet. Die Überwachung erfolgt also
in einem Zusammenwirken aus verteilter Messwerterfassung
und Vorauswahl sowie der zentralen Weiterverarbeitung. Die
Netzwerkkommunikation wird für die sehr verschiedenartigen
Kapazitätsgradient
(~Energieumsatz)
Hoch
Notwendige
Messdatenrate
Zulässige Latenzzeit Erforderliche
zwischen Messdaten Messauflösung
(% bzw. ppm)
versch.Sensoren
Hoch
Betriebzustände
des Zellensensors
HochstromEntladung
HochstromLadung
BetriebsEntladung
BetriebsLadung
Niedrig
Niedrig
Hoch
Hoch
II. V ERTEILTE F UNKTIONSWEISE
Eine verdrahtete Messung an den einzelnen Zellen bringt
eine Reihe von Nachteilen mit sich. Neben dem Aufwand
für eine robuste Anschluss- und Verbindungstechnik stellt die
Potenzialtrennung das größte Problem dieser Lösung dar. Als
Alternative dazu bietet sich eine Integration von drahtlosen
Sensoren in die einzelnen Zellen an.
Der Sensor misst Spannung und Temperatur einer Zelle und
führt je nach Betriebsmodus eine Vorauswahl der Messwerte
Ruhe
Niedrig
Niedrig
Abbildung 2.
Anforderungen der Betriebszustände an die Sensorik
73
Klasse 1
Klasse 2
Klasse 3
Übertragung zw.
Sensoren und
Steuergerät
nur
Uplink, kein
Downlink
Uplink und
Downlink mit
Broadcast-Wakeup
Uplink u. Downlink mit Multicast
u. addressierte
Kommandos
2.6
Zellspannung in V
Funktionsklasse
2.4
2.2
2
kein Empfänger
passiver
Empfänger
aktiver
Empfänger
Wechsel des
Sensormess- u.
-betriebsmodus
autonome
Entscheidung
teil-autonome
Entscheidung
zentral
kommandierte
Entscheidung
Mess- u.
Netzorganisation
ohne Synchr.
einfache zentrale
Synchr.
komplexe, paarw.
Synchr.
BalancierungsEffektor in der
Zelle
dezentrale
Steuerbarkeit
schwierig
bedingt möglich
(dezentrale
Entscheidung)
gut möglich
(zentrale
Entscheidung)
Werte in Sensorqueue
1.6
Empfänger im
Sensor
Spannungsverlauf einer Zelle
Entnommene Messwerte (Inqueue)
1.8
0
5
10
15
20
25
30
35
40
45
50
20
Füllung der Queue
Einstellen in Queue
Ausgabewert aus Queue
15
10
5
0
0
5
10
15
20
25
30
35
40
45
50
2.6
Gegenüberstellung der Konzepte des Zellensensors
Zellspannung in V
2.4
Tabelle 3.
2.2
2
Empfangseitig rekonstruierter Spannungsverlauf
Empfangene Werte ca. 20% Kollisonsverlust
1.8
1.6
Betriebszustände angepasst. Diese verteilte Funktionsweise ist
Gegenstand des Forschungsvorhabens. Es basiert auf Vorarbeiten insbesondere am Gabelstapler [3], [8], [9], [13].
III. AUFBAU DER S ENSOREN
Abhängig von der Anwendung sollen autonome, teilautonome (synchronisierte) und zentral gesteuerte Zellensensoren
untersucht werden. Daher werden drei Klassen von Sensoren
definiert, siehe Tabelle 3.
Gegenwärtig werden die Versuchsmuster der Sensoren von
Microcontrollern der MSP-Familie gesteuert. Diese besitzen
einen sehr niedrigen Stromverbrauch und können über einen
internen RC-Oszillator betrieben werden. Die Datenerfassung
erfolgt über einen internen ADC und eine Temperaturdiode.
Für die Versorgung der Sensor-Hardware ist ein Step-UpDown-Wandler auf dem Zellensensor verbaut, sodass ein
Betrieb zwischen 0.5 V und 5 V Zellspannung möglich ist.
Die Funkübertragung der Messwerte (Uplink) erfolgt im ISMBand bei 433 MHz mit OOK-Modulation. Durch die Verwendung eines modernen Transmitter-IC [17] in den neuesten
Versuchsmustern kann auch hier auf einen externen Quarz zur
Generierung der Sendefrequenz verzichtet werden. Als Endziel
soll die benötigte Sensor-Hardware inklusive Analog-, Digitalund HF-Schaltungen in einen Chip integriert werden.
A. Zellensensor ohne Downlink (Klasse 1)
Denkbares Anwendungsgebiet dieser Sensorklasse ist die
Starterbatterie. Da diese in Massenfertigung hergestellt wird,
ist der Sensor besonders kostensensitiv. Eine Übertragung vom
Batteriesteuergerät zum Sensor (Downlink) ist nicht vorgesehen. Die entsprechende Empfangsschaltung wird bei dieser
Klasse nicht integriert. Somit ist eine Synchronisation der
Funkkanalzugriffe wie auch eine sensorseitige Überprüfung
des Kanals auf Belegung nicht möglich. Um die resultierenden Kollisionen zu verringern, wird mit pseudo-zufälligen
Übertragungszeitpunkten und einer niedrigen durchschnittlichem Senderate gearbeitet. Die maximale Senderate wird
anhand der resultierenden Kollisionswahrscheinlichkeit ausgewählt [10]. Beim Spannungssignal des Sensors kann jedoch
eine hohe Dynamik auftreten, beispielsweise beim Starten
des Motors. Um die Spannung ausreichend genau abzutasten,
74
0
5
10
15
20
25
30
35
40
45
50
Zeit in s
Abbildung 4. Zellspannung bei Hochstromentladung, Betriebsladung und
Ruhe beim Start und Stopp eines Dieselmotors im Mercedes Vito 2,4D. Oben:
Entnommene Messwerte. Mitte: Queue-filling im Sensor. Unten: Rekonstruierter Messwertverlauf.
werden dann zusätzliche Messwerte in Abhängigkeit der Spannungsänderung aufgenommen. Dadurch kann die Messrate
kurzeitig über der maximalen Senderate liegen. Somit können
die Messwerte nicht mehr direkt übertragen werden, sondern
müssen im Sensor in einer Warteschlange (Queue) zusammen
mit einem lokalen Zeitstempel zwischengespeichert werden.
Geht die Dynamik des Spannungssignales anschließend wieder
zurück, fällt auch die Messrate wieder unter die maximal
mögliche Senderate. Dann wird der Zwischenspeicher im
Sensor geleert. Die übertragenen Messdaten werden im Steuergerät anhand der Zeitstempel den jeweiligen Messzeitpunkten
zugeordnet und so das Spannungssignal des Sensors rekonstruiert, siehe Abbildung 4. Aufgrund der ungenauen RCOszillatoren (Fehler 1-5 %) der Sensoren müssen die lokalen
Zeitstempel der Sensoren nachträglich korrigiert und der zentralen Zeitangabe des Steuergerätes zugeordnet werden, siehe
[14].
B. Zellensensor mit passivem Downlink-Empfänger (Klasse 2)
Im Rahmen einer laufenden Masterthesis [7] wird derzeit
ein Testsystem für diese Sensorklasse aufgebaut, siehe Abbildung 5. Hierbei wird auf dem Batteriesteuergerät ein IC
eines RFID-Readers, der bei 13,56 MHz arbeitet, eingesetzt.
Die entsprechende Transponder-Frontendschaltung auf dem
Sensor ist diskret aufgebaut [4]. Hauptvorteil des passiven
Empfängers ist die Möglichkeit, den Step-Up-Down-Wandler
auf dem Sensor über den Downlink-Kanal zu aktivieren, siehe
Abbildung 6. Dadurch kann der gesamte Sensor - nicht nur
der Transmitter - in Ruhephasen komplett deaktiviert und bei
Bedarf aktiviert werden. Da bei diesen Sensoren ein synchronisiertes Zeitschlitzverfahren verwendet wird, kann eine höhere
effektive Datenrate ohne Kollision erreicht werden.
C. Zellensensor mit aktivem Downlink-Empfänger (Klasse 3)
Die Sensoren der Klasse 3 sollen zukünftig über umfangreiche Funktionen verfügen, die durch den Downlink-
len vermindert. Die Steuerung der zellenweisen ’Stromumleitung’ benötigt u.a. ein Entscheidungsmodell, dazu besteht Forschungsbedarf im Rahmen des Vorhabens. Zellenausgleichsverfahren werden für die modernsten LithiumBatteriemonitoring-IC beworben [11]. Diese arbeiten jedoch
mit drahtgebundener Kommunikation, was generelle Nachteile
gegenüber dem drahtlosen Ansatz des Vorhabens aufweist.
IV. S YSTEMEINBINDUNG
A. Flexible Unterstützung von Batteriemodellen und Batteriemonitoring
Messages
A-Level
Functions
Messages
D. Ladungsbalancierung
cell 1,2,…,n
HF
Downlink
Uplink
(optional)
Spannungs
begrenzer
Spannungs
verdoppler
Lastmodulator
(optional)
Detektor &
Halteschaltung
Aktiv
Passiv
Schwingkreis
UHF
Uplink
C -Level
Tiefpass &
Demodulator
EN
Step-UpDown
Converter
Transmitter
MCU
...
Zellensensor 1
Zellensensor 2
Zellensensor n
cell 1,2,…,n
Abbildung 6.
Commands
Functions
Messages
B-Level
Commands
Der Ladungszustand von ’schwachen’ und ’gesunden’ Zellen kann durch einen vom Controller im Sensor geschalteten Nebenstrompfad in gewissem Umfang angeglichen (balanciert) werden, was die Schädigung der ’schwachen’ Zel-
Functions
...
C-Level
Messages
kanal kommandiert werden. Das können sowohl den einzelnen Sensor individuell adressierende Kommandos als auch
Broadcast/Multicast-Informationen sein. Der Sensor der Klasse 3 wird dem Kommunikationsverfahren IEEE 802.15.4 am
nächsten kommen, allerdings ist auch vergleichbar hoher Aufwand - insbesondere beim Empfänger - erforderlich. Er kann
wegen des Empfängers keine gänzlich stromlose Deaktivierung haben. Es ist noch nicht absehbar, ob diese Sensoren
den Kostenanforderungen genügen können. Alle drei Klassen
sollen dennoch im Projekt realisiert und verglichen werden.
Commands
Abbildung 5. Steuergerät und Versuchssensor der Klasse 2 mit:
(1) UHF-Uplink-Antenne u. Transmitter auf der Unterseite einer Sensorplatine
(2) HF-Downlink-Antenne auf der Oberseite des Sensors (Laboraufbau)
(3) Steuergerät Datenlogger mit Display und Interfaces
(4) Sender für HF-Downlink des Steuergerätes
(5) Sendeantenne des HF-Downlink (auf die Batterie aufsetzbar)
(6) UHF-Empfänger mit Empfangsantenne am Steuergerät
Um den Einsatz der Zellensensoren in den genannten
drei Klassen der Fahrzeugbatterien zu erlauben, muss das
der Überwachungsfunktion zugrunde liegende Batteriemodell
flexibel bleiben. Das Modell wird von der Batterietechnologie, den herstellerabhängigen Batteriespezifikationen und
den Vorgaben des Fahrzeugherstellers für angenommene Betriebsbedingungen bestimmt. Im Rahmen der vorgesehenen
Arbeiten soll ein Ansatz erarbeitet werden, sehr verschiedene
Batteriemodelle zu unterstützen. Diese sollen durch die Software des Batteriesteuergerätes und der Zellensensoren in den
Parametern einstellbar und der Funktionsweise anpassbar sein.
Functions
Abbildung 7. Grundgliederung der Battery Monitoring and Control Language
Zur formalen Beschreibung ist die Formulierung eines Vorschlags für eine Battery Monitoring and Control Language
(BMCL) geplant. Diese Sprache soll über einen Satz von Functions, Messages und Commands verfügen, die über die Batterietypen abstrahieren. BMCL soll über verschiedene Schichten
der Funktionalität verfügen, die auch der lokalen Anordnung
der Funktionalität bzw. Kommunikation entsprechen. Diese
Schichten sind wie folgt gegliedert: A-Level für die Applikationsebene, B-Level für das Gesamtbatteriemonitoring und
C-Level für die Funktionen des Sensors bzw. Effektors in der
Zelle, siehe Abbildung 7. Durch das Konzept von BMCL in
Verbindung mit einer Schaltungstechnik, die für einen breiten
Spannungsbereich geeignet ist, wird der Einsatz der drahtlosen
Zellensensoren für Blei- und Lithiumbatteriezellen möglich.
Schematischer Aufbau des Zellensensors der Klasse 2
75
Abbildung 8. Verbesserte Sensoren der Klasse 1 ohne Quarze für Controller
und Sender, hier Parallelschaltung für die Kalibrierung im Temperaturschrank
Abbildung 9. Erprobung am PKW, parallele Zellen-Erfassung mit drahtlosen
Sensoren und konventioneller Messtechnik (Spannung, Strom, Temperatur)
werden die mikroelektronische Realisierung und die breite
Erprobung mit verschiedener Batterietechnologie bilden.
B. Sensor-Kalibrierung
Die mit den Zellensensoren erfassten Spannungen müssen
bis in den Millivolt-Bereich genau erfasst werden, da bei modernen Batterietechnologien, wie Lithium-Titanat, die Spannungskurve bei Ladung bzw. Entladung sehr flach verläuft.
Außerdem sind passende Automotive-Temperaturbereiche
(AEC Q100 Grade 3) von -40 bis 85 ◦ C sicherzustellen. Auch
wenn davon die Batterie nicht den gesamten Tieftemperaturbereich abdecken wird, muss dennoch eine Temperaturinformation bis unter ein Grad genau bestimmbar sein. Auf dem Chip
steht hierfür nur eine einfache integrierte Diode zur Verfügung,
deren unkalibrierte Messfehler um einige Grad streuen. Es
ist eine wichtige Teilaufgabe, die Sensoren über individuelle
Korrekturfunktionen zu kalibrieren. Grundlage dafür sind die
umfangreiche Datenerfassung und die Regressionsrechnung
über Spannungen und Temperaturen. Entsprechende Arbeiten
erfolgen im Rahmen des Projektes [6], siehe Abbildung 8.
C. Bezug zu laufenden Entwicklungen beim Batteriemanagement
In den letzten fünf Jahren sind Entwicklungen zum elektronischen Batteriemanagement von vielen Firmen initiiert
worden [11], [18], [1]. Einige Automobilhersteller haben die
’elektronische Batterieklemme’ bereits in Serie eingeführt,
welche die Strom- und Spannungsüberwachung der Gesamtbatterie vornimmt. Die Kombination mit diesen bestehenden
Lösungen wird nicht ausgeschlossen, sondern sogar erwartet.
V. Z USAMMENFASSUNG
Im Forschungsprojekt sollen für drahtlose Zellensensoren von Fahrzeugbatterien die verschiedenen Realisierungsmöglichkeiten im Bezug auf unterschiedliche Betriebszustände der Anwendung untersucht werden. Ziel ist es, dabei
ein flexibles und trotzdem aufwandsgünstiges System für alle
Aspekte der Hardware, der Kommunikation und der Softwarestruktur zu finden. Wichtige Schwerpunkte weiterer Arbeiten
76
Danksagung
Das Vorhaben BATSEN wird vom BMBF gefördert (FKZ
17001X10) und von den Unternehmen Volkswagen AG, Bertrandt AG, Still GmbH, OMT GmbH, Fey Electronic GmbH
und Coilcraft Ltd. unterstützt.
L ITERATUR
[1] Analog Devices; ADuC703x, AD7280 - Datasheets; www.analog.com
[2] Ansari J., Pankin D., Mähönen P.: Radio-Triggered Wake-ups with
Addressing Capabilities for Extremely Low Power Sensor Network
Applications; IEEE PIMRC 2008.
[3] Eger, Torsten; Entwicklung von Hard- u. Software eines Readers für
drahtl. Sensorik m. Resonanzabgleich; Diplomarb. HAW Hamburg 2008
[4] Finkenzeller, Klaus, RFID-Handbuch, 5. Auflage, Hansa-Verlag, 2008
[5] Hella KGaA Hueck & Co.; Energiemanagement - Technische Informationen (Broschüre) im Internet www.hella.com/.../ti em d.pdf
[6] Ilgin, Sergej; Drahtlose Sensoren für Batteriemodule - Konzeption und
Kalibrierung; Bachelorthesis HAW Hamburg 2011
[7] Jegenhorst, Niels; Entwicklung eines Zellensensors für Fahrzeugbatterien
mit bidirektionaler drahtloser Kommunikation; Masterthesis HAW Hamburg 2011
[8] Krannich, Tobias; Experimentalsystem für einen Sensor-Controller mit
drahtl. Energie- u. Datenübertragung; Diplomarb. HAW Hamburg 2008
[9] Krannich T., Plaschke S., Riemschneider K.-R., Vollmer J.; Drahtlose
Sensoren für Batterie-Zellen - ein Diskussionsbeitrag aus Sicht einer Anwendung; 8. GI/ITG KuVS Fachgespräch Drahtlose Sensornetze“ 2009
”
[10] Kube, Raik; Drahtloses Sensornetzwerk für Fahrzeugbatterien - Kanal,
Antennen und Fehlerraten; Masterthesis, HAW Hamburg 2011
[11] Linear Technologies; LTC680x - Datasheets; www.linear.com
[12] Notten, P., Hetzendorf G.,Riemschneider K.-R.:Arrangement and Method
for Monitoring Pressure within a Battery Cell; EP1856760B1,
US2008097704A1, WO2006077519A1, CN100533845C u.a.
[13] Plaschke, Stephan; Experimentalsystem für drahtlose Batteriesensorik;
Diplomarbeit an der HAW Hamburg 2008
[14] Püttjer, Simon; Diagnosefunktionen für Automobil-Starterbatterien mit
drahtlosen Zellensensoren; Diplomarbeit HAW Hamburg 2011
[15] Pop, V., Bergveld, H., Danilov, D., Regtien, P., Notten, P.; Battery
Management Systems; Philips Research Book Series 2008
[16] Riemschneider, K.-R.; Wireless Battery Management System, Pat.appl.
WO2004/047215A1, US020060152190A1, EP000001573851A1
[17] Silicon Laboratories Inc.; SI4012 - Datasheet; www.silabs.com
[18] Texas Instruments.; bp76PL536 - Datasheets and Notes;
www.focus.ti.com
Efficient Power Management
Using Out-of-Band Signaling
Tobias Vaegs, Muhammad Hamad Alizai, Jó Ágila Bitsch Link, Klaus Wehrle
Communication and Distributed Systems,
RWTH Aachen University, Germany
{firstname.lastname}@comsys.rwth-aachen.de
Abstract—A tremendous amount of energy is wasted today,
because computing devices are left running all the time even
though they are needed only sporadically. Especially in office
environments many devices (e.g., printers) are very rarely turned
off, because they need to be available from time to time and
because it is inconvenient having to switch them on and off manually. Existing solutions, such as Wake-on-LAN (WoL), provide
support for managing the power consumption of the network
devices remotely using an always-on data channel. However, these
solutions are inefficient, because power to the network interface
has to be maintained even when the host system is asleep just to
ensure remote accessibility.
We propose a Wireless Sensor Network (WSN) based outof-band signaling architecture for network interfaces which
minimizes the systems’ power consumption during the large idle
periods when nobody is using them. This is done by separating
the data and control channels on the Internet-enabled devices
using a low-power out-of-band signaling channel based on battery
driven, energy scavenging devices. Unlike existing solutions,
which only allow parts of the system to go in sleep modes, our
architecture allows the whole system, including the main power
supply, to be shut down.
Our initial investigation indicates a significant reduction in
energy consumption of devices during idle times compared to
the existing in-band signaling mechanisms such as WoL.
I. I NTRODUCTION
Energy efficient operation of networked devices is pivotal in
establishing a sustainable green IT infrastructure at our homes
and in our offices. The Internet forms the core of our IT
infrastructure that includes Internet-enabled desktops, laptops,
printers, servers, storage, and IP phones. Approaches such as
Wake-on-LAN (WoL) have been proposed to enable sleepmodes on these systems without compromising the remote
accessibility enjoyed by always-on systems.
However, over the years, these approaches have not proven
successful for several reasons. For example, they rely on heavy
infrastructure or application-level support or manual user action, presenting barriers to deployment and use. Similarly, their
operation is inefficient since power to the network interface
has to be maintained even when the host system is asleep: The
network interface actively waits for incoming (in-band) signals
and thus continually draws power from the main power-supply
whose design is not optimized for powering such a small
subsystem.
We present a sensornet based out-of-band signaling architecture for network interfaces that significantly reduces systems’
power consumption during large idle periods when nobody
is using them. This is done by physically separating the
data and control channels on the Internet-enabled devices by
employing a low-power out-of-band signaling channel based
on battery driven, energy scavenging devices. Unlike existing
solutions, which only allow parts of a system to go in sleep
modes, our architecture allows the whole system, including
the main power supply, to be shut down. The control channel
interface is capable of signaling a wake-up or reboot the
system automatically when the need arises.
The utility of such an architecture lies in one key question:
Is it possible to construct a highly energy and cost efficient
out-of-band signaling mechanism to switch the power state
of certain devices? The energy overhead and the deployment
cost must be substantially smaller than for WoL based network
interfaces, since otherwise one should just directly use inband signaling as employed by the existing approaches. The
advances in sensornets research provide an affirmative answer
to this question and thus put us in the privileged position to
explore the feasibility of such an architecture even further.
In this position paper we suggest interesting directions
and opportunities offered by our solution. The remainder of
this paper discusses the design of our approach, presents
our prototype, and discusses an initial analysis of potential
energy savings. A thorough evaluation of the savings for a
real deployment is out of scope of this paper.
II. O UT- OF - BAND SIGNALING
Our solution for switching devices according to user’s needs
bases on out-of-band signaling. The basic idea is to control
devices over a Wireless Sensor Network (WSN) as a separate
signaling channel.
A. Scenario
Consider an environment where several devices are networked, like in a modern office or household. The connection
between the devices, which usually bases on the Internet
Protocol (IP), we will call the data channel. Technologies used
for these connections (like Ethernet of WiFi) are optimized to
transfer data at a high rate. Although they can also be used
for signaling purposes like it is done with WoL, they were not
designed with energy-efficiency in mind.
Instead of adjusting the existing data channel connecting
our target devices to work more energy-efficiently we propose
a separate signaling channel. Since this channel is solely
77
ID
WS
WS
Fig. 1. System design envisioned by us for our prototype: Parallel to the data
channel visualized by the solid line we propose a separate signaling channel
for controlling purposes using WSN technology visualized by the dashed line.
used for signaling purposes, it does not have to provide a
high bandwidth and can be based on energy-efficient WSN
technology (i.e., IEEE 802.15.4). Signaling users’ needs to the
devices in order to control power levels accordingly without
having to alter existing communication channels leads to a
solution that is cheap and flexible as well as easily and
incrementally deployable.
Figure 1 illustrates our design vision. The solid line represents the data channel (i.e., Ethernet and WiFi), which
interconnects most of the devices in a given environment,
like workstations (WS), servers (S), or printers (P). Usually
there is a device or a set of devices acting as interconnecting
device(s) (ID) by maintaining the communication between all
other devices. This can be everything ranging from a simple
WiFi router in a home environment to a very capable server
within a company’s network backbone.
The ID can send commands over the separate WSN channel
represented by the dashed line signaling devices to switch their
power state. If a device is capable of IEEE 802.15.4 communication without additional hardware, it may be switched
directly over this channel. Devices without this capability can
be controlled by an attached sensor node and/or be powered
over a power socket controllable over this channel.
The advantage of the ID is that it is usually always running
and connected to most other devices over the data channel.
So it can be used as a gateway to signal users’ needs, which
it receives over the data channel, to the connected devices.
Additionally to the ID, other devices (like a workstation) could
be used to send commands as well so that users can control
devices directly from their machines. However, in this case
the device being controlled (or the sensor node in control
of the corresponding power socket) would have to coordinate
commands from several senders.
Since the whole purpose of this design is to save as much
energy as possible, and since the sensor nodes are quite limited
in their capabilities, it would be better to let them sleep as
much as possible. Reacting on received commands would then
be their only purpose, and more evolved tasks were handled by
more capable devices that are reachable by most other devices
over the data channel. Those devices are usually consuming
power all the time anyway to perform other tasks and can
easily take the additional burden.
The design described here offers a variety of possibilities for
controlling the power state of the connected devices. Switching
to members of an elaborate set of energy saving states would
require the integration of the control logic directly into the
devices themselves, as this process is supposed to be very
device-specific.
However, with our prototype devices can simply be switched
off completely so that they do not consume any energy at
all during times in which they are not needed. Yet, they
can be switched on again fast and conveniently as soon as
they are needed. Moreover, our solution is realized with very
energy-efficient hardware, so the energy needed to keep the
device responsive to the users’ needs is reduced significantly
compared to currently available solutions directly integrated
into the devices (such as WoL).
Although our approach can save energy when used with
different classes of devices, consider a networked printer as a
use case. The printer is connected to the network over which
it receives its print jobs, and additionally it is capable of
communicating on the signaling channel over which it can
be turned on and off remotely.
The manual case would be that a user who wants to print
would have to send a command to switch on the printer before
(over the ID) and one to switch it off again after fetching the
printouts. This would already save energy, although it does
not involve any sophisticated program logic. This is because
our solution eliminates the inconvenient need to actually go
to the printer to switch it on before printing, which usually
prevents users from exploiting the idle times of the device
to save energy even though these times might account for a
significant portion of the day/week.
Manual switching of the device reflects the users’ needs
but is still a burden. Detecting users’ needs can be performed
arbitrarily complex, but in certain scenarios it is very easy. In
this use case our prototype software (cf. II-B) running on the
ID can switch on the printer when it detects the presence of
a corresponding print job and switch it off after some time
when no jobs for that printer are issued anymore.
Hence, the printer is switched-off for the majority of its idle
time, which is considerably long at nights, over the weekends,
and usually even during office hours. This approach promises
tremendous power savings as an office printer typically remains powered-on after installation until it is repaired or
replaced.
For these scenarios we need the switched devices to also
communicate with the ID for example to state when a print job
is finished. Another possibility would be to employ appropriate
heuristics to determine when a device should be switched on
and off, whose derivation lies outside the scope of this paper.
Those heuristics can be based on usage patterns derived over
time and should also take the boot-up time of the controlled
devices into account.
the node hardware uses only very little energy compared to
what the socket provides during times when the device is
running, it should usually be possible to keep the node alive,
as long as the device is used at least once in a while.
(3)
(1)
(2)
Fig. 2. A photograph of our prototype: One can see the switchable power
socket (1) connected to a telosB sensor node (2), that can receive commands
for this socket. Moreover, there is a second sensor node (3) connected to a
controlling device via USB to send those commands.
B. Prototype
As a proof of concept we created a very simple prototype
for our proposed separate WSN signaling channel and the
printer use case. We attached a standard telosB sensor node to
a switchable power socket with which we are able to switch
the printer on and off by enabling/disabling its power supply.
The socket we use1 provides a D-sub connector as a
control interface, that we attached to the exclusive digital
I/O expansion connector pins of the sensor node. This way
the node can switch the socket and thereby the printer when
triggered to do so. A photograph of this prototype can be seen
in Figure 2.
The software running on the nodes is intentionally kept
very simple to let them work as energy-efficient as possible.
We assume one base station node attached to the ID, which
sends out the commands for the nodes connected to the power
sockets. So the nodes only have to handle the plain command
sending and receiving, any other program logic is implemented
on the ID itself. Routing simply happens in a tree-based
fashion rooted in the base station node to enable multi-hop
command relaying.
The software running on the ID monitors the CUPS server
in the network. When a printing job appears for a printer,
which is known to be switchable, a switch-on command is
sent to the sensor node controlling that printer’s socket. After
a configurable timeout the printer is switched off again, if no
more printing jobs exist for it.
Of course, the software can be extended to collect information about usage patterns, room occupancies and the like
provided by sensors in the building and nodes attached to
workstations and other devices. Decisions on how to switch the
device can then be assisted by appropriate heuristics derived
from this information.
The sensor nodes connected to a switchable power sockets
can employ energy scavenging techniques so that the batteries
can be recharged during times when the device which is
controlled by the node is running (i.e., when power runs
through the switchable socket). The collected energy can then
be used by the sensor node to stay responsive during times
when the controlled device is completely powered off. Since
1 http://www.antrax.de/en/230V-Switchboxes/switch-via-USB-COMLPT/SwitchBox-Relay
III. A NALYSIS
After presenting our approach we want to give a rough
estimate on how much energy can be saved by deploying it.
A. Standby Power
Our prototype helps to reduce the power needed in standby
mode, which can be surprisingly much. The survey in [1]
gives an overview about how much energy different devices
consume during their standby phase, i.e., while not doing
anything useful but waiting to be used. Numbers can be found
ranging up to several watts with the minimum in the order of
one watt, also for computing devices like printers.
This is already significantly bigger than what we need to
keep the sensor node responsive, which is all our prototype
consumes during devices’ idle times.
B. Usage Patterns
Of course, we cannot just compare standby energy consumption of a device we want to control with the energy
consumption of a telosB node. We do not consider the power
consumption of the base station node, since the device it is
attached to (the ID) will be running anyway to perform its
other tasks and will not need significantly more energy to
power the base station node. Moreover, one base station can
be used to control several devices.
However, for a real comparison we need to take into account
the device’s usage pattern and the additional costs that come
with switching the device on and off. For this we use data
traces from the Powernet project2 at Stanford University,
where the power consumption of several office devices is
monitored constantly during regular usage. We took a look
at the data gathered over the whole month June 2011 from
three printers, whose power consumption and usage patterns
can be seen in Table I.
Three arguments for our approach are directly apparent
from these numbers: (1) Most devices are almost never turned
off, although they are used only a tiny fraction of the whole
time, so they mostly run in standby mode. (2) In this mode
the printers consume quite a lot of power. Nevertheless the
consumption is realistic considering the values in [1]. (3) Even
when the devices are turned off, they consume a significant
amount of power.
The total consumption of the three devices over the whole
month was 11.38 kWh, 8.31 kWh and 3.64 kWh, respectively.
C. Our Approach
To compute the potential savings of our approach, we
calculate its energy costs using the results from [4], where the
power consumption of the telosB sensor node was measured
and compared to the information in the official data sheet. For
2 http://powernet.stanford.edu
79
device
103
129
151
avg. consumption [W]
energy spent [%]
off
standby used
off
standby used
1.39
16.23 413.79 0.01
98.40
1.60
1.41
10.59 529.71 ∼ 0
99.89
0.11
1.19
6.19 340.68 6.39
87.64
5.97
time spent regular [%]
off
standby used
0.01 99.78
0.06
0.01 99.95
∼0
27.41 72.36
0.09
time spent OA
off
standby
97.19
2.75
98.81
1.18
97.61
2.30
[%]
used
0.06
∼0
0.09
total [kWh]
regular OA
11.38
0.53
7.31
0.12
3.64
0.35
saving
[%]
95.43
98.50
90.66
TABLE I
E NERGY CONSUMPTION DATA FROM THE P OWERNET PROJECT [2], [3]. BASIS FOR THESE NUMBERS IS THE DATA GATHERED FOR THREE PRINTERS
DURING J UNE 2011. N OTE THAT THE DEVICES CONSUME A SIGNIFICANT AMOUNT OF POWER EVEN WHILE THEY ARE TURNED OFF . W E COMPARE THE
TIME AND CONSUMPTION DURING REGULAR USAGE WITH THE TIME AND CONSUMPTION WHEN USING OUR APPROACH (OA).
simplicity reasons we do not consider any duty cycling for
now. The goal in the future is to allow the nodes to sleep
as much as possible, but their power consumption is already
fairly low without any duty cycling. We assume the node to
use only 68.4 mW all the time, regardless if the controlled
device is running or not. Hence, responsiveness of our system
for one device over a complete month (i.e., 24 hours over 30
days) needs 49.25 Wh.
Considering the controlled devices we distinguish three
different states: (1) active (i.e., the device is turned on and
used), (2) standby (i.e., it is turned on but not used), and (3)
off (i.e., its power supply has been cut).
The energy amount for the telosB stated above is spent all
the time, because the sensor node has to stay responsive to
receive commands. Additionally we have to consider energy
costs on top of that for the switchable socket and the device
itself. While turned off no additional costs apply, but while
the device is in standby or active state (i.e., turned on) the
socket needs 1.2 W. Moreover, in the standby state we have
to add the device’s standby consumption as well as its active
consumption during active times.
For our calculations we assume that the device is turned on
right before it is used and turned off after its usage has ended
and an additional timeout of five minutes has expired. Thus,
during this timeout the device would be in the standby state.
Whenever the device is not used long enough its power supply
is cut setting it to its off state.
The rightmost columns of Table I compare the printers’
power consumption as it was recorded (regular) as opposed to
the consumption calculated by us when using our prototype
(OA). One can see that at least 90% of the energy can be
saved. The savings are less when the devices are used more
frequently or when they are turned off manually from time to
time, but they are still huge.
D. Boot-up Phases
One more cause of energy consumption we have to consider
is the boot-up times of the devices. When a device is running
all the time, it constantly consumes some energy. However,
when turned off and on in between it saves energy while being
off but consumes significantly more power when switching
from the off to the on state. We assume the devices controlled
by our approach to be idle most of the time, so there will be
only very few boot-up phases, but the increase in energy can be
very drastic. Unfortunately the Powernet data did not provide
80
this information and since the increase in energy consumption
caused by the boot-up process varies significantly depending
on the device, it is hard to estimate for the general case.
However, what we can do is calculate how much power
a printer would have to spend during boot-up to use up
what our prototype would save. The energy saved by our
approach without considering boot-up phases is 10.85 kWh,
7.19 kWh, and 3.29 kWh, respectively. During the month of
monitoring when using our prototype the printers would have
to be switched on by it 227, 95 and 193 times, leading to an
available amount of energy per boot-up phase of 47.80 Wh,
75.68 Wh and 17.05 Wh. Even assuming very long boot-up
phases of 30 seconds, this would mean that during each of
them the printers would have to consume about 5.7 kW, 9 kW
and 2 kW, respectively, to defeat the savings gained by our
prototype.
ACKNOWLEDGMENTS
The authors like to thank Maria Kazandjieva and her colleagues working on the Stanford Powernet project for kindly
providing us with the raw data to analyze as well as Thomas
Gerlitz, Norbert Landa and Alexander Roth for helping with
implementing our prototype for TinyOS.
R EFERENCES
[1] A. Chakraborty and A. Pfaelzer, “An overview of standby power
management in electrical and electronic power devices and appliances to
improve the overall energy efficiency in creating a green world,” Journal
of Renewable and Sustainable Energy, vol. 3, no. 2, 2011. [Online].
Available: http://link.aip.org/link/?RSE/3/023112/1
[2] M. A. Kazandjieva, B. Heller, P. Levis, and C. Kozyrakis, “Energy
dumpster diving,” in Proceedings of the Second Workshop on Power
Aware Computing (HotPower), vol. 9, October 2009. [Online]. Available:
http://sing.stanford.edu/pubs/dumpster.pdf
[3] M. A. Kazandjieva, O. Gnawali, B. Heller, P. Levis, and C. Kozyrakis,
“Identifying energy waste through dense power sensing and utilization
monitoring,” Technical Report CSTR 2010-03, Stanford University, Tech.
Rep., August 2010.
[4] A. Prayati, C. Antonopoulos, T. Stoyanova, C. Koulamas, and
G. Papadopoulos, “A modeling approach on the telosb wsn platform
power consumption,” Journal of Systems and Software, vol. 83, no. 8,
pp. 1355 – 1363, 2010. [Online]. Available: http://www.sciencedirect.
com/science/article/pii/S0164121210000087
Wireless Sensor Network-Based Asset Management
for Mobile Measurement Devices
Helena Preiß, Sebastian Lempert, Christopher Kaffenberger, Alexander Pflaum
Department for Supply Chain Technologies
Center for Intelligent Objects ZIO
Fraunhofer Institute for Integrated Circuits IIS
Fuerth, Germany
Email: {helena.preiss; sebastian.lempert; christopher.kaffenberger; alexander.pflaum}@iis.fraunhofer.de
Abstract – The maturity level of Wireless Sensor Networks (WSN)
has grown constantly and the market offers first components and
products. Nevertheless the commercial breakthrough in
industries has not yet happened due to the lack of economically
justifiable applications. This paper presents the management of
assets as one promising field of application for WSN. In
particular we show how the existing asset management process
for mobile measurement devices at Fraunhofer IIS is optimized
with a WSN-based asset management system.
I.
AN INSUFFICIENT ASSET MANAGEMENT HAS NEGATIVE
IMPACTS ON VALUE-ADDING PROCESSES AND FINANCIAL
CAPABILITIES
Asset management could be defined “as systematic and
coordinated activities and practices through which an
organization optimally and sustainably manages its assets and
asset systems” [1]. In this context we understand assets as
physical goods which are essential for the execution of the
value-adding process but don’t merge in the final product.
From our point of view the need for an asset management
system is reasonable when three circumstances occur:
Assets have a high monetary value.
Assets have more than one user or responsible person.
Assets are critical for the company’s success as the
value-adding process depends on them.
In many cases a fourth criteria becomes essential as physical
assets can be mobile. These assets move around in a company
or on a site, are used at different places and often have not a
dedicated storage location.
If a company has not installed an asset management system the
last criteria leads to a lack of transparency about the number,
the status and the location of the assets. The assets wander
around, nobody feels responsible for them and they finally get
lost. Under these conditions a company has to hold high
security stocks if it wants to satisfy customer requests in time.
This ties up capital and narrows the financial capabilities for
the company. Additional, a badly performing asset
management influences the value-added processes negatively
as assets have long waiting times or are missed completely.
Asset management systems are as various as the companies
using them but mostly they don’t meet the high expectations in
reducing the stock, speeding up the processes and solving the
problems mentioned above. To prevent negative impacts of an
insufficient asset management, in this contribution we propose
the use of WSN for the management of eligible assets in
general. In particular we present a WSN-based asset
management solution for mobile measurement devices at
Fraunhofer IIS. The rest of this contribution is organized as
follows. A comparision between this contribution and related
work is given in section II. In section III we describe what the
previous asset management process at Fraunhofer IIS looked
like in the past along with its weaknesses. On this basis in
section IV we present the developed WSN-based asset
management system, the benefits that come along with it and
the method for optimizing the existing asset management
process. We conclude this contribution with a summary and an
outlook on prospective future work in section V.
II.
STATE OF THE ART: WSN FOR ASSET MANAGEMENT
WSN are broadly discussed in industries and research
literature, where [2] and [3] give a good overview about
different application areas.
Although the maturity level of WSN has grown constantly
over the years, a commercial breakthrough has not happened
yet. We compared 13 suppliers concerning their offerings in
the area of asset management systems and found out that all
companies offer RFID-based and about the half WLAN- or
RTLS-based solutions. Only one company has WSN in its
portfolio what leads us to the assumption that either the
customers don’t request this technology or that WSN-based
solutions for asset management are not ready for the market.
In contrast, a look on the scientific literature reveals first
pilot and test applications of WSN for the management of
assets. The main application areas are the health care sector and
hospitals. For example, in [4] and [5] medical devices are
equipped with ZigBee-based WSN nodes in order to track their
positions. The WSN consists of 21 mobile nodes and they aim
especially on time savings, asset utilization and an efficient
inventory management. A similar approach is described in [6].
In a clinical environment a WSN consisting of about 500
mobile s-net sensor nodes is used to optimize asset tracking,
the supply chain of blood product and the patient safety during
81
blood transfusion. Furthermore, WSN test installations are used
for asset management in logistics and supply chain
management. For example, commissioning might be improved
by using shelves and containers equipped with sensor nodes
which are speeding up picking processes [7]. This comparison
shows that there is still a discrepancy between research results
and their use in the industrial practices. The asset management
system presented in this contribution wants to reduce this gap.
III.
EXISTING ASSET MANAGEMENT PROCESS FOR MOBILE
MEASUREMENT DEVICES AT FRAUNHOFER IIS
A. Identification of Weaknesses in the Existing Process
The Fraunhofer Institute for Integrated Circuits IIS makes
use of a range of high-priced measurement and testing devices
from 1.000 € to 100.000 € used by different organizational
teams for research and industry projects. One single
measurement setup can consist of numerous devices so that
their worth can sum up to 1.000.000 €.
The original asset management process was supported by a
central IT-system. When new laboratory equipment was
bought, it was inventoried with its accompanying information
like identification number and type, its supplier, its storage
location and the responsible person in a database. All registered
employees are able to log in the IT-system, but they are only
allowed to search for devices and to change the current asset
location. The lending process looks as follows. If a person
wants to borrow a measurement device he or she selects it via
the IT-system and looks around in the laboratories. If a suitable
device is found and moved from one room to another, the
employee is urged to update the current location in the ITsystem manually.
B. Derivation of Requirements for a Supporting Asset
Management System
The process described above causes problems and a
dissatisfactory asset management situation. The employees
don’t consequently update the data in the IT-system and so
virtual and real storage locations are not consistent. This leads
to a couple of resulting discomforts with the asset management
system. To identify and rank the main problems guided
interviews consisting of 26 questions were carried out with
seven engineers. The seven engineers are responsible for the
measurement devices in their departments and spend most of
their working time with measurement tasks. A new asset
management solution should help to solve the following eight
aggregated main problems which negative affect the valueadding processes and the financial capabilities of the company:
Long search times for measurements devices as their
current location is not valid in the IT-system.
Decentralized storage of devices as they are not
returned to their original location after usage.
Loss of devices as they are borrowed by other
departments of the company and are not returned later.
High safety stock due to the attempt to satisfy
customer requests in time.
82
Time delays of research projects as industrial projects
are preferred in case of bottlenecks.
Measurement installations cannot be reproduced on a
later date.
Accompanying documents get lost, mixed up, or dirty
and so important information are not well attached to
the measurement device.
Yearly inventory is time consuming as the
measurement devices have to be searched and
documented manually.
Beyond these problems, the seven interview partners
mentioned additional functionalities the asset management
system should support:
Identification of measurement devices on item level.
Active localization of measurement devices.
Geofencing for the laboratories.
Geofencing describes the implementation of virtual fences
around an area and the active triggering of alarm messages
when a fence is crossed without permission [8, 9].
As the current IT-based asset management system caused
dissatisfaction among the employees, could not solve all
problems mentioned above and was not able to fulfill the
additional requests of the engineers, a new solution had to be
found. In this case, a WSN-based solution was selected for two
reasons. First, WSN provide all technological functionalities to
meet the requirements and second, a cost-benefit analysis
shows the best ratio compared with other technologies like
RFID or RTLS [10].
IV. OPTIMIZATED ASSET MANAGEMENT PROCESS THAT
USES A WSN-BASED ASSET MANAGEMENT SYSTEM
A. Overview on the System Architecture
The technical implementation relies on an integration and
application platform for diverse smart object technologies like
RFID, RTLS and WSN. This fundamental architecture unites
these technologies with a shared technology abstraction layer,
controls the interaction between these technologies and existing
enterprise infrastructures, supports intra-corporate and crosscompany integration and aims at reducing integration costs
significantly. Furthermore the platform is equipped with a set
of basic applications that serve as a basis for the efficient
development of more sophisticated applications for the Internet
of Things [11].
The essential requirements that such a platform should meet
are presented in [12], further detailed requirements and the
corresponding fundamental abstract architecture are presented
in [13]. In addition a description of the underlying
methodological approach that comprises the structured
derivation of functional requirements from real world
applications and subsequently the design of the platform is
given in [10].
sdfsdfadasd
Figure 1: Asset management system architecture based on s-net sensor nodes and the integration and application platform
As can be seen in Figure 1 the implemented asset
management system architecture consists of:
Java EE components. The same applies to the asset
management application on top of the platform.
Mobile and fixed WSN infrastructure: Since mobile
sensor nodes are battery powered, frequent battery
changes would be a show-stopper in a system with a
large amount of deployed sensor nodes. Consequently
the system is built upon very energy efficient s-net
sensor nodes and corresponding gateways and anchor
nodes that were developed at Fraunhofer IIS [14].
B. Details on the Functionalities of the Developed System
For every asset, basic information like inventory number,
warranty expiration date and specification are stored in a
database. These information are accessible via a web frontend,
where reservations can be made, capacities can be checked and
measurement setups can be defined and reproduced.
Integration and application platform: The platform
serves as a basis for the asset management application
and connects this application and the WSN
infrastructure to the existing enterprise IT.
Existing enterprise IT: The asset management system
is integrated into the intranet of Fraunhofer IIS. An
additional connection to the existing management
information system is planned for the near future.
Clients: The asset management system comes with a
user friendly graphical user interface that can be
accessed with usual web browsers.
The concrete implementation of the above mentioned
abstract platform architecture is based on the current Java EE
specification Version 6. Amongst others our implementation
leverages the standards EJB 3.1, JPA 2.0 and JSF 2.0 while
using JBoss AS 6.0.0, PostgreSQL 9.0.4 and OpenFaces 3.0.
The platform modules presented in [13] are implemented as
Since real life information must be available to the system,
every asset is equipped with and represented by a s-net sensor
node (see Figure 2). Periodically, the sensor node sends its
position to the integration and application platform via hard
wired anchor nodes (which are installed in almost every room)
or directly to the gateway, which routes messages to the
platform. After receiving and interpreting a message, the
platform maps the sensor node id to the asset id, adds a time
stamp and stores the coordinates of the node in a database.
Furthermore, the room number that belongs to these
coordinates is determined by a positioning engine and stored in
the database too. Amongst others, on this basis, two scenarios
can occur:
Users can ask for the actual position of an asset: that
means that via a web frontend the last room that has
been determined by the positioning engine is shown on
a map.
83
The system logic is responsible for generating alert
messages in case defined geofences are crossed
without permission: every time the server receives the
position from a sensor node, the generated room
number is compared to a list of rooms an asset must
not leave. In case that the room number is not one of
those associated with the asset, a SMS message is sent
to the owner of the asset.
Last but not least the management of the system is done by
an authorized administrator, who can add new assets to the
system, assign to them their respective sensor nodes, allocate
geofences, add new users and administrators and (un-)connect
the system to gateway nodes.
adequate level. This will be done through usability tests with a
group of users, who answer questionnaires and execute typical
use cases with the asset management system. The results of
these tests will build the base for the optimization of the system
in a version 2.0. In addition in the next months the system will
be enlarged: more measurement devices will be tagged with the
s-net sensor nodes. Furthermore the next generation of s-net
sensor nodes will be developed and used as well. These nodes
will be equipped with an energy efficient Wake Up-Receiver
[15] that represents a significant contribution to the economy of
the WSN-based asset management process.
[1]
[2]
[3]
[4]
[5]
[6]
Figure 2: Mobile measurement device observed by s-net sensor node
[7]
C. Testbed for the Asset Management Application
The project was executed at two distantly located
departments of the Fraunhofer Institute for Integrated Circuits
IIS, Nuremberg and Fuerth. Every department initially received
about 20 sensor nodes. In addition, 30 anchor nodes were
permanently installed at both department sites. The asset
management system itself is available via a web frontend and
thus accessible via the Fraunhofer IIS intranet site.
V.
[9]
[10]
CONCLUSION AND OUTLOOK
This contribution was motivated by the negative impacts
that an insufficient asset management has on value-adding
processes and financial capabilities. Against the background of
an inefficient asset management process for mobile
measurement devices at Fraunhofer IIS, we showed how this
process was optimized with a WSN-based asset management
system: we described what the previous asset management
process at Fraunhofer IIS looked like in the past along with its
weaknesses. On this basis we presented the developed WSNbased asset management system, the benefits that come along
with it and the method for optimizing the existing asset
management process at Fraunhofer.
The system has been implemented over the last months and
the next step is the evaluation of the system. Aim is to proof if
the system supports the users in the departments on an
84
[8]
[11]
[12]
[13]
[14]
[15]
The Institute of Asset Management, “PAS 55-1:2008 - Asset
Management Part 1: Specification for the optimized management of
physical assets”. London, UK, British Standards Institution, 2008.
M. Ilyas and I. Mahgoub, Imad, “Handbook of Sensor Networks”. Boca
Raton, FL, USA: CRC Press, 2005.
H. Karl and A. Willig, “Protocols and Architectures for Wireless Sensor
Networks”. Chichester, West Sussex, UK: John Wiley & Sons, 2007.
K. Kim, J. Jun, S. Kim and B. Y. Sung, “Medical Asset Tracking
Application with Wireless Sensor Networks” in Proceedings of
SENSORCOMM 2008, Cap Esterel, France, pp. 531-536, August 2008.
S.-J. Kim, J. H. Seo, J. Krishna and S.-J. Kim, “Wireless Sensor
Network based Asset Tracking Service” in Proceedings of PICMET
2008, Cape Town, South Africa, pp. 2643-2647, July 2008.
A. Pflaum et al., “Deployment of a wireless sensor network to support
and optimize logistical processes in a clinical environment” in
Proceedings of RFID-SysTech 2010, Ciudad, Spain, June 2010
M. Faschinger, C. R. Sastry, A. H. Patel and N. C. Taş, “An RFID and
Wireless Sensor Network-based Implementation of Workflow
Optimization” in Proceedings of WoWMoM 2007, Espo, Finnland, pp.
1-8, June 2007.
F. Reclus and K. Drouard, “Geofencing for Fleet & Freight
Management” in Proceedings of ITST 2009, Lille, France, pp. 353–356,
October 2009.
E. Gill, B. M. Fox and J. Kreisel, “Emerging commercial opportunities
based on combined communication–navigation services” in Acta
Astronautica, vol. 59, pp. 100– 106, July-September 2006.
S. Lempert and A. Pflaum, “Sensornetzbasiertes Supply Chain Event
Management zur Optimierung des innerbetrieblichen Asset
Managements am Fraunhofer IIS” in Proceedings of LM 2011,
Bamberg, Germany, in press, September 2011.
S. Lempert and A. Pflaum, “Development of an Integration and
Application Platform for Diverse Identification and Positioning
Technologies”, in press, Springer, 2011.
S. Lempert and A. Pflaum, “Über die Notwendigkeit einer
Integrationsplattform für unterschiedliche Smart Object Technologien”
in Prodeedings of FGSN 2010, Wuerzburg, Germany, pp. 71–74,
September 2010.
S. Lempert and A. Pflaum, “Towards a Reference Architecture for an
Integration Platform for Diverse Smart Object Technologies” in
Proceedings of MMS 2011, Kaiserslautern, Germany, pp. 53–66,
February 2011.
Fraunhofer IIS, “Wireless Sensor Networks”, available online at
http://www.iis.fraunhofer.de/en/Images/Wireless_Sensor_Networks_tcm
183-84849.pdf, last checked on 2011-07-15.
H. Milosiu, F. Meier, H. Preiss, F. Oehler and A. Pflaum, “A Novel
Concept for a Long Lifetime Wireless Geofencing System With an
Integrated Sub-10 µA Wake-Up Receiver” in Proceedings of RFIDSysTech 2011, Dresden, Germany, May 2011
1
TakaTuka — Java for Wireless Sensor Motes
Faisal Aslam and Christian Schindelhauer and Zartash Uzmi
Abstract—TakaTuka is a Java virtual machine (JVM) for
wireless sensor network devices. Java as a programming
language allows non specialized software developers to develop programs for wireless sensor networks. TakaTuka is
designed to support small microprocessors and offers CLDC
compatible library support. It optimizes the memory footprint, execution speed and energy consumption. At the moment it supports four sensor network platforms. TakaTuka
provides an optimized garbage collection, a Java debugger
and basic communication routines.
TakaTuka stores the full Java class in a highly compact
format named Tuk while the other information remains on
the compiling machine. The Tuk-format strips all unnecessary information, such as class names and retains only
essential information for runtime. This Split VM architecture allows enormous bytecode compaction that results in
smaller code size and faster bytecode execution.
Index Terms—Java, Programming, Wireless Sensor Networks, Memory Optimization, Garbage Collection
increases the execution speed.
For the memory management a new garbage collection
mechanism is introduced for the JVM which solves some
of the tasks of garbage collection at compile time. As a
consequence less memory is used during the execution of
TakaTuka during the execution and the performance of
TakaTuka sensor motes come close to the necessities of a
real-time computing. So, up to 66% more RAM might
be available during the execution compared to standard
JVMs. The storage, performance and RAM consumption
features of the TakaTuka JVM makes it an attractive platform for developing applications for wireless sensor networks employing micro-controllers and embedded devices.
For an overview of TakaTuka see [1].
II. Related Work
I. Introduction
Java as a high-level programming language enables the
simple and object-oriented development of software which
is platform-independent and robust. It guarantees type
safety and with the help of its runtime garbage collection
one does not run into memory allocation problems known
from programming languages like C.
For the programming of sensor motes the community
started with low-level languages like C, Assembler or specialized languages like nesC. This was caused by the hardware restrictions of a typical sensor mote, like the Crossbow Mica2, which provides only 4kB RAM for data memory, 128 kB flash code memory and a slow 8 bit microprocessor. So, it was widely believed that under such restrictions high-level programming under Java is impossible and
therefore Sun microsystems developed for their Java platform Squawk sensor motes in combination a fitting hardware platform with faster processors and sufficient memory.
The TakaTuka Java virtual machine (JVM) takes a different approach and is developed to fit on existing microcontrollers with small RAM, storage and processing power.
For this, the TakaTuka optimizes storage requirements for
the Java binary as well as the JVM interpreter, both of
which are to be stored on an embedded device. For this
the Java binary size of the TakaTuka JVM provides optimized code which needs for some extreme cases only 8%
of the usual size of a Java binary. Also, the interpreter
size for a given program is reduced to as small as 25 KB.
This highly optimized Java binary and Java interpreter allows sensor motes to run Java code and as a by-product
Faisal Aslam is with the Lahore University of Management Sciences (LUMS), Lahore, Pakistan, e-mail: [email protected]
Christian Schindelhauer is with the University of Freiburg, Germany, 79183 Freiburg, e-mail: [email protected]
Zartash Uzmi is with the Lahore University of Management Sciences (LUMS), Lahore, Pakistan, e-mail: [email protected]
Sun Microsystem’s JVM does not work on sensor motes
because its memory requirements of some hundred KBs.
To overcome this problem Sun Microsystems has released
Squawk, a special JVM for embedded systems [11]. It resolves some of the obstacles to implement a JVM on a sensor mote by using a Split VM Architecture (SVA). Such
a SVA runs resource hungry tasks of the JVM, including
class file loading and bytecode verification on the desktop
[10], [11]. By this, memory and CPU usage requirements
for motes are weakened. Now runtime loading and verification is not required on the mote. Compared to standard
JVMs, Squawk has lower requirements of resources. Still it
is not possible to run Squawk on a typical mote equipped
with an 8-bit microcontroller, a few hundred KB of flash
memory and around 10 KB of RAM. For such motes, Sentilla Corp. has developed a special JVM only for Sentilla
motes, which has not been open-source and has been discontinued recently [8]. Darjeeling, is an open source JVM
designed for motes [5]. It support only some parts of the
JVM specification and sacrifices some features like floating
point support, 8-byte data types and synchronized staticmethod calls for efficiency [5]. The Java Card VM [6] by
Sun Microsystems has very small resource requirements.
Yet, it does not support multi-threading and garbage collection. So, for a variety of applications is is not suitable.
There are a only few other JVMs available for embedded
devices, such as NanoVM [7], and VM* [9], but these are
either limited in functionality by not fully supporting JVM
specifications or are closed source with a limited scope of
operation only on specific devices.
III. TakaTuka
The TakaTuka JVM aims to provide all features of a
fully CLDC-compliant JVM 2. Currently, it supports all
but two of the Java bytecode instructions and most of the
CLDC library. It supports threading, debugging, synchronized method calls, 8-byte data types and 4-byte floating
85
Networks and Telematics
2
ach other.
we address
DQG )LHOGV
Split VM Architecture
3&6LGH
Mote Side
/RDGLQJ
9HULILFDWLRQ
/LQNLQJ
2SWLPL]DWLRQ
many Classfiles
1.5. Challenges and Contributions
,QWHUSUHWHU
0HPRU\0DQDJHPHQW
one Tukfile
XQWLPH
$SSOLFDWLRQ
:KROH&ODVV/LEUDU\
2SWLPL]HG$SSOLFDWLRQ
6XEVHWRI&ODVV/LEUDU\
RAM Optimizations
Fig. 1. Split Virtual Machine Architecture of TakaTuka [4]
Current Status
Percentage Reduction
ntries is
onstant
e of the
ant pool
Percentage Reduction
CLDC
RAM
is usually on
themotes.
scarcest
in motes,
because
point
arithmetic
It resource
runs on motes
with
RAM
of
its
high
energy
consumption.
Therefore
we
try to
as small as 4 KB and flash as small as 48 KB. It provides
reduce
the
RAM
usage
of
TakaTuka
as
much
as
possible.
74
Bytecode Compaction
Java interfaces for commonly used hardware components
of sensor motes. So, any platform, which provides an imTakaTuka keeps the application and libraries in non
plementation of those interfaces, also supports TakaTuka.
volatile memory (Flash). In contrast to traditional
The TakaTuka JVM has been tested on more than five
FODVVILOHVWKHLQGH[VWUXFWXUHVDUHEXLOWLQWRWKH7XNILOH Figure
1.2:
offline optimizations
and checks
Fig.
2. The
Generation
of the Tuk-File
[1] for the TakaTuka JVM. All optimizadifferent mote platforms and is currently available for the
tions
are
performed
on
a
desktop
computer
and,
afterwards, a compact Java binary (TUK)
following ones.
RAM is strictly used for dynamic data, that includes the
is transferred to the host device such as a mote.
• Crossbow IRIS
140
compution stack, the object heap and the VM state.
javax/microedition
• Crossbow MICA2/MICAz
java/io
120
java/lang
• Crossbow TelosB
collection wastes RAM by deallocating a subset of objects
from the set of objects that
java/util
Sun Spot Demos
• Sentilla JCreate
should be deallocated100
at a given point of the program
execution.
CTPFurthermore, the garbage
collection needs to analyze the program several times duringDYMO
its execution. These analyses
A number of Java WSN applications and protocols have
JTC
80
require extensive CPU cycles. Thus, garbage collection wastes
CPU cycles and reduce the
Quicksort
been developed and tested on such motes.
battery lifetime of wireless
motes.
This
work
presents
Offline
Garbage Collection (GC)
60
TakaTuka
stores theCore
complete Java classes in a highly
ŹVirtual Machine
to alleviate both of these problems. Our approach defies the current practice in which
compact
format named Tuk and stores other information
40
an object may be deallocated
only if it is unreachable. The Offline GC allows freeing
&XUUHQWO\UXQVRQWKH3&PLFD
on a $OPRVWIXOOVXSSRUWIRUVWDQGDUG-DYDE\WHFRGH
Tak-file which remain on the compiling machine.
an object that is still reachable but is guaranteed not to be used again in the program.
20
The Tuk-format
strips all unnecessary information, such as
&XVWRPL]DEOHLQIXQFWLRQDOLW\WRUHGXFHWKHVL]H
0
class %DVLFVXSSRUWIRUWKUHDGLQJV\QFKURQL]DWLRQ
names and retains only essential information for runInput Programs
time.%DVLFUXQWLPHJDUEDJHFROOHFWLRQ
This Split VM architecture allows enormous byte(a) LC
code compaction that results in smaller code size and faster Fig. 3. Sample decrease of the Java bytecode [1]
javax/microedition
bytecode
execution,
see Fig. Support
1 from [4].
ŹDrivers
and Hardware
60
java/io
java/lang
The
generation of the Tuk file involves a series of opti,QWHJUDWLRQLQWR7LQ\26
java/util
50
mization
steps, see Fig. 2 from [1]. First, the TakaTuka
Spot
Demos
/('DQGUDGLRGULYHUUHDOL]HG
The verification
process checksSun
the
integrity
of class file
CTP
compiler removes unreachable java code (dead code re- (e.g. if a branch
DYMO
target
is
valid
or
not.).
In
TakaTuka
the
40
JTC
moval).
Then, the following optimizations on the class bytecode verification is performed on the
Ź Miscellaneous
desktop computer
Quicksort
30
files of
a program are crucial:
/RDGLQJDQGOLQNLQJRIQHFHVVDU\FODVVHV
before transferring
the Tuk file onto the mote, see Fig. 3.
&RQVWDQW3RRORSWLPL]DWLRQV
1. Bytecode Optimizations
The Constant
Pool
(CP) of a class file has no redundant
20
2. 3UHOLPLQDU\GHDGFRGHUHPRYDO
Constant Pool Optimizations
information, however CPs of different class files of a pro10
3. 3UHOLPLQDU\E\WHFRGHFRPSDFWLRQDOJRULWKP
Format Optimizations
gram may possess
the same information. The Tuk file has
The set of instructions executed by a JVM are called a Global CP 0(GCP) that has constants of all the class files
Input Programs
Java bytecode instructions. TakaTuka has two different but has no redundant information.
Furthermore, instead
(b) FC
kinds5HODWHG:RUN
of bytecode optimizations, namely, single instruc- of using names for dynamic linking at runtime, TakaTuka
tion optimization and multiple instructions optimization.Figure
has4.7:
static
linkingPercentage
that is reduction
carried inout
the three
program
Aggregated
Javaduring
binary using
compaction
schemes
with
LC
and
FC.
These
optimizations
reduce
the
size
of
bytecode.
In
addicompilation.
The
static
linking
does
not
rely
on
the
names
SUN Microsystems:
tion,7KH6TXDZN-DYD9LUWXDO0DFKLQH
the optimized bytecode executes faster. The informa- of class files, functions, and fields stored in the CP. TheretionKWWSUHVHDUFKVXQFRPSURMHFWVVTXDZN
required for the runtime bytecode verification and not fore, the GCP does not have names if they are not used
for the program execution is removed from the Tuk file, in the program. Removing the naming information from
Sentilla:
which
further reduces its size, see [2], [4].
GCP makes it further smaller in size. On the average, the
CLDC
andard
ed with
HV QRW
2YHUYLHZ
86
KWWSMDYDVXQFRPMDYDRQHVIDUWLFOHVJHQBVHQWLOODMVS
11
TAKATUKA — JAVA FOR WIRELESS SENSOR MOTES
Tuk GCP for a given set of programs is 95% smaller than
corresponding regular CP of those programs.
A frame is the data structure used to store local variables
and operand stack of a function. The maximum number
of slots required by the frame of a function is calculated
during creation of class files from the Java source of the
program. In Sun JVM each slot of a frame is exactly 32bit long. This means that data types smaller than 32-bit
(e.g. 16-bit Short) will also be stored in a 32-bit long slot
and that any data type larger than 32-bit will be stored in
multiple slots. We call this a Fixed Slot Size (FSS) scheme
optimized for 32-bit micro-controllers. A wireless sensor
mote usually has either 16-bit or 8-bit micro-controllers,
and has less than 10 KB of RAM. 8-bit micro-controller
can efficiently access a memory in multipless of 8. In order
to save RAM on tiny motes we have designed a Variable
Slot Size (VSS) scheme in which the slot of a frame may be
8-bit, 16-bit or 32-bit long. The results of our studies show
for both 8-bit and 16-bit microcontroller slot sizes that the
slot size of 16-bit saves RAM as well as CPU cycles on a
tiny mote [2]
The garbage collector is a program responsible for automatic memory management as explained. It is invoked
during the program execution and it reclaims objects not
reachable from the root-set. Garbage collection uses additional CPU cycles and may reduce the battery lifetime of
wireless motes. TakaTuka uses an Offline Garbage Collection (GC) to alleviate both of these problems. The Offline
GC allows freeing an object that is still reachable but is
guaranteed not to be used again in the program and frees
valuable RAM earlier than the standard Java garbage collectors.
The Offline GC increases the amount of RAM available
to a program by up to 66% compared to a typical online
garbage collector. Furthermore, the number of CPU cycles
consumed in freeing the memory is reduced by up to 73%
when the Offline GC is used, see [3].
The Offline garbage collection and the VSS both are
designed to increase the RAM availability for a Java program. Due to these optimizations a program with larger
RAM requirements may be executed on a tiny mote that
has only few KBs of RAM. However, the Java binary of
that program must also fit on the flash of a mote that is
used to store programs.
The interpreter is stored on the flash memory of a mote
beside the Java binary of a project. Hence, it is also a
necessary target for optimization. The TakaTuka interpreter has been designed as a set of modules, which allows
the programmer to remove certain modules for reducing
its memory footprint. If, for example, the programmer decides not to use floating point operations he may remove
the floating modules from the interpreter. Furthermore,
the interpreter decreases with the number of unused bytecode instructions.
The interpreter for motes is also be optimized for speed.
In order to reduce the time of instructions dispatch,
the TakaTuka interpreter employs the labels-as-values approach for providing direct threading instead of traditional
3
switch. The labels-as-values approach requires only a small
constant number of comparisons to interpret a bytecode instruction, and thus exhibits better execution time as compared to a switch.
Java programs may need to use hardware drivers including drivers for radio, e.g. Light Emitting Diodes (LEDs)
and sensors. TakaTuka aims at supporting a large variety of hardware platforms, but each hardware platform
may have a different set of drivers. Many existing operating systems that have been developed for the motes
have support for these drivers. However, each operating system has a different set of functions and a model
for the hardware drivers’ support. For example TinyOS
has event-driven model and Contiki operating system has
threading based model. Furthermore, both of these operating systems have different sets of functions for drivers’
support. TakaTuka supports all the existing operating systems, without depending on any one of them. For this, it
provides a set of hardware-independent Java interfaces to
access drivers. The TakaTuka JVM interfaces hide the operating system model and low-level driver functions from
the Java programmer. A programmer, writing his code
using TakaTuka, does not need to know which operating
system is supported by a given mote. The Java code written for one mote may run on any other mote without any
changes even when the mote has a different hardware or
operating system. This is accomplished by providing a
hardware and operating abstraction layer [1].
The current version of the TakaTuka JVM uses the same
power management strategies as implemented in TinyOS
but in future versions, more comprehensive power management are planned.
Debugging in a wireless sensor network is one of the most
difficult problems in programming since the distributed applications may be trigger by unpredictable external events.
TakaTuka provides a Tiny Java Debugger (TJD), which
can monitor and examine the Java source code execution
on a mote without significantly burdening the mote resources. The TJD has been tested on most of the motes
supported by the TakaTuka JVM. Furthermore, it supports
any mote supported by TakaTuka in future with a few or
no changes.
IV. Current Status and the Future of
TakaTuka
TakaTuka has been development from scratch at
the University of Freiburg as an open-source project
(takatuka.sourceforge.com), without employing any existing JVM code. The TakaTuka JVM supports almost all
the bytecode instructions and almost the complete CLDC
library.
At the moment the TakaTuka project is at a transition
step and faces the following challanges. The main development has moved to LUMS at Lahore while the Freiburg
site is currently re-organizing its development team. Furthermore, new partners have signaled their interest in contributing to the future development of TakaTuka. The interests of users of TakaTuka need to be met by providing
87
4
new hardware drivers and continue the support of all hardware platforms.
For this, an international consortium will be formed
which provide developers and users a reliable perspective
for the further development of TakaTuka. Another goal
is to organize and provide funding for the core developer
teams around globe. This consortium will welcome industrial partners which are willing to contribute to this project
and in return supports the commercial use of TakaTuka or
its components as long as the open source status of the
overall project is not compromised.
References
[1] F. Aslam. Challenges and Solutions in the Design of Java Virtual Machine for Resource Constrained Microcontrollers. PhD
thesis, University of Freiburg, Georges-Koehler-Allee 51, 79110
Freiburg, Germany, March 2011.
[2] F. Aslam, L. Fennell, C. Schindelhauer, P. Thiemann, G. Ernst,
E. Haussmann, S. Rührup, and Z. Uzmi. Optimized Java Binary
and Virtual Machine for Tiny Motes. In Distributed Computing
in Sensor Systems (DCOSS), volume 6131, chapter 2, pages
15–30. Springer Berlin Heidelberg, Berlin, Heidelberg, 2010.
[3] F. Aslam, L. Fennell, C. Schindelhauer, P. Thiemann, and Z. A.
Uzmi. Offline gc: Trashing reachable objects on tiny devices.
Accepted for ACM SenSys, 2011.
[4] F. Aslam, C. Schindelhauer, G. Ernst, D. Spyra, J. Meyer, and
M. Zalloom. Introducing takatuka: a java virtualmachine for
motes. In Proceedings of the 6th ACM conference on Embedded
network sensor systems, SenSys ’08, pages 399–400, New York,
NY, USA, 2008. ACM.
[5] N. Brouwers, K. Langendoen, and P. Corke. Darjeeling, a
feature-rich vm for the resource poor. In ACM SenSys, 2009.
[6] O. Corporation. Java card platform specification, v 2.2.2, 2006.
[7] A. engineering.
The NanoVM - Java for the AVR.
http://www.harbaum.org.
[8] J. J. Heiss. Sentilla’s Pervasive Computing – The Universe Is
the Computer. 2008 JavaOne Conference.
[9] J. Koshy and R. Pandey. Vmstar: Sythesizing scalable runtime
environments for sensor networks. In SenSys. ACM Press, 2005.
[10] T. Lindholm and F. Yellin. The Java Virtual Machine Specification. Second Edition, Prentice Hall, 1999.
[11] D. Simon, C. Cifuentes, D. Cleal, J. Daniels, and D. White. Java
on the bare metal of wireless sensor devices: the squawk java
virtual machine. In ACM SIGPLAN VEE, 2006.
88

Sensornetze - Institut für Informatik

Transcrição

Documentos relacionados

Anleitung zur Demontage der

Klausur Sensortechnik WS 09/10 1. Aufgabe 2P 2. Aufgabe 5P 3

MONTAGEANLEITUNG

Werkzeuginnendruck-Sensor Mold Pressure Sen

Robot Kit NIBO burger

Datenblatt

Installationsanleitung_Generationsensor

Download… - Multiplex

sports - 1DayFly.com

Datenblatt herunterladen .