Bluetooth and Sensor Networks : A Reality Check

  • View

  • Download

Embed Size (px)


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 - PowerPoint PPT Presentation

Text of Bluetooth and Sensor Networks : A Reality Check

  • 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.

    123Aggregate38.125.419.3Per Slave38.112.76.4







    20 bytes payload

    668 bytes payload (max)

    Theoretical max

    Bluetooth Encoding

    Throughput (kb/sec)



    Master-Slaveasymetric comms

    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)

    Theoretical max

    Bluetooth Encoding

    Throughput (kb/sec)



  • 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: 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.

    Complex stack

    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)

    Serial Connection

    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