Speed/RAP/CODA Presented by Octav Chpara Real-tme Systems Many wreless sensor network applcatons requre real-tme support Survellance and trackng Border patrol Fre fghtng Real-tme systems: Hard real-tme: guarantee deadlnes Soft real-tme: mprove mss rato Dfferentaton Real-tme Systems Concerned wth two aspects: Control RAP Prortzaton SPEED CODA Modelng the sensor networks A sensor: Lmted memory Lmted processng Communcaton: Scarce bandwdth Vods exst Energy ntensve Communcaton generates congeston hotspots MAC layer may provde QoS end-to-end communcaton tme depends on sngle-hop delay and the dstance t has to travel Modelng the sensor networks Tght ntegraton wth the physcal world Locaton aware Communcaton patterns: Local coordnaton Sensors coordnate wth one another [usually by defnng a group] n order to aggregate data Usually nvolves a small number of hops Sensor-base communcaton Sends data from the local group to the base staton Requres multple hops RAP 1
Contrbutons A hgh level archtecture for large wreless networks Ablty to defne queres Use event servces Velocty Monotonc Schedulng (VMS) A polcy for schedulng packets n a sensor network Desgn Goals Provde APIs for mcro-sensng and control Maxmze the number of packets meetng ther EE deadlnes Scale well to large number of nodes and hops Introduce mnmum communcaton overhead RAP Stack Query/Event Servce API Query attrbute lst area tme constrants querer locaton When an event s detected, the query s started and perodcally generates result Locaton-Addressed Protocol Connectonless transport layer Address s based on geographc locaton Servces: Uncast Delver a node closest to the destnaton Area multcast Delver to all nodes n an area Area anycast Delver to any node n the area Geographc forwardng Greedy algorthm Selects the node wth the shortest geographc dstance to the packet s destnaton At every step the packet gets closer to the destnaton Works really good for hgh densty network
Velocty Monotonc Schedulng FCFS polcy s generally used n sensor networks Works poorly for real-tme systems VMS It s both deadlne and dstance aware Assgns prorty based on the requested velocty A hgher velocty denotes hgher prorty Velocty Monotonc Schedulng() Statc monotonc velocty (SMV) (xs,ys) v = ( x x ) + ( y y ) s d D Dynamc monotonc velocty (DMV) s (xd,yd) (xs,ys) (xd,yd) d Tj (x,y) v = ( x x ) + ( y y ) d D T j d 80.11 Overvew 80.11 has two coordnaton functons Pont Coordnaton Functon (PCF) Dstrbuted Coordnaton Functon (DCF) Two access methods Basc access method RTS/CTS 80.11 Basc mechansm A staton montors the channel If the channel s free for more than DIFS the staton transmts Before transmttng we wat for a random delay Else, the channel contnues to montor the channel untl t s free for DIFS To avod capture effect, the staton needs to wat for a perod of tme before sendng the next packet Dscrete tme backoff as multple of the number of slots σ s the amount of tme needed for any staton to detect transmsson 80.11 Basc mechansm () Exponental backoff Chosen for an unform dstrbuton (0, w-1), where w s the contenton wndow The sze of the contenton wndow ncrease exponentally wth the number of faled attempts to send the message CW mn mnmum contenton wndow CW max = m CW mn maxmum contenton wndow 80.11 Basc mechansm (3) We retry to resent the message when the backoff counter reaches zero The backoff counter s decremented only when the channel s dle The counter s reset to zero n the case of a successful transmsson 3
MAC layer prortzaton When communcatng multple host compete for the shared medum In 80.11b all messages have the same prorty To enforce packet prortzaton MAC protocols should provde dstrbuted prortzaton on packets from dfferent nodes We can changed two parameters The tme you can wat after dle DIFS = BASE_DIFS * PRIORITY Backoff ncrease functon CW=CW*( + (PRIORITY-1)/MAX_PRIORITY) Experments Routng protocols Dynamc Source Routng (DSR) GF Schedulng FCFS DS fxed prorty based on ther ee deadlne Velocty Schedulng DVS SVS Overall Mss Rato of GF/DSR Usng VMS SPEED State of the art Only a few real-tme algorthms exst for sensor networks Routng based on sensor s poston GPSR GR LAR 4
Desgn Goals Speed Protocol Stateless Informaton regardng the only the mmedate neghbors Soft Real Tme Provdes unform speed delvery across the network Mnmum MAC Layer support Traffc load-balancng Localzed behavor Vod avodance Soft Real-tme Where s the tme constrant? SPEED ams at provdng a unform packet delvery speed across the sensor network, so that the end-to-end delay of a packet s proportonal to the dstance between the source and destnaton. Wth ths servce, real-tme applcatons can estmate end-toend delay before makng admsson decsons. Delay dfferentaton for dfferent classes of packets s left as future work. Try to send the packet at Ssetpont Neghbor beacon exchange scheme Perodcally broadcasts a beacon to neghbors to exchange locaton nformaton In order to reduce traffc we can pggyback the nformaton Assume all neghbors ft n the neghborhood table Possble enhancement: Advertsng state changes may reduce number of beacons On-demand beacons Delay estmaton Back pressure pressure Felds: Neghbor ID Poston Send To Delay TTL Delay estmaton algorthm Due to scarce bandwdth cannot use probe packets Delay s measured at the sender as the dfference between when the packet was queued and ts ACK and the processng tme on the recever tme t0 p delay = 1 0 t t p Delay estmaton algorthm () Delay estmaton beacon s used to communcate to other neghbors the estmated delay Goal: allow nodes react to changes n traffc patters [avod congeston] t1 Keeps track of multple data ponts to compute the current delay usng (EWMA): average = average* α + delay*( α 1) 5
FS ( destnaton) = { n NS L Lnext > 0} SNGF Neghbor set of node NS = { n d( n, ) < range( )} Forwardng canddate set FS ( destnaton) { n NS L L > 0} = next Where L = d(, destnaton) Lnext = d(next, destnaton) Relay speed j L Lnext Speed ( destnaton) = HopDelay j SNFG() Load balancng If ( FS > 0) { The node wth the hghest relay speed has the hghest Vable( FS ) = { j FS speed probablty j ( dest) Sof setpont beng } chosen. f ( Vable > 0) { canddate=choose(vable(fs)) send to canddate } else { compute relay rato f no nodes to support Ssetpont downstream, drop packet f a random chosen between (0,1) s bgger than the relay rato } } else { drop packets send pressure beacon upstream } SNFG(3) Delay Bound = L ee / S setpont Where: L ee s the end-to-end Eucldan dstance measured S setpont the speed mantaned across the network Drawbacks: All messages have the same speed Does not take nto account the lnk qualty [same ssue as GF] Better measure of congeston Neghbor feedback loop Goal: Mantan a sngle hop speed above a desred Ssetpont Ssetpont s a network wde parameter that tunes how harsh the real-tme requrements are Neghbor feedback loop Back pressure reroutng Reroutng due to pressure The congested area s detected and the probablty of sendng to that node s lmted 6
Back pressure reroutng() Issue: Maybe renforcement should refer to a geographc area rather than a node! Other ways of thnkng about congeston Congeston detecton Samplng Queue length Backpressure Closed-loop mult-source regulaton Overall approach: Under a threshold there s no need to check for congeston. Above t, we want to detect and control congeston. Vod avodance Vods occur f the densty s not hgh enough Deals wth vods smlarly to hotspots by applyng backbone pressure Several packets may be dropped when tryng to avod a vod Last mle processng Processng close to the destnaton area Area anycast Area multcast EE Mss Rato Ssetpont = 1km/s ee deadlne = 00 ms 7
Improvng Speed Crtques and Possble Improvements Is the delay estmaton correct?!? Combne SPEED and RAP Energy conservaton s only secondary concern n the paper All neghbors can ft n the routng table Needs to be manually tuned Multple veloctes Can we do better for long runnng flows? How to handle moble users? Can we use power control? 8
Questons? 9