25-08-2017, 09:32 PM
Bluetooth and Sensor Networks: A Reality Check
[attachment=26226]
ABSTRACT
The current generation of sensor nodes rely on commodity components. The choice of the radio is particularly important as it impacts not only energy consumption but also
software design (e.g., network self-assembly, multihop routing
and in-network processing). Bluetooth is one of the most
popular commodity radios for wireless devices. As a representative
of the frequency hopping spread spectrum radios,
it is a natural alternative to broadcast radios in the context
of sensor networks. The question is whether Bluetooth
can be a viable alternative in practice. In this paper, we
report our experience using Bluetooth for the sensor network
regime. We describe our tiny Bluetooth stack that
allows TinyOS applications to run on Bluetooth-based sensor
nodes, we present a multihop network assembly procedure
that leverages Bluetooth’s device discovery protocol,
and we discuss how Bluetooth favorably impacts in-network
query processing. Our results show that despite obvious
limitations the Bluetooth sensor nodes we studied exhibit
interesting properties, such as a good energy per bit sent
ratio. This reality check underlies the limitations and some
promises of Bluetooth for the sensor network regime.
INTRODUCTION
It is now possible to develop software for sensor networks
and to conduct experiments using sensor nodes readily available
through research groups or commercial companies.
These sensor nodes, based on commercial off-the-shelf components,
guarantee a good trade-off between cost (of development
and production), reliability and performance. One
of the key differences between sensor nodes is their radio
component: it impacts not only energy consumption but
also software design (network self-assembly, multihop routing
and in-network processing).
We can distinguish two types of radio components for
sensor nodes: those based on fixed frequency carriers, i.e.,
all sensor nodes within communication range compete for a
shared channel in order to transmit data, and those based on
spread-spectrum transmissions such as Bluetooth, i.e., sensor
nodes within communication range use separate channels to
transmit data. Roughly, the former type of radio favors connectionless
data broadcast while the latter favors connection
oriented communications. In this paper, we focus on the use
of Bluetooth modules as radio components for sensor nodes.
Bluetooth was initially designed as a cable replacement
technology. Does it make sense to consider it in the context
of sensor networks? Spread spectrum radios are serious candidates
for sensor network usage because of their resilience
to interferences (notably in the free 2.4 GHz band). The
WINS prototypes from UCLA, for instance, relied on this
type of radio. The mass production of Bluetooth radios ensures
robustness and decreasing costs. Bluetooth modules
are thus valid candidates, but how suited are they to the
sensor network regime?
• A Bluetooth module embeds both the physical layer
and the MAC layer through the three bottom layers of
the Bluetooth stack (baseband, link manager and host
controller interface). As a consequence there is no need
to implement a MAC layer as part of the sensor node
software. Is the Bluetooth MAC layer, based on channel
reservation through frequency hopping, adapted to
the sensor network regime? How much of an overhead
is a Bluetooth module embedded on a sensor node?
• The Bluetooth protocol is complexwit h its sixla yers
and its drastic compliance requirements. Is it possible
to define a stripped down version of the Bluetooth
software stack adapted to the footprint requirement of
a sensor node?
• Bluetooth’s multihop capabilities (scatternets) have
been announced for years. However these announce-
103
ments have not been backed up by product releases.
How can we establish a multihop network with Bluetooth
based sensor nodes?
• A typical assumption in sensor networks is that each
sensor node can communicate with its neighbors to
collect information used for collaborative signal processing,
routing or in-network processing. Because
Bluetooth-based sensor nodes have to establish connections
before they send or receive data, a Bluetoothbased
sensor network can only be operational after a
self-assembly phase during which connections are established.
What is an appropriate network-assembly
algorithm relying on Bluetooth’s device discovery
mechanism?
• When two devices are connected, one of them is a master
and the other a slave. Nodes are arranged in clusters
composed of one master and up to seven slaves.
Slaves are following the hopping sequence dictated by
the master and they are only allowed to transmit data
once the master has contacted them. During network
assembly, the choice of masters and slaves is not neutral.
If node A is sending data to node Bwhat is
the impact of the choice of master and slave? What
is the impact of the number of slaves connected to the
master?
• Proposals for in-network query processing [11] assume
that the underlying radio supports connectionless data
broadcast. What is the impact of Bluetooth on these
proposals? In particular, they rely on the introduction
of time division multiplexing (TDM) at the application
level to synchronize the transmission and processing of
data across nodes. Does Bluetooth alleviate the need
for application based TDM?
Because we favour a pragmatic approach, we have decided
to experiment with actual Bluetooth-based devices in order
to study these questions. We chose the BTnodes developed
at ETH Zurich [10]. The BTnodes rely on an Atmel microcontroller
similar to the one used in the Berkeley motes [4].
Because no Bluetooth module currently supports scatternets,
we equipped the BTnodes with two radios in order to
enable multihop networking. Using two radios, it is possible
to combine clusters of Bluetooth nodes into a multihop
topology. This decision was inspired by the dual-radio node
design from Sensoria [16]. The BTnodes are detailled in
Section 2.
In this paper, we report our experience with Bluetoothbased
sensor nodes. Specifically, we make the following contributions:
1. We designed and implemented a tiny Bluetooth stack
for TinyOS. We decided to use TinyOS [9] and port
it to the BTnodes in order (a) to benefit from its programming
model for the design and implementation of
our stripped down Bluetooth stack and (b) to benefit
from the library of existing components. We measured
the code footprint as well as the throughput and the
energy consumption on the BTnodes running our Tiny
Bluetooth stack.
2. We developed a network assembly procedure that leverage
Bluetooth’s device discovery protocol. Our procedure
is inspired by BlueTree [20] and is adapted to
the configuration of the BTnodes with two radios. We
measured the latency and energy consumption of our
procedure.
3. We adapted the in-network query processing approach
of TinyDB for a Bluetooth-based sensor network. We
focused on the TDM scheme managed by TinyDB to
drive query processing on individual nodes.
Our results suggest that Bluetooth based sensor networks
could be appropriate for a niche of applications, such as
mounted operations in urban terrain, that necessitate heavy
data exchanges during a few criticial periods within a timeframe
of up to a week.
BTNODES
The BTnodes were developed by ETH Zurich in the context
of the Smart-Its project [15]. They are based on the
Atmel ATmega128L microcontroller - an 8 bit microcontroller
(MCU) clocked at 7.4 MHz, with 4 KiB1 on chip
memory and an external memory chip of up to 64 KiB. The
MCU has digital and analog I/O ports that can be used to
connect external sensor devices through Molex plugs on the
edge of the board. The nodes are equipped with a Bluetooth
module (Ericsson ROK 101 007) together with an onboard
antenna. Two UARTs connect the MCU with the embedded
Bluetooth chip and one of the Molexpl ugs. Four leds can
be used for debugging purposes. The board also contains
a voltage regulator: the BTnode can be plugged to power
supplies ranging from 3.3 V to 12 V.
[attachment=26226]
ABSTRACT
The current generation of sensor nodes rely on commodity components. The choice of the radio is particularly important as it impacts not only energy consumption but also
software design (e.g., network self-assembly, multihop routing
and in-network processing). Bluetooth is one of the most
popular commodity radios for wireless devices. As a representative
of the frequency hopping spread spectrum radios,
it is a natural alternative to broadcast radios in the context
of sensor networks. The question is whether Bluetooth
can be a viable alternative in practice. In this paper, we
report our experience using Bluetooth for the sensor network
regime. We describe our tiny Bluetooth stack that
allows TinyOS applications to run on Bluetooth-based sensor
nodes, we present a multihop network assembly procedure
that leverages Bluetooth’s device discovery protocol,
and we discuss how Bluetooth favorably impacts in-network
query processing. Our results show that despite obvious
limitations the Bluetooth sensor nodes we studied exhibit
interesting properties, such as a good energy per bit sent
ratio. This reality check underlies the limitations and some
promises of Bluetooth for the sensor network regime.
INTRODUCTION
It is now possible to develop software for sensor networks
and to conduct experiments using sensor nodes readily available
through research groups or commercial companies.
These sensor nodes, based on commercial off-the-shelf components,
guarantee a good trade-off between cost (of development
and production), reliability and performance. One
of the key differences between sensor nodes is their radio
component: it impacts not only energy consumption but
also software design (network self-assembly, multihop routing
and in-network processing).
We can distinguish two types of radio components for
sensor nodes: those based on fixed frequency carriers, i.e.,
all sensor nodes within communication range compete for a
shared channel in order to transmit data, and those based on
spread-spectrum transmissions such as Bluetooth, i.e., sensor
nodes within communication range use separate channels to
transmit data. Roughly, the former type of radio favors connectionless
data broadcast while the latter favors connection
oriented communications. In this paper, we focus on the use
of Bluetooth modules as radio components for sensor nodes.
Bluetooth was initially designed as a cable replacement
technology. Does it make sense to consider it in the context
of sensor networks? Spread spectrum radios are serious candidates
for sensor network usage because of their resilience
to interferences (notably in the free 2.4 GHz band). The
WINS prototypes from UCLA, for instance, relied on this
type of radio. The mass production of Bluetooth radios ensures
robustness and decreasing costs. Bluetooth modules
are thus valid candidates, but how suited are they to the
sensor network regime?
• A Bluetooth module embeds both the physical layer
and the MAC layer through the three bottom layers of
the Bluetooth stack (baseband, link manager and host
controller interface). As a consequence there is no need
to implement a MAC layer as part of the sensor node
software. Is the Bluetooth MAC layer, based on channel
reservation through frequency hopping, adapted to
the sensor network regime? How much of an overhead
is a Bluetooth module embedded on a sensor node?
• The Bluetooth protocol is complexwit h its sixla yers
and its drastic compliance requirements. Is it possible
to define a stripped down version of the Bluetooth
software stack adapted to the footprint requirement of
a sensor node?
• Bluetooth’s multihop capabilities (scatternets) have
been announced for years. However these announce-
103
ments have not been backed up by product releases.
How can we establish a multihop network with Bluetooth
based sensor nodes?
• A typical assumption in sensor networks is that each
sensor node can communicate with its neighbors to
collect information used for collaborative signal processing,
routing or in-network processing. Because
Bluetooth-based sensor nodes have to establish connections
before they send or receive data, a Bluetoothbased
sensor network can only be operational after a
self-assembly phase during which connections are established.
What is an appropriate network-assembly
algorithm relying on Bluetooth’s device discovery
mechanism?
• When two devices are connected, one of them is a master
and the other a slave. Nodes are arranged in clusters
composed of one master and up to seven slaves.
Slaves are following the hopping sequence dictated by
the master and they are only allowed to transmit data
once the master has contacted them. During network
assembly, the choice of masters and slaves is not neutral.
If node A is sending data to node Bwhat is
the impact of the choice of master and slave? What
is the impact of the number of slaves connected to the
master?
• Proposals for in-network query processing [11] assume
that the underlying radio supports connectionless data
broadcast. What is the impact of Bluetooth on these
proposals? In particular, they rely on the introduction
of time division multiplexing (TDM) at the application
level to synchronize the transmission and processing of
data across nodes. Does Bluetooth alleviate the need
for application based TDM?
Because we favour a pragmatic approach, we have decided
to experiment with actual Bluetooth-based devices in order
to study these questions. We chose the BTnodes developed
at ETH Zurich [10]. The BTnodes rely on an Atmel microcontroller
similar to the one used in the Berkeley motes [4].
Because no Bluetooth module currently supports scatternets,
we equipped the BTnodes with two radios in order to
enable multihop networking. Using two radios, it is possible
to combine clusters of Bluetooth nodes into a multihop
topology. This decision was inspired by the dual-radio node
design from Sensoria [16]. The BTnodes are detailled in
Section 2.
In this paper, we report our experience with Bluetoothbased
sensor nodes. Specifically, we make the following contributions:
1. We designed and implemented a tiny Bluetooth stack
for TinyOS. We decided to use TinyOS [9] and port
it to the BTnodes in order (a) to benefit from its programming
model for the design and implementation of
our stripped down Bluetooth stack and (b) to benefit
from the library of existing components. We measured
the code footprint as well as the throughput and the
energy consumption on the BTnodes running our Tiny
Bluetooth stack.
2. We developed a network assembly procedure that leverage
Bluetooth’s device discovery protocol. Our procedure
is inspired by BlueTree [20] and is adapted to
the configuration of the BTnodes with two radios. We
measured the latency and energy consumption of our
procedure.
3. We adapted the in-network query processing approach
of TinyDB for a Bluetooth-based sensor network. We
focused on the TDM scheme managed by TinyDB to
drive query processing on individual nodes.
Our results suggest that Bluetooth based sensor networks
could be appropriate for a niche of applications, such as
mounted operations in urban terrain, that necessitate heavy
data exchanges during a few criticial periods within a timeframe
of up to a week.
BTNODES
The BTnodes were developed by ETH Zurich in the context
of the Smart-Its project [15]. They are based on the
Atmel ATmega128L microcontroller - an 8 bit microcontroller
(MCU) clocked at 7.4 MHz, with 4 KiB1 on chip
memory and an external memory chip of up to 64 KiB. The
MCU has digital and analog I/O ports that can be used to
connect external sensor devices through Molex plugs on the
edge of the board. The nodes are equipped with a Bluetooth
module (Ericsson ROK 101 007) together with an onboard
antenna. Two UARTs connect the MCU with the embedded
Bluetooth chip and one of the Molexpl ugs. Four leds can
be used for debugging purposes. The board also contains
a voltage regulator: the BTnode can be plugged to power
supplies ranging from 3.3 V to 12 V.