Wireless Sensors Discovery in Sleeping

presented by: Ted Herman, University of Iowa

March/April 2011, Vietnam

Introduction Technical Problems Neighbor Discovery

Plan of Presentation

Introduce topics of Wireless Sensor Networks, and show some technical apects
1 2 3

why wireless sensor networks? what are the problems? some ideas about neighbor discovery

2 / 46

Introduction Technical Problems Neighbor Discovery

Wireless Embedded Computing

Wireless Embedded Computing Vision
Dream 1: Ubiquitous Computing - always connected

computing (= cloud computing + smart phone)

Dream 2: Spimes, Sensors on Web - sensing data, putting in

cloud (measure temperature, light, in smart phone)

Dream 3: Pervasive Computing - a world of smart objects

(cars, buildings, roads, machines) - embedded computers everywhere, sensing and adapting to changes works even without cloud
3 / 46

Introduction Technical Problems Neighbor Discovery

Wireless Embedded Computing

Wireless Embedded Computing Vision

Dream 4: Extended Sensing

what if you can know where is trac, be aware if grandmother is OK, nd out if heat is on/o at home, . . . these things are like sensing from a distance, enabled by sensors placed in our lives, with networked (wireless) communication

4 / 46

Introduction Technical Problems Neighbor Discovery

Sensor Types

What kinds of sensors? Small, low-power sensors now made for: temperature, dark/light, CO2 , vibration, pressure, ultrasound, movement Future small sensors will include: special chemicals, biological agents, radiation, visual patterns, radar, . . .

5 / 46

Introduction Technical Problems Neighbor Discovery

Current WSN Applications

Wireless Sensor Networks (WSN) Applications

monitor supply chain (inventory, transportation) security (shipping containers, borders) factory equipment (overheating, vibration) infrastructure (bridges, buildings) precision agriculture (vineyards, greenhouses) scientic experiments (measuring precisely)

6 / 46

Introduction Technical Problems Neighbor Discovery

Example: Jindo Bridge, South Korea

7 / 46

Introduction Technical Problems Neighbor Discovery

Example Bridge Sensor Hardware

8 / 46

Introduction Technical Problems Neighbor Discovery

Other Sensor Deployments

Sensors in Use 1 Aircraft: hundreds of sensors (Airbus communicates sensor data by radio in real time)
2

Vehicles: expensive vehicles may use hundreds of sensors (lookup wireless hack) RFID in supply chain: location, and even other attributes like temperature, vibration

Some usage, but wireless sensor networks very limited!

9 / 46

Introduction Technical Problems Neighbor Discovery

What are the Problems?

What is needed for future? Some technical problems to solve, for more widespread use of Wireless Sensor Networks: battery problems, radio problems, reliability, standards, . . . Two Main Practical Problems 1 Cost. They are still too expensive ( $100)
2

Software. We need fault tolerant, exible software for these very small devices

10 / 46

Introduction Technical Problems Neighbor Discovery

Sensor Cost Problem

Cost Factors 1 processor, memory, radio cost $5$50 (depending on features)
2 3

board, enclosure, batteries, antenna cost $20$100 sensors (temperature, acceleration, etc) cost $1-$10

Comparison Note: cell phone processor is 100x more powerful than wireless sensor (But, cell phone consumes 10-100x more energy) Currently, some cell phones cost less than a wireless sensor! Why? Scale of manufacturing & competition
11 / 46

Introduction Technical Problems Neighbor Discovery

Software Problems
Challenges in Wireless Sensor Networks well-known research problems 1 Localization: how does sensor know where it is?
2 3

Clock Synchronization: how does sensor know what time it is? Power Conservation: how can sensors optimize battery life (and perhaps gain power from environment, from vibration, heat, sun)? Routing: how can sensors cooperate to forward data to the world? Neighbor Discovery: how can sensors discover other sensors?

12 / 46

Introduction Technical Problems Neighbor Discovery

Localization
Problem: nd (x, y ) or even (x, y , z) coordinates of sensors. (Maybe sensors are dropped from airplane, maybe put randomly in some area.) Some Solution Ideas 1 maybe a few sensors can have GPS they are called anchor nodes
2

sensing by ultrasound, by radar, or radio strength can estimate distances between sensors from distances, each sensor can build a local map by messages between sensors, local maps are exchanged put together local maps to get big map of all sensor locations

3 4 5

13 / 46

Introduction Technical Problems Neighbor Discovery

Localization

14 / 46

Introduction Technical Problems Neighbor Discovery

Clock Synchronization
Problem: each sensor has a clock, but how to make all clocks in network the same? Some Solution Ideas 1 one sensor node is connected to internet, or has high-quality hardware clock that is accurate
2

messages carry time from accurate clock to nearby (neighbor) sensors neighbors tell their neighbors, etc technical diculty: messages may collide, then nobody gets message! hardware radio inserts random delay, to reduce collisions but random delay makes clocks unsynchronized!
15 / 46

3 4

5 6

Introduction Technical Problems Neighbor Discovery

Synchronization
Best Case: random delay is known (access part is random amount)

16 / 46

Introduction Technical Problems Neighbor Discovery

Synchronization
Other Case: random delay is discovered later

17 / 46

Introduction Technical Problems Neighbor Discovery

Power Conservation and Harvesting

What Consumes or Supplies Power? 1 sensors, local computing, radio consume power
2 3

batteries supply limited power ( 1.2 Amp Hours typical) ultra low-power sleep modes available (no radio, no sensing) sensor node could last for years, if mostly sleeping duty-cycle alternate sleep, wake periods (coordinated in network) active research: harvest solar power, energy from vibration, heat, . . .

18 / 46

Introduction Technical Problems Neighbor Discovery

Routing
1 2 3

sensors must forward data to base station for eciency, sensor data can be aggregated in network some research: sensor network is queried like SQL data base!

19 / 46

Introduction Technical Problems Neighbor Discovery

Neighbor Discovery

Purpose: we look more in depth at one problem what if most sensors use duty cycle to sleep most of time, to save power How can a sensor know if a new sensor was added to network? What happens if sensor has batteries replace? What if a sensor reboots and forgets who are neighbors? Such events motivate neighbor discovery (hard, because radio is turned o most of time)

20 / 46

Introduction Technical Problems Neighbor Discovery

BREAK OF PRESENTATION
BREAK OF PRESENTATION: A Puzzle! Puzzle of Election 1 n sensors, in line network (only communicate with limited range)
2 3 4 5

each sensor has ID from [0, 264 ] all have synchronized clocks, starting from 0 puzzle: choose one sensor as leader using only n messages solution done when every sensor knows ID of leader

21 / 46

Introduction Technical Problems Neighbor Discovery

Methods of Neighbor Discovery

Survey of Techniques Hardware Ideas

Wake by Radio (like

RFID) - messages received wake up sensor

Tiny Samples - very brief

Software Ideas (Classical Computer Science) - use patterns of wake/sleep to discover awake neighbor
patterns must intersect

each other
assume radio on for

wakeup to sample radio waves

known interval (long enough for discovery)

22 / 46

Introduction Technical Problems Neighbor Discovery

Basic Notions in Discovery Problem

Slotted Time (relax this later) although node clocks may be unsynchronized, assume time is divided into slots and the slots are aligned Awake vs Asleep Slots for each node, some slots are asleep (radio o), others are awake Duty Cycle over time, ratio of awake time to sleep time should be /1 duty cycles of 5%, 1%, 0.02%, . . . desired for good lifetime (goals depend on application requirement)

23 / 46

Introduction Technical Problems Neighbor Discovery

B-MAC: Radio Sampling

Radio Activity Sample (CCA) (CCA designed for sensing to prevent collisions)
CCA quick, low-power wakeup to sample radio Idea: if sample looks like probable activity, then wake fully &

read
not a feature of all radios (only a few)

24 / 46

Introduction Technical Problems Neighbor Discovery

B-MAC Low-level Behavior

Leftmost peak is the sample, later peak is start of reading. If the sample sees no radio activity, then crystal oscillator does not start.

25 / 46

Introduction Technical Problems Neighbor Discovery

B-MAC Tradeo
Problem of Sampling The time taken after a sample, to turn on the radio ( 2ms) makes it too late to receive the message! Solution: longer messages
1

change message format: increase the frame preamble (bytes for synchronizing the start of a frame) enough to enable listeners to receive the message alternative: back-to-back duplicate frames sent implicit tradeos:
transmittors use more power, listeners use less power some bandwidth loss due to more bytes transmitted

2 3

26 / 46

Introduction Technical Problems Neighbor Discovery

B-MAC Evaluation
B-MAC implemented in TinyOS as LPL (Low-Power

Listening)
duty cycles reported in 0.52.5% range packet delivery success reported 98% (carefully tuned

sampling)
better than previous MAC protocols using CTS/RTS (5-10%

duty cycles)
success depends on hardware factors (CCA, bandwidth,

transmission power costs)

favors some application types over others (some

compute-sense tasks would interfere with real-time radio sampling; other applications need longer sleep periods and lower duty cycles)
27 / 46

Introduction Technical Problems Neighbor Discovery

IEEE 802.11 Research

Slot types: AW (active window), BW (beacon window), MTIM (RTS, CTS, ACK, data)

28 / 46

Introduction Technical Problems Neighbor Discovery

Intersecting Patterns
Power-Saving Mode introduce sleeping as part of beacon interval (periodic) for duty cycle

unsynchronized nodes may never see each other! Simple Solution Require AW > BI /2 + BW idea: if nodes are awake over half the time, there is overlap
29 / 46

Introduction Technical Problems Neighbor Discovery

Intersecting Patterns

Quorum Solution 1 not all periods contain sleep intervals

2 3

for some parameter n, let 1/n of the periods be totally awake assumption: periods overlap enough for unsynchronized nodes to see each other n > space of node IDs nodes use xed quorum to choose all-awake intervals, based on ID

4 5

30 / 46

Introduction Technical Problems Neighbor Discovery

Intersecting Patterns

31 / 46

Introduction Technical Problems Neighbor Discovery

The Birthday Protocol

Fact: given enough persons, some two will probably have same birthday randomized sleeping
node states: T, L, S (transmit, listen, sleep) modes: BLT, BL (birthday-listen-transmit or birthday-listen) each node randomly choses (depending on mode) which of T,

L, S to do
upon entry to BL: pt = 0, p = , ps = 1 p upon entry to BLT: pt = t , p = , etc

Like birthdays, high probability some are awake at same time (what to do after that . . . ?)
32 / 46

Introduction Technical Problems Neighbor Discovery

Birthday Example

33 / 46

Introduction Technical Problems Neighbor Discovery

Theory of Patterns

Model Schedules as Block Designs

each node has on/o schedule of T slots goal: discover neighbors within one scheduling period (one

duty cycle)
goal: deterministic, static cycle denition

34 / 46

Introduction Technical Problems Neighbor Discovery

Theory of Patterns
denitions
schedule for node v is given by fv =

ai {0, 1} for on/o, x i is slot number

T 1 i i=0 ai x

where

fvk (x) = x k fv (x) mod (x T 1) cyclic shift by k slots

j C (u, v ) = minj,k | fu fvk | the (worst case) overlap Problem: design f so that C (u, v ) m for all u, v

let kv = fv (1) (duty-cycle) for symmetric designs, ku = kv

for all u, v
necessary condition: C (u, v ) m km kv m T corollary: k

m T (for symmetric designs)

35 / 46

Introduction Technical Problems Neighbor Discovery

Theory of Patterns
Schedules follow a symmetric (v , k, ) design (node row)

(Block Design theory found in most Discrete Mathematics Textbooks)

36 / 46

Introduction Technical Problems Neighbor Discovery

Theory of Patterns

considerations for block design protocol fast, deterministic discovery

can tune amount of overlap desired in design but, design requires knowing number of nodes each node needs individual pattern patterns irregular (dicult for some hardware/applications) higher duty cycle than other protocols: ( T ) (note, T has

to be large enough to accommodate number of nodes)

37 / 46

Introduction Technical Problems Neighbor Discovery

Discovery using Primes

The DISCO Protocol 1 wake schedule based on Chinese Remainder Theorem (note: schedules based on primes are in literature of wakeup problem)
2 3 4

choose two primes p, q such that 1/p + 1/q duty cycle cycle length at least max(p, q) number slots of cycle 1,2,3,. . . , then wake in slot i when i mod p = 0 or i mod q = 0 (in a cycle, a node may wake more than once) eventually, neighbors must wake in common slot

38 / 46

Introduction Technical Problems Neighbor Discovery

Discovery using Primes

39 / 46

Introduction Technical Problems Neighbor Discovery

Discovery using Primes

discovery rate may not be uniform ?!

40 / 46

Introduction Technical Problems Neighbor Discovery

Temporal Partition

no-cost vs probing no-cost protocols: each cycle has awake and sleep intervals
(each period is contiguous, unlike several other schemes) no-cost schedules based on primes selection of primes randomized (periodically) to assure

intersection
probing protocols add additional awake slots to speed up

discovery

41 / 46

Introduction Technical Problems Neighbor Discovery

Temporal Partition

no-cost protocol parameter S is upper bound on how long a node may sleep
duty cycle is 1/z for z S each synchronized group of nodes act identically duty cycle determined by max(p, q), for primes p, q each synchronized group pseudorandomly chooses from {p, q} choice is held for 2z cycles (after that, choose again)

42 / 46

Introduction Technical Problems Neighbor Discovery

Temporal Partition

no-cost protocol results

discovery of neighbor occurs in O(z 2 ) slot times discovery for graph occurs in O(diam z 2 ) slots times

43 / 46

Introduction Technical Problems Neighbor Discovery

Temporal Partition

extra-cost protocols each cycle can have two awake intervals, normal and probing
probing interval consists of c consecutive slots trivial: c > z/2 assures fast discovery but with smaller c, need to increment start position in each

cycle
duty cycle is (1 + c)/z (normal is 1 slot) discovery upper bound is O(z 2 /c) slot times

44 / 46

Introduction Technical Problems Neighbor Discovery

Temporal Partition

randomized probing protocols use one extra slot for probing

selection of probing slot is random (per node) in each cycle result for clique topology: expected discovery of all nodes is

O((log z + log log n) z) slot times

45 / 46

Introduction Technical Problems Neighbor Discovery

END OF PRESENTATION
END OF PRESENTATION: A Puzzle 1 There are 5 doors, numbered 1, 2, 3, 4, 5
2 3 4 5 6

Behind each door is a room doors are closed Each door is labeled by its number, on both sides Two persons are in dierent rooms; other rooms are empty Operation: person can send a message to any numbered room Time is synchronous, starting with 1, then 2, 3, . . . with both persons starting at time 1

Challenge: devise a protocol guaranteeing that one person will send a message to the other with at most 3 total messages (not 3 per person, but 3 in total)
46 / 46