Αλγόριθµοι Κατασκευής Επικαλυπτικού ένδρου Κατανεµηµένα Συστήµατα Ι Μάθηµα Βασικής Επιλογής, Χειµερινού Εξαµήνου Τοµέας Εφαρµογών και Θεµελιώσεων Ιωάννης Χατζηγιαννάκης Πέµπτη, 22 Νοεµβρίου, 2007 Αίθουσα Β3 Πρόβληµα Κατασκευής Επικαλυπτικού ένδρου Ενα επικαλυπτικό δέντρο T(G) ενός δικτύου G περιέχει όλες τις διεργασίες του δικτύου (κορυφές) και ορισµένα (ίσως όλα) κανάλια επικοινωνίας (ακµές). Η κατασκευή ενός επικαλυπτικού δέντρου προυποθέτει την επιλογή µιας διεργασίας u0 που ϑα είναι η ϱίζα του δέντρου T(G). Οταν η κατασκευή ολοκληρωθεί, όλες οι διεργασίες πρέπει κατ ελάχιστον να γνωρίζουν την διεργασία γονέα τους στο δέντρο. Σε ορισµένες εφαρµογές είναι απαραίτητο κάθε διεργασία να γνωρίζει επιπλέον στοιχεία όπως το ύψος της στο δέντρο. Αυτόµατο Εισόδου/Εξόδου Είσοδος προς το δίκτυο -- interface SendMsg Ολοι οι αλγόριθµοι µπορούν να περιγραφούν µε τον ίδιο τρόπο όταν ϑέλουµε να ορίσουµε την λειτουργικότητα που προσφέρουν στα υψηλότερα επίπεδα ενός συστήµατος Η διεργασία P u init(id)u joined()u Για την ενέργεια εξόδου send(m)u,v χρησιµοποιούµε το interface SendMsg ReceiveMsg.nc Η κατάσταση της Pu καθορίζεται από τις τιµές των άλλων διεργασιών αν έχει ανακοινώσει την απόφαση της Οι ενέργειες εισόδου είναι της µορφής init(id)u και receive(m)v,u Οι ενέργειες εξόδου είναι της µορφής joined()u και send(m)u,v send(m)u,v Pu receive(m)v,u i n t e r f a c e SendMsg { command r e s u l t _ t send ( uint16_t address, uint8_t length, TOS_MsgPtr msg ) ; event r e s u l t _ t senddone ( TOS_MsgPtr msg, r e s u l t _ t success ) ;
Εξοδος προς το δίκτυο -- interface ReceiveMsg Είσοδος/ Εξοδος στα ανώτερα επίπεδα (1) Ορίζουµε το interface SpanningTreeControl ως εξής: Για την ενέργεια εισόδου receive(m)v,u χρησιµοποιούµε το interface ReceiveMsg ReceiveMsg.nc i n t e r f a c e ReceiveMsg { event TOS_MsgPtr receive ( TOS_MsgPtr m) ; command result_t init(uint16_t deviceid) αρχικοποιεί τις εσωτερικές µεταβλητές του αλγόριθµου. Η παράµετρος deviceid υποδηλώνει την ταυτότητα που ϑα χρησιµοποιήσει η διεργασία κατα την κατασκευή του επικαλυπτικού δέντρου. Το command επιστρέφει πάντα SUCCESS command result_t start() ξεκινά τη διαδικασία κατασκευής του επικαλυπτικού δένδρου. Επιστρέφει πάντα SUCCESS. event result_t joined(uint16_t parentid, uint16_t height) όταν ο κόµβος συνδεθεί στο επικαλυπτικό δέντρο, δηµιουργείται ένα event όπου η παράµετρος parentid δηλώνει την ταυτότητα του κόµβου-γονέα στο δέντρο και η παράµετρος height δηλώνει το ύψος του κόµβου στο δένδρο. Το event επιστρέφει πάντα SUCCESS. Είσοδος/ Εξοδος στα ανώτερα επίπεδα (2) Ορίζουµε το interface SpanningTreeControl ως εξής: command uint16_t getparentid() επιστρέφει την ταυτότητα του κόµβου-γονέα στο δένδρο, αλλιώς UNKNOWN_PARENT. Για την ϱίζα του δέντρου επιστρέφει την ταυτότητα της διεργασίας. command uint8_t getstatus() επιστρέφει JOINED αν η διεργασία έχει συνδεθεί στο δέντρο, αλλιώς NOT_JOINED. command result_t getheight() επιστρέφει το ύψος του κόµβου στο επικαλυπτικό δένδρο (0 αν είναι η ϱίζα, αυξάνεται όσο πλησιάζουµε προς τα ϕύλλα). SpanningTreeControl.nc i n t e r f a c e SpanningTreeControl { async command result_ t i n i t ( uint16_t deviceid ) ; async command uint16_t getparentid ( ) ; async command uint8_t getstatus ( ) ; async command u i n t 8 _t getheight ( ) ; async command result_ t start ( ) ; event r e s u l t _ t j o i n e d ( u i n t 1 6 _t leaderid, uint1 6 _t height ) ;
Κατασκευή Επικαλυπτικού έντρου Αυτόµατο AsynchSpanningTree u (1) Αλγόριθµος AsynchSpanningTree Οι διεργασίες διατηρούν µια µεταβλητή µαρκαρισµένη η οποία αρχικά είναι false και µια µεταβλητή γονέας µε αρχική τιµή 0. Αρχικά, η διεργασία u0 ϑέτει την µεταβλητή µαρκαρισµένη ως true, την µεταβλητή γονέας µε την ταυτότητα της, και στέλνει ένα µήνυµα αναζήτησης σε όλους τους γείτονες της. Σε κάθε γύρο, εάν µια διεργασία λάβει ένα µήνυµα αναζήτησης και η τιµή της µεταβλητής µαρκαρισµένη είναι false, τότε ϑέτει την µεταβλητή σε true, ϑέτει την µεταβλητή γονέας µε την ταυτότητα της διεργασίας από όπου έλαβε το µήνυµα, και στον επόµενο γύρο στέλνει ένα µήνυµα αναζήτησης σε όλους τους γείτονες της. Ενέργειες: Ενέργειες Εισόδου in(asynchspanningtree u ) 1. receive( search )u,v, όπου v nbrs Ενέργειες Εξόδου out(asynchspanningtree u ) 1. send( search )u,v, όπου v nbrs 2. parent(v)u, όπου v nbrs Καταστάσεις: parent nbrs {null -- αρχικά null reported -- τύπου boolean, αρχικά false. για κάθε v nbrs -- send(v) {search, null -- αρχικά search αν u = u0, αλλιώς null Αυτόµατο AsynchSpanningTree u (2) Χαρακτηριστικά του Αλγόριθµου AsynchSpanningTree Μεταβάσεις: send( search )u,v προϋπόθεση -- send(v) == search αποτέλεσµα -- send(v) = null receive( search )u,v parent(v)u αποτέλεσµα αν u u0 και parent == null τότε parent = v για κάθε k nbrs v -- send(k) = search προϋπόθεση -- parent == v, reported == false αποτέλεσµα -- reported = true Ο αλγόριθµος AsynchSpanningTree κατασκευάζει ένα επικαλυπτικό δέντρο Η απόσταση µιας διεργασίας απο την u0 δεν είναι η ίδια στο G και στο T(G) Η πολυπλοκότητα επικοινωνίας είναι O (m) Χρονική πολυπλοκότητα: εν παρατηρούνται συνωστισµοί µηνυµάτων Ολες οι διεργασίες ϑα έχουν επιλέξει γονέα εντός χρόνου δ(l + d) + l
AsynchSpanningTreeM.nc AsynchSpanningTreeM.nc module AsynchSpanningTreeM { p r o v i d e s { i n t e r f a c e SpanningTreeControl ; uses { i n t e r f a c e SendMsg ; i n t e r f a c e ReceiveMsg ; enum { UNKNOWN_PARENT = 65534, JOINED = 1, NOT_JOINED = 0 ; implementation { u i n t 1 6 _ t m_id ; u i n t 1 6 _ t m_parentid ; u i n t 8 _ t m_joined ; TOS_Msg m_msg ; / /... οµή Μηνυµάτων οµή Μηνυµάτων του AsynchSpanningTree /opt/tinyos-1.x/tos/types/am.h # define TOSH_DATA_LENGTH 29 typedef s t r u c t TOS_Msg { u i n t 1 6 _ t addr ; u i n t 8 _ t type ; u i n t 8 _ t group ; u i n t 8 _ t length ; int8_ t data [TOSH_DATA_LENGTH ] ; u i n t 1 6 _ t crc ; u i n t 1 6 _ t strength ; u i n t 8 _ t ack ; u i n t 1 6 _ t time ; u i n t 8 _ t sendsecuritymode ; u i n t 8 _ t receivesecuritymode ; TOS_Msg ; AsynchSpanningTree.h typedef s t r u c t SpanningTreeMsg { u i n t 1 6 _ t id ; SpanningTreeMsg ; enum { AM_SPANNINGTREEMSG = 15 ;
Ουρά FIFO µε µηνύµατα ιασύνδεση Το TinyOS υλοποιεί ένα component για την τοποθέτηση µηνυµάτων σε FIFO ουρά. Προσφέρει το interface SendMsg και απαιτεί ένα interface SendMsg Στην ουσία το συνδέουµε στο interface SendMsg του αλγορίθµου µε το interface SendMsg του GenericComm Κάθε ϕορά που κάνουµε send το µήνυµα µπαίνει αυτόµατα στην ουρά η ουρά αναλαµβάνει την τελική αποστολή c o n f i g u r a t i o n AsynchSpanningTree { provides interface StdControl ; provides i n t e r f a c e SpanningTreeControl ; implementation { components AsynchSpanningTreeM, QueuedSend, GenericComm ; AsynchSpanningTreeM. SendMsg > QueuedSend. SendMsg [AM_SPANNINGTREEMSG ] ; AsynchSpanningTreeM. ReceiveMsg > GenericComm. ReceiveMsg [AM_SPANNINGTREEMSG ] ; S t d C o n t r o l = GenericComm ; S t d C o n t r o l = QueuedSend ; SpanningTreeControl = AsynchSpanningTreeM ; async command result_ t SpanningTreeControl. i n i t ( uint16_t deviceid ) { atomic { m_joined = NOT_JOINED ; m_id = deviceid ; m_parentid = UNKNOWN_PARENT ; dbg (DBG_BOOT, " AsynchSpanningTree : i n i t i a l i z e d. \ n " ) ; r e t u r n SUCCESS ; async command r e s u l t _ t SpanningTreeControl. s t a r t ( ) { u i n t 1 6 _ t parentid ; atomic parentid = m_parentid ; / / Check i f already f i n i s h e d i f ( parentid! = UNKNOWN_PARENT) r e t u r n FAIL ; dbg (DBG_USR1, " AsynchSpanningTree : s t a r t e d \n " ) ; / / Send search message post sendsearchmessage ( ) ; r e t u r n SUCCESS ;
t a s k void sendsearchmessage ( ) { / / Access message body SpanningTreeMsg msgdata = ( SpanningTreeMsg ) m_msg. data ; / / Set message contents atomic msgdata >i d = m_id ; / / T r y to send the message c a l l SendMsg. send ( TOS_BCAST_ADDR, sizeof ( SpanningTreeMsg ), &m_msg ) ; event r e s u l t _ t SendMsg. senddone ( TOS_MsgPtr msg, bool success ) { / / Report t h a t process j o i n e d the t r e e post reportjoined ( ) ; r e t u r n SUCCESS ; dbg ( DBG_TEMP, " AsynchSpanningTree : Sending \tmsg(%d)\ n ", msgdata >id ) ; event TOS_MsgPtr ReceiveMsg. receive ( TOS_MsgPtr recv_packet ) { SpanningTreeMsg msgdata = ( SpanningTreeMsg ) recv_packet >data ; u i n t 1 6 _ t joined ; atomic joined = m_joined ; / / Check i f we have already j o i n e d the t r e e i f ( j o i n e d == NOT_JOINED ) { atomic { m_parentid = msgdata >id ; j o i n e d = JOINED ; post sendsearchmessage ( ) ; r e t u r n recv_packet ; task void reportjoined ( ) { u i n t 1 6 _ t parentid ; atomic parentid = m_parentid ; dbg (DBG_BOOT, " AsynchSpanningTree : j o i n e d. \n " ) ; s i g n a l SpanningTreeControl. j o i n e d ( parentid, 0 ) ;
οκιµαστική Εφαρµογή async command u i n t 1 6 _ t SpanningTreeControl. getparentid ( ) { r e t u r n m_parentid ; async command u i n t 8 _ t SpanningTreeControl. getstatus ( ) { r e t u r n m_joined ; Θέλουµε µια απλή εφαρµογή για να ελένξουµε τον αλγόριθµο Να µετρίσουµε την απόδοση του σε διαφορετικές τοπολογιες Η εφαρµογή δίνει µια ταυτότητα στον αλγόριθµο και όταν τελειώσει εξάγει το αποτέλεσµα χρησιµοποιώντας καποια LED async command u i n t 1 6 _ t SpanningTreeControl. getheight ( ) { r e t u r n 0 ; Χρήση Timer lab2appm.nc Εφόσον έχουµε να κάνουµε µε ένα ασύγχρονο σύστηµα, υπάρχει περίπτωση οι συσκευές να µη ξεκινήσουν ταυτόχρονα αλλά να υπάρχει µια χρονική καθηστέριση. Θέλουµε να εξασφαλίσουµε ότι όλες οι συσκευές του συστήµατος είναι ενεργοποιηµένες και συµµετέχουν στην εκλογή αρχηγού. Χρησιµοποιούµε ένα Timer για να καθυστερήσουµε την εκτέλεση του αλγόριθµου. module lab2appm { p r o v i d e s { interface StdControl ; uses { i n t e r f a c e SpanningTreeControl ; i n t e r f a c e Leds ; interface Timer ; implementation { / /...
lab2appm.nc / / I n i t i a l i z e the component. command r e s u l t _ t S t d C o n t r o l. i n i t ( ) { c a l l Leds. i n i t ( ) ; call SpanningTreeControl. i n i t (TOS_LOCAL_ADDRESS ) ; r e t u r n SUCCESS ; / / Start things up / / s e t the t i m e r to f i r e once a f t e r 1000ms command r e s u l t _ t StdControl. s t a r t ( ) { r e t u r n c a l l Timer. s t a r t (TIMER_ONE_SHOT, 1 0 0 0 ) ; lab2appm.nc / / H a l t execution of the a p p l i c a t i o n / / d i s a b l e s the clock component. command r e s u l t _ t StdControl. stop ( ) { r e t u r n c a l l Timer. stop ( ) ; / / S t a r t the t r e e c o n s t r u c t i o n event r e s u l t _ t Timer. f i r e d ( ) { post starttreeconstruction ( ) ; r e t u r n SUCCESS ; lab2appm.nc task void starttreeconstruction ( ) { / / S t a r t the t r e e c o n s t r u c t i o n process i f ( TOS_LOCAL_ADDRESS == 0) { c a l l SpanningTreeControl. s t a r t ( ) ; c a l l Leds. redon ( ) ; dbg (DBG_TEMP, " Tree c o n s t r u c t i o n process s t a r t e d. \n " ) ; e l s e { c a l l Leds. yellowon ( ) ; lab2appm.nc event r e s u l t _ t SpanningTreeControl. j o i n e d ( u i n t 1 6 _t parentid, u i n t 1 6 _ t height ) { dbg ( DBG_TEMP, " Node %d j o i n e d under Node %d w i t h height %d. \ n TOS_LOCAL_ADDRESS, parentid, height ) ; c a l l Leds. y e l l o w O f f ( ) ; c a l l Leds. greenon ( ) ; r e t u r n SUCCESS ;
Current Technology Current Technology Current sensor devices measured in cubic centimeters and contain 1. Processing unit -- Limited Processing Capabilities (0.6 MIPS) 2. Non-volatile storage -- Limited Memory Capabilities (32-512 Kb) 3. One or more Sensors (Light, Motion, Temperature, Seismic, Acoustic, etc.) 4. Wireless Communication -- Advances in low-cost communication Radio: 38.4 Kbits/sec @ 200m Bluetooth: 1 Mbits/sec @ 10m Optical: 30 bps @ 21.4 km 5. Battery power -- Operation may last up to a couple of months Future Trends Not-so-future Technology Current research tries to reduce size = Future sensor devices will be measured in cubic millimeters Current sensor networks operate with 100-1000 devices = Future networks will operate with 10000 devices Reduce energy consumption: Current sensor devices operate for months = Future sensor devices will operate for years An instance of Ubiquitous Computing -- the calm technology that recedes into the background of our lives - Mark Weiser
The Future: Smart Dust MICA Mote Platform (1) second generation mote module used for research and development of low power, wireless, sensor networks low-power Atmega128L microcontroller running at 4MHz 128 Kbytes of flash program memory 4 Kbytes of system RAM RF Monolithics TR1000 transceiver 2 AA bateries MICA Mote Platform (2) maximum transmission range 30m (100 feet) digital potentiometer (DS1804) in order to dynamically adjust the transmission strength of the radio radio transceiver operates at 916.57 MHz (also at 413MHz) does not allow transmission and reception at the same time built in 8-channel analog to digital converter 51-pin connector used to attach different sensor boards We focus on applications for monitoring buildings important application of Wireless Sensor Networks (WSN) We wish to develop a proof of concept application Monitor indoor environments (temperature, light, motion) Multiple buildings at different locations Monitor all buildings (and data) through a single interface Support different types of users with different access levels
For each monitored building 1. Deploy wireless nodes in offices 2. Equip with temperature, light and camera sensors 3. Assign a control center (gateway) Connect control centers to AEOLUS Overlay Computing Platform (OCP) Provide access to sensed data to AEOLUS peers Gateways advertise the capabilities of the wireless networks XML documents describing available functionalities, location of nodes, sampling rate, accuracy AEOLUS peers discover operational sensor networks OCP services can index data OCP services can catalogue spatio-temporal coverage AEOLUS peers query for sensor readings XML documents describing interests, area, periodicity, accuracy, aggregation function Gateways respond with sensor readings OCP services can store data OCP services can replicate data Two parts developed: 1. Gateway application: integration with TinyOS 2. WWW application: integration with Google Earth Final user interface: 3D environment sensor data integrated with Google GIS access via web