Bluetooth and Sensor Networks :A Reality Check
Martin Leopold, Mads Dydensborg, Philippe BonnetUniversity of Copenhagen
HogthrobA sensor net for sow monitoringTracking in large pensHeat period alertMotion detectorsCorrelation between movement of sows (circles) and their heat period Sensor netInterferencesMobile nodes + Fixed infrastructureSensor nodes2 years lifetimeLow costPackaged for tough conditions
Radio technology is key.Spread spectrum radios are natural candidates.Is Bluetooth a good option?
Bluetooth and Sensor Networks:Promises and ChallengesOff-the-shelf radioRepresentative of spread-spectrum radios (frequency hopping)Free 2.4 GHz bandPromise to be cheapThe Bluetooth stack is complexStripped down version of Bluetooth adapted to constraints of sensor nodes? A Bluetooth module embeds front-end radio, baseband and MAC layerAre standard Bluetooth physical layer and MAC layer adapted to the sensor network regime?Multihop capabilities Scatternet support has been announced for years but was not supported at the time of our studyHow to build multihop Bluetooth-based networks?Bluetooth is connection-basedHow to define network self-assembly based on Bluetooth device discovery. What is the impact on performance?Bluetooth implements Time Division Multiplexing (TDM) at the radio levelCan applications leverage radio-driven TDM?
Our ApproachPragmatic ApproachBTNodes from ETH ZurichAtmega 128 7.32 MHz128 KiB flashDual-radio Ericssons Bluetooth module ROK 101 007Port of TinyOS to BTNodesDevelopment of TinyBluetoothSelf-Assembly ProcedureApplication using Radio-level TDMUC Berkeleys TinyDB on top of TinyBluetoothPerformance EvaluationIntrinsic propertiesPrototype properties
Bluetooth StackRFBasebandHCIPhysical Bus Hardware
TinyBluetooth StackRFBasebandHCIPhysical Bus HardwareTinyBluetoothTinyOS Application
TinyBluetooth StackAsynchronous Programming ModelHCI mapped onto tinyOS events and commandsUART events decoupled from HCI events Buffer TradingBuffers swapped between modulesGeneric Packet type casted into specific packet depending on event/commandInteresting information encapsulated inside Bluetooth module
Self-Assembly ProcedureEach node is equipped with 2 radiosFor each nodeTo which node to connect?Connect as master or slave?3 node configurations: S-SM-MM-S, S-M
Self-Assembly ProcedureBuilding a connection tree as a baseline (BlueTree [Petrioli, Basagni 2002])Each node has a radio set up as a master, the other as a slaveRecursive connection establishmentFirst slave radio is turned on.One node is chosen as the root of the connection tree. Master radio turned on once a connection is established on slave radio.Rely on Bluetooth device discovery and connection establishment
UC Berkeleys TinyDBPush declarative queries into sensor netImpose a hierarchical routing tree onto the networkDivide time into epochsEvery epoch, sensors evaluate query over (i) local sensor data and (ii) data from children nodesAggregate local and children dataEach node transmits just once per epochRest of the time, sensors sleep (deep microcontroller sleep)The TDM is driven by the application: How long should sensors sleep? What if interesting data needs to be transmitted while sensors sleep?
TinyDB on top of TinyBluetoothConnection tree supports hierarchical routing tree.Radio drives TDMBluetooth radio in Sniff mode: Master and Slaves agree on synchronization points (ideally once per epoch). Rest of time sensor node sleeps or senses. Microcontroller waken up on radio signal. Pipelined aggregation along the routing tree.Separated ChannelsNo unplanned collisionsMMMSSSSMM
TinyDB on top of TinyBluetoothProblem # 1: The sniff period is not longer than 40 secs.
Problem # 2: When a connection is in sniff mode, the microcontroller sleeps in idle mode (which is less efficient than the power save mode according to the Atmel specs).
Code Size Breakdown
DescriptioncodebssdataSupport & TinyOS core1180UART 0 & Interrupts3464UART1 & Interrupts2925hciPacket0604155hciPacket1588155hciCore01624159hciCore11590159Assembly Component4796102116Total11020165816
Throughput- Point-to-point throughput ishigh!- The performance weachieve is far from the theoretical maxUART limit is 45 Kib/secJunk sent by Bluetooth module- Slave-to-master andmaster-to-slave throughputare similar- Throughput degrades forMultipoint connections
DM and DH are two encoding schemes. DM offers a lower error rate. 1, 3 and 5 corresponds to the number of consecutive slots during which slaves and masters communicate.
20 bytes payload
668 bytes payload (max)
20 bytes payload668 bytes payload (max)Theoretical max
1,3,5 slot packetsDM13.85.713.6
M: medium(high noise resistance9DM54.716.559.73
H: high(lower ...)DH54.725.590.4
UART limit 460000 b/s (raw)
20 bytes payload
668 bytes payload (max)
Energy Usage Breakdown50mW when idle and 250 mW when communicatingBerkeleys mica motes: 10 mW when idle and 160 mW when communicatingMaintaining connections is very expensiveDifferent sleep modes!
Self AssemblyNode is turned on.Connection on slave radio1st Connection on master radio2nd Connection on master radioMaster radio is discoverableData packets are transmitttedDisconnections on master radioDisconnection on slave radio
Application CharacteristicsThroughput is highBest suited for applications that transmit lots of dataEnergy consumption is high (in particular connections)Life time of applicatoin must be short (days)Short periods of connectionsSuited for Asynchronous In-Network Processing with radio driven TDM.Bluetooth-Based Sensor Network well suited for short lived deploymentsWith unplanned burst of data with high throughput (images, video).
Lessons LearnedIntrinsic Bluetooth PropertiesIt is feasible to develop a Bluetooth stack for TinyOS devicesEncapsulation within Bluetooth module hurts Frequency hopping hurts (40 sec period for sniff mode)Inquiry, connection establishment is slowBetter engineering might improveScatternet supportCost of connection maintenanceThroughput maxdecrease on point-to-multipoint
ConclusionCode available in TinyOS contrib directoryMore info on our project home page: http://www.distlab.dk/manateeThis study is a baseline for:Intel motes802.15.4 radiosTailored radios relying on Bluetooth front-end (Pico Radio)
Time to convince you that Bluetooth was a valid technology for SN.
BT is a cable replacement technology. Most products cable replacement : point to point connections (head sets, phone)
Demo (Intel Motes) showed that Bluetooth is an alternative in the context of SN.
Bluetooth characteristics -> what apps?
Given an app -> is Bluetooth appropriate?DK, 5m people, 20m pigs
Pig industry, first exporting industry
Hogthrob: project with other danishInstitutions
Goal: a sensor net for sow monitoring
Sensor net is characterized by
The following constraints applyTo the sensor nodes
Whether we are choosing existing nodesOr designing our own:Radio technology is keyAs interferences are important, a spread spectrum radio seems like a natural choiceThe question is whether Bluetooth is a good candidate
Bluetooth is a representative of the spread spectrum class of radios (separated channels) desirable because resilient to interferencesFrequency hopping (master connected to up to 8 slaves). Master determines the hopping sequence.
Most flexible way to incorporate Bluetooth in an embedded system is to use a Bluetooth module that encapuslates the radio front-end, the baseband and the MAC layer.
ConnectionsIt is necessary to build connections before data can be transmitted.Context of SN, connection paths need to be established between Snodes. Constructing the neighbor list for each node. Network self assembly.
Questions we wanted to study.To do so, we decided to go for a pragmatic approach.
Implementation (baseline version of stripped down version of protocol, self-assembly)Performance evaluation
Typical BT stack (Bottom Up)
Timing sensitive lower layers (BT module) separated from compute intensive higher layers.
BT moduleRFPhysical (FH) MAC (HCI, device discovery, piconet mgt)
Higher layersAbstract application from module- Hide heterogeneity- High level abstraction (e.g., RF com)
Tiny Bluetooth stackThin layer on top of BT module.Wrapper around HCI layer.Executed on Atmel microcontroller,Integrated to TinyOS.
UART existing tinyOS componentHCICore exposes HCI commandsHCI packet intermediate abstractionlayer
(Btnode do not communicate with external nodes, connectionless l2cap)
Mapping HCI tinyOS straightforward
Key aspect of implementation is memory management: buffer trading
More details in paper
Interesting info not available:timing infoStatus of transmissions
Stripped down version of BT
How to use BT device discovery in the context of a SA proce