180 likes | 325 Views
Bluetooth and Sensor Networks : A Reality Check. Martin Leopold, Mads Dydensborg, Philippe Bonnet University of Copenhagen. A sensor net for sow monitoring Tracking in large pens Heat period alert Motion detectors Correlation between movement of sows (circles) and their heat period
E N D
Bluetooth and Sensor Networks :A Reality Check Martin Leopold, Mads Dydensborg, Philippe Bonnet University of Copenhagen
A sensor net for sow monitoring Tracking in large pens Heat period alert Motion detectors Correlation between movement of sows (circles) and their heat period Sensor net Interferences Mobile nodes + Fixed infrastructure Sensor nodes 2 years lifetime Low cost Packaged for tough conditions Radio technology is key. Spread spectrum radios are natural candidates. Is Bluetooth a good option? Hogthrob
Off-the-shelf radio Representative of spread-spectrum radios (frequency hopping) Free 2.4 GHz band Promise to be cheap The Bluetooth stack is complex Stripped down version of Bluetooth adapted to constraints of sensor nodes? A Bluetooth module embeds front-end radio, baseband and MAC layer Are 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 study How to build multihop Bluetooth-based networks? Bluetooth is connection-based How 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 level Can applications leverage radio-driven TDM? Bluetooth and Sensor Networks:Promises and Challenges
Pragmatic Approach BTNodes from ETH Zurich Atmega 128 7.32 MHz 128 KiB flash Dual-radio Ericsson’s Bluetooth module ROK 101 007 Port of TinyOS to BTNodes Development of TinyBluetooth Self-Assembly Procedure Application using Radio-level TDM UC Berkeley’s TinyDB on top of TinyBluetooth Performance Evaluation Intrinsic properties Prototype properties Our Approach
Applications Profiles L2Cap Bluetooth Stack Physical Bus Hardware HCI Baseband RF
TinyBluetooth Stack TinyOS Application TinyBluetooth Physical Bus Hardware HCI Baseband RF
Asynchronous Programming Model HCI mapped onto tinyOS events and commands UART events decoupled from HCI events Buffer Trading Buffers swapped between modules Generic Packet type casted into specific packet depending on event/command Interesting information encapsulated inside Bluetooth module TinyBluetooth Stack
Each node is equipped with 2 radios For each node To which node to connect? Connect as master or slave? 3 node configurations: S-S M-M M-S, S-M Self-Assembly Procedure
Building a connection tree as a baseline (BlueTree [Petrioli, Basagni 2002]) Each node has a radio set up as a master, the other as a slave Recursive connection establishment First 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 M M S M M S M S S M M M S M S S S Self-Assembly Procedure S
UC Berkeley’s TinyDB • Push declarative queries into sensor net • Impose a hierarchical routing tree onto the network • Divide time into epochs • Every epoch, sensors evaluate query over (i) local sensor data and (ii) data from children nodes • Aggregate local and children data • Each node transmits just once per epoch • Rest 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?
Connection tree supports hierarchical routing tree. Radio drives TDM Bluetooth 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 Channels No unplanned collisions TinyDB on top of TinyBluetooth M M S M M M S S S
Problem # 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). TinyDB on top of TinyBluetooth M M S M M M S S S
- Point-to-point throughput is high! - The performance we achieve is far from the theoretical max UART limit is 45 Kib/sec Junk sent by Bluetooth module - Slave-to-master and master-to-slave throughput are similar - Throughput degrades for Multipoint connections Throughput • 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.
50mW when idle and 250 mW when communicating Berkeley’s mica motes: 10 mW when idle and 160 mW when communicating Energy Usage Breakdown Maintaining connections is very expensive Different sleep modes!
Node is turned on. Connection on slave radio 1st Connection on master radio 2nd Connection on master radio Master radio is discoverable Data packets are transmittted Disconnections on master radio Disconnection on slave radio Self Assembly
Application Characteristics • Throughput is high • Best suited for applications that transmit lots of data • Energy consumption is high (in particular connections) • Life time of applicatoin must be short (days) • Short periods of connections • Suited for Asynchronous In-Network Processing with radio driven TDM. Bluetooth-Based Sensor Network well suited for short lived deployments With unplanned burst of data with high throughput (images, video).
Conclusion • Code available in TinyOS contrib directory • More info on our project home page: http://www.distlab.dk/manatee • This study is a baseline for: • Intel motes • 802.15.4 radios • Tailored radios relying on Bluetooth front-end (Pico Radio)