Create Presentation
Download Presentation

Download Presentation

Optimal QoS-aware Sleep/Wake Scheduling for Time Synchronized Sensor Networks

Optimal QoS-aware Sleep/Wake Scheduling for Time Synchronized Sensor Networks

105 Views

Download Presentation
## Optimal QoS-aware Sleep/Wake Scheduling for Time Synchronized Sensor Networks

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -

**Optimal QoS-aware Sleep/Wake Scheduling for Time**Synchronized Sensor Networks CISS 06 Yan Wu, Sonia Fahmy, Ness B. Shroff Center for Wireless Systems and Applications(CWSA) Purdue University**Application specific networks**• Habitat monitoring, military surveillance etc • Sensor Nodes • Unattended during their life cycle • Limited in processing/communication capabilities • Constrained in battery life time • One large application class: Continuous Monitoring • Examples: habitat monitoring, civil structure maintenance • Nodes monitor the environment and periodically upload sensing data to a Base Station Wireless Sensor Networks**Continuous Monitoring Applications**• Duty cycle is usually low • Clustering is often used [1] • Nodes in the same neighbourhood elect a cluster head (CH) • 2-step communication: intra-cluster and inter-cluster • Cluster Head (CH) is heavily utilized • To extend the lifetime of the CH • Re-clustering – extensively investigated • Sleep/wake scheduling – our interest • Idle energy is significant for low duty cycle networks • Turn off the CH radio when no transmissions • Wake it up right before transmissions occur • Good match with periodic traffic pattern • [1] S. Tilak, N. B. Abu-Ghazaleh, and W. Heinzelman. A taxonomy of wireless micro-sensor network models. ACM Mobile Computing and Communication Review, April 2002.**Motivation**• Under periodic traffic pattern • If time synchronization is perfect Sleep/wake scheduling of CH will be trivial • Most previous sleep/wake scheduling work assumes perfect synchronization--This assumption is not always true! • Existing synchronization protocols[2] achieve precise (µs) synchronization immediately after exchange of synchronization messages • But clock drifts away as time progresses • E.g., two nodes exchange a message every 5 minutes • Motes datasheet: max clock skew = 100ppm • After 5 minutes, clock disagreement = 30ms • Larger than message transmission time in sensor networks • Synchronization error is non-trivial! [2] J. Elson, L. Girod, and D. Estrin. Fine-Grained Network Time synchronization Using Reference Broadcasts. In Proceedings of OSDI, 2002.**Motivation (summary)**• Environment • Continuous monitoring applications with periodic transmissions • Network has already been clustered using some existing clustering algorithm. • Problem • Cluster Head (CH) is heavily utilized • Goal: save energy for CH via sleep/wake scheduling • Difficulty • Trivial if synchronization is perfect • But in practice synchronization is imperfect and synchronization error is non-negligible Sleep/wake scheduling with consideration of synchronization error**Outline**• Motivation • Review Time Synchronization • System model • Problem definition • Solution • Conclusions and future work**Time Synchronization**• Why are clocks different from each other? • Phase offset: clock disagreement at a given time instant • Clock skew: clocks run with different speed • May slowly change over time Synchronization is to estimate phase offset and clock skew • Mechanism -- exchange messages to synchronize • Example: one node sends a message to another • Uncertainty: sender (random backoff), receiver (PHY/MAC layer) Random Estimation Error • Many synchronization protocols try to reduce the uncertainty • RBS[2]/TPSN[3] • [2] J. Elson, L. Girod, and D. Estrin. Fine-Grained Network Time synchronization Using Reference Broadcasts. In Proceedings of OSDI, 2002. • [3] S. Ganeriwal, R. Kumar, and M. Srivastava. Timing-sync Protocol for Sensor Networks. In Proceedings of ACM SenSys, November 2003.**A single cluster with a CH and M members:n1, …nM**• Each member uploads to the CH every T seconds System Model • Time is divided into epochs • Epoch = Synchronization interval + Transmission interval**System Model**• Assumptions • Neighbouring clusters use orthogonal frequency channels • Focus on intra-cluster communications • Clock skew and phase offset are constant over each epoch • Only account for communication energy • Synchronization Scheme in This Work • Adopt the widely used RBS[2] synchronization scheme • RBS Procedure • Exchange sync. messages to obtain multiple corresponding time pairs • Use linear regression to estimate clock skew and phase offset**RBS Synchronization Scheme**• C: time of CH, tx : time of member x • a/b: clock skew/phase offset • a’/b’: estimation of a/b • Recall that clock skew and phase offset are constant over an epoch • For a given epoch, tx = a×C + b • RBS • Obtain Ns corresponding time pairs (txi, Ci) i=1…Ns txi = a×Ci + b + ei, ei: random error • System measurements show that ei is normally distributed • Chi-square test, 99.8% confidence level • Use linear regression to estimate a and b • The existence of ei causes estimation error: (a’, b’) ≠(a, b)**Outline**• Motivation • Review Time Synchronization • System model • Problem definition • Solution • Conclusions and future work**Problem Definition**• CH and the member x agree upon a message send time t (CH clock) • x should transmit at t by CH clock (scheduled send time) • x coverts t into its own clock: tx = a’× t + b’ and transmits at tx • The actual send time is tx (x’s clock), express it using CH clock τ = (tx – b)/a = a’/a × t + (b-b’)/a Ifthere is no estimation error, (a’, b’)=(a, b), thenτ =t But there exists random estimation error, so τ≠ t Because of estimation error, message may not be sent at scheduled time. • How does the CH combat the estimation error? • Uses a wake up interval to “capture” the message**Question: how early should the CH wake up and how long**should it stay active? • wakes up early and stays up long -- wastes energy • wakes up late and stays up short -- miss msg. Trade-off between energy consumption and message capture probability! • Guarantee a minimum message capture probability th • Minimize the expected energy consumption Problem Definition**Sleep/wake scheduling – considering sync. error**• Minimize the expected energy consumption under constraint on capture probability Minimize: such that where: w: wake up time s: sleep time τ: actual message arrival time l: message length R: data rate : idle/receiving power : Probability Density Function of τ th: QoS parameter Problem Definition**Outline**• Motivation • Review Time Synchronization • System model • Problem definition • Solution • Conclusions and future work**Computing PDF**τ = a’/a × t + (b-b’)/a • a’/b’ are computed from standard Linear Regression • sync. error is Normal τ is also Normal E(τ) = t, VAR(τ) Solution Sketch**Put the PDF into the formulation**• Change of variable: x=[w-E(τ)]/στ, y =[s-E(τ)]/στ • Minimize: such that • Non-convex optimization problem • Compute the Hessian Matrix • Cannot directly solve it using conventional techniques Solution Sketch**Solution Sketch**• Proposition: optimal solution satisfies Q(x)-Q(y) = th • Meaning: optimum is achieved when capture_probability=th • Put this result into F(x,y)**Simplified Formulation**Minimize such that • Solve the simplified formulation • Proposition: G”(x) >0 Proof:Implicit Differentiation and Mean Value Theorem • The simplified formulation is convex**Performance Evaluation**• A previous scheme to combat sync. error • Assume an upper bound on the clock disagreement and use it as a guard time • Simulation results • In order to guarantee the same capture performance, the energy consumption of our scheme is 20-40% less than the previous scheme**So far**• Assumed capture probability threshold th is already given • Extension -- How to assign th for different nodes n1, … nM? • Uniform assignment: assign same value to all nodes • Problem: heterogeneity among nodes • Some nodes: expensive high-precision thermometer • Others: cheap low-precision thermometer Differentiated Assignment**Conclusions**• This work • Studied sleep/wake scheduling in clustered networks • Identified the impact of sync. error on sleep/wake scheduling • Proposed an optimal sleep/wake scheduling scheme with consideration for sync. error • Simulations validate the effectiveness of our scheme • Future work • This work • Focus on intra-cluster communications (memberCH) • CH Base Station? • Future work • Inter-cluster communications -- Multi-hop**RBS**• Receiver-receiver synchronization • Nodes A and B want to synchronize with each other • Requires an additional beacon node C • Procedure • Beacon Node send reference beacons to A and B • A and B record the arrival time of the beacon, tA and tB • A and B compare the arrival times • Properties • Removes completely randomness caused by the sender • Leaves only one source of error – receiver**Clock skew**• crystal oscillator • expected frequency: the frequency that it should work. • actual frequency: might differ from expected frequency. • Accuracy: <100 ppm • Decided by manufacturing imprecision and aging effect • Affected by environment factors like variations in temperature, humidity etc. • Slow changing • For off-the-shelf oscillator, clock skew < 100pm**Transmission Error**• Not considered in the current formulation • During cluster construction, nodes will select nearby CH • Error probability should not be very large • In case of transmission error, our scheme is still robust • Prob(receive) = Prob(capture) * (1-Pe)**Adaptive adjustment of the wake up interval**• Idea: a message not received synchronization is wrongadjust the wake up interval for next message • Implicit assumption: message not received is only caused by wrong synchronization • Not necessarily true: message not received might also be caused by transmission error**Retransmission**• No retransmissions • Retransmissions need acknowledge mechanism, cost energy • Sensor networks usually deployed with redundancy**Problem definition**• CH and member x • The difference between them is 10 minutes. • They estimate the difference to be 10 minutes • CH tells x: “Send the message to me at 6pm.” • x will compute: ”CH’s 6pm is my 6:10” and send at 6:10pm (by its own clock) • Now suppose their difference is 10 minutes, but they estimate the difference to be 9 minutes. • X will compute: “CH 6pm is my 6:09”transmit at 6:09 by its own clock 6:09 in x is 5:59pm in CH, not 6pm in CH!