CS 546: Intelligent Embedded Systems Gaurav S. Sukhatme Robotic Embedded Systems Lab Center for Robotics and Embedded Systems Computer Science Department University of Southern California

Last time –Sensors –Networking Today –HW3 –Time synchronization basics –Firefly paper –RBS paper

Today Memory Processor InterfaceSensor and actuator suite Energy supply External communication Platform OS and SW architecture Tools User interface Application Figure adapted from [Pottie and Kaiser 2005] 1/24, 4/18: Cyclops 1/31: Networking 2/21: Energy management 4/18: Cyclops 2/7,14 and 28: Time synch, localization and data management 3/21,28 and 4/11: Environmental monitoring

Why Time Synch? To time-stamp measurements To perform in-network signal processing For localization For cooperative communication For medium access For sleep scheduling (energy management) For coordinated actuation

Key Issues Clock = crystal + timer circuitry Clock is incremented after K ticks or interrupts by the timer Low-end systems = cheap crystal and unreliable timer circuitry Clocks are jittery, unstable, and error prone in real systems

Basic Model Real frequency is modeled as the sum of an ‘ideal’, an offset, a drift term, and random noise Oscillator model Initial time Value of Clock C at time t

Simplified Model Drop drift and random term to obtain a linear model Clock offset at reference time t=0Clock drift Ideal clock has α=0 and β=1 Clock is said to be fast if β>1 and slow if β<1

Synchronization Manufactured clocks usually have a maximum drift rate parameter ρ such that 1- ρ < β < 1+ ρ For a typical mote ρ ~ 40 ppm, giving a drift rate of ±40 μs Two synchronized clocks can drift apart at a maximum rate of 2ρ Suppose we want to always keep relative offset between two clocks bounded by δ seconds => synchronization every δ/2ρ seconds (or more often)

Synchronization: Simple Approaches Periodic broadcast of a global clock (UTC – Universal Coordinated Time) –Such a clock needs to be consistent and high quality (e.g. US NIST WWV, WWVH, WWVB) –WWVB is a 60kHZ carrier, 50kW signal transmitter, accurate to 1μs but comm delays allow receiver synch ~10μs Satellite-based GPS receiver –~1μs, but expensive, and only work in unobstructed environments

Requirements Quality – vary from ~0.1μs to ~10-100ms Scope –All nodes synched to a global external references vs. local sync between neighbors only Consistency –All nodes synched at all times vs. intermittent or post facto synch Costs –Energy, convergence time, equipment

Approaches to Time-synch Original approach by Lamport Cristian’s algorithm and its (hierarchical) NTP implementation Fine grained –RBS –TPSN (pair wise receiver-sender) –Linear parameter-based –FTSP (flooding) –Predictive –Firefly (biologically inspired oscillator entrainment) Coarse grained –Wisden - an alternative to true time-synch (retroactive time stamping)

Lamport Consistent ordering of all events in a distributed system Label each event x with a distinct time stamp Lx such that –Lx not equal to Ly for all unique x and y –If x precedes y within a node then Lx <Ly –If x is a message transmission at one node and y is its receipt at another node then Lx<Ly Lamport timestamps do not provide true causality. If true times of x and y are Tx and Ty then –Tx Lx < Ly but –Lx< Ly does not imply Tx < Ty

Cristian Two node clock synch –A sends request to B (which has a reference clock) –B sends clock value T B to A –A records transmission time T 1 and reception time T 2 Simple estimate for propagation time is (T 2 -T 1 )/2 If processing delay is known to be D then better estimate is (T 2 – T 1 – D)/2 Even better if you do several round trip samples and use minimum or mean delays after removing outliers NTP is essentially a hierarchy of time servers and a cascaded implementation of Cristian’s algorithm

Factors Affecting Message Latency Send time: processing time and time to assemble and move message to link layer Access time: random delays while message is buffered at link layer due to contention and collisions Propagation time: point to point travel time (small for one link, dominant over multiple hops depending on network congestion) Receive time: processing and recording message arrival

RBS (more later) Exploit broadcast Beacon node B broadcasts reference signal Received by receivers A and C simultaneously (assume insignificant propagation delay) A and C record received time A and C exchange local time stamps Key feature is the elimination of sender-side uncertainty Can be extended to multihop

TPSN Timing-synch protocol for sensor networks Cristian’s algorithm –A stamps a mesg locally as T1 and sends to B –B stamps the received time as T2 –B send mesg to A (stamped locally at B as T3) –A stamps the received mesg as T4 Let the offset between A and B be Δ and the propagation delay be d T2 = T1 + Δ + d T4 = T3 – Δ + d, thus Δ = [(T2 – T4) – (T1 – T3)]/2 d = [(T2 + T4) – (T1 + T3)]/2 Network-wise synch using a level-by-level structure

Linear Parameter-based Synch Provide bounds for relative clock drift and offset Recall for two clocks A and B C A = α A +β A t and C B = α B +β B t Eliminate t to get C A = α AB +β AB C B Two constraints T 1 < α AB +β AB T 2 T 4 > α AB +β AB T 3

FTSP Flooding time synch protocol Reduce uncertainties of RBS and TPSN –Interrupt handling time (delay between processor and radio) –Modulation/encoding time (delay at the radio) FTSP broadcasts an actual time measurement from single sender to multiple receivers. Receivers do not synch among themselves Fine tuning –Multiple time measurements at byte boundaries –Flooded messaging

Predictive time synch Frequency of inter-node sampling is adjusted based on drift prediction

Reachback Firefly Algorithm (more later) Biologically inspired synch Not timestamping Fully decentralized and heavily fault tolerant

Coarse grained Data Synch WISDEN –Collect and record latency measurements in each packet in a special field –Retroactively timestamp at the base station when packet arrives Only base station needs an accurate reference clock

Next week Localization HW 3 is due a week from today