Presentation is loading. Please wait.

Presentation is loading. Please wait.

CS 443 Advanced OS Fabián E. Bustamante, Spring 2005 The Emergence of Networking Abstractions & Techniques in TinyOS P. Levis, S. Madden, D. Gay, J. Polastre,

Similar presentations


Presentation on theme: "CS 443 Advanced OS Fabián E. Bustamante, Spring 2005 The Emergence of Networking Abstractions & Techniques in TinyOS P. Levis, S. Madden, D. Gay, J. Polastre,"— Presentation transcript:

1 CS 443 Advanced OS Fabián E. Bustamante, Spring 2005 The Emergence of Networking Abstractions & Techniques in TinyOS P. Levis, S. Madden, D. Gay, J. Polastre, R. Szewczyk, A. Woo, E. Brewer and D. Culler U. Berkeley, Intel Lab Berkeley, CSAIL MIT NSDI 2004 Presented by: Fabian Bustamante

2 2 Introduction Sensor networks/EmNets – Networked systems of small, often battery-powered embedded computers Are they substantially different from general purpose systems? Partial answer based on examples –Much work has been done on TinyOS (since 2000) Multiple research groups at Berkeley, CMU, UCLA, USC, … Multiple applications in the open –Focus on networking issues – at the core of their design as it can eat your battery

3 3 Current state of development Categories of networking abstractions –General - widely used, TinyOS provides mechanism & policies, e.g. multihop broadcast –Specialized - widely used, TinyOS provides mechanism, app provides policies, e.g. power management –In flux - w/o consensus, app implemented, e.g. epidemic protocols –Absent - appear widely in the literature, but rarely in apps System design techniques used in these abstractions: –Cross-layer control - reflects hw constrains & specialized nature of EmNets, also its desing-to-suite –Static resource allocation - small storage requires it –Snooping – collects as much as possible but eats power –Scheduled communication – coordination to avoids energy costs

4 4 TinyOS Design TinyOS focuses on three high-level goals: –Take account of current & likely future designs –Allow diverse implementations of both OS services & apps –Address specific challenges of sensor nets: Limited resources Concurrency-intensive operation Robustness App-specific requirements To support them –Modularity framework Allows the OS to adapt to hardware diversity Allows apps to reuse common software services & abstractions Based on component model – interface: set of commands & events –Event-driven concurrency model Need to handle high concurrency & multiple tasks at once No blocking or spin-loop → split-phase operations

5 5 Hardware Platforms Dramatic evolution in 3 years Rate of improvement it’s not like w/ desktops Processing/memory/communication balance != 1MIPS:1MB:1mbps

6 6 Applications Habitat Monitoring (TinyDB) –Patches of nodes gather environmental/nature data for months –Needs to keep energy consumption low Shooter Localization –Few nodes localize origin of bullet –Requires a high sample rate and fine-grain time synchronization Pursuer-Evader –Large network tracking evader & reporting pursuer –Requires mote localization and more advanced routing

7 7 Single-hop communication Active Messages – basic networking primitive of TinyOS Three major networking stacks – diffs in network hw/sw i/f –For reliable radio transm. - high-freq low-jitter channel sampling –Simplified by raising hw/sw i/f, but loosing fine grained power mgmt, lik-level packet ack, … Communication i/f –GenericComm encapsulates TinyOS network stack (AM i/f) –Msg buffer structures w/ fixed size –CSMA for media access –App & network stack exchange msg buffers through pointers –Alternative i/f for single-hop comm exist – S-MAC supports fragmentation at data link level

8 8 AM Stack Implementations - rene The RFM TR1000 component exports bit-level interface Data encoding & transmission in SEC_DED component CRCPACKETOBJ performs packet-to-byte translation, w/ CRC checking AM is responsible for application layer dispatch

9 9 AM Stack Implementations - mica Adds hw edge detection & byte-to-bit conversion on top of the RFM chip –more precise bit timing & increased data rates Separates media access control (ChannelMon), bit-level timing (RadioTiming) & data transfer (SpiByteFifo) MicaHighSpeedRadio signals events to AM layer CRC checks through interposition Later version introduced link-layer acks Low power listening, instead of idle listening, saves power by lowering radio sample rate, but requires longer start symbol & quick turn on

10 10 AM Stack Implementations – mica2 Based on Chipcon CC1000 radio –Performs bit synchronization & encoding –Exports a byte-level i/f –CC1000RadioInt replaces modular arch of mica Link-layer acknowledgments Low power listening, but less efficient New platforms supporting IEEE 802.15.4 should push most stuff to hw – including CRC checking & early packet rejection

11 11 AM Stack Implementations – S-MAC S-MAC on mica radio stacks - an alternative approach to layering SMAC component handles backoff, retransmission, RTS/CTS/ACK handshakes, fragmentation & radio duty cycle control PHY_RADIO performs CRC checking & byte buffering CODEC_MANCHESTER runs Manchester coding RADIO_CONTROL handles the low-level carrier sensing & start symbol detection

12 12 Analysis AM abstraction is general & widely used Lower levels of stack are implementation-specific & hardware-dependent HW diffs bet/ motes affect SW structure & network capabilities –Moving hw/sw boundaries –Changing division of work bet/ tasks & hw events, & implying != max critical sections & task lengths Example –Bit-level i/f in rene requires stack to handle interrupts at high enough rate that handler cannot encode/decode bytes –So, encoding/decoding deferred to tasks, but –Encoding layer has small buffer, so encoding (SEC_DED) must run a task per byte time, which means –No other task can run longer than a byte time

13 13 Multi-hop communication Ad-hoc multi-hop routing algorithms –Tree-based collection – nodes route/aggregate data to an endpoint –Intra-network routing – data transfer bet/ in-network end-points –Dissemination – data propagated to entire regions Tree-based routing –Primarily based on two pieces of info: parent node identifier & hop- count or depth from tree root –Routing tree is built via local broadcast from root followed by selective retransmission from its descendents –Nodes route/aggregate data to an endpoint, one level (as target) at a time, to the root Key design issue –How the routing tree is discovered & maintained –How the forwarding is performed –From beacon-flooding w/o history (BLess) to beaconless, filtered neighbor-set, retransmission, … (MultiHopRouter)

14 14 Multi-hop communication Intra-networking routing –Data is transferred between in-network end-points –E.g. DSDV, AODV, Directed diffusion, GPSR, … –Mainstay of Internet usage, but uncommon in TinyOS apps Reliable data dissemination –Two principal implementations Broadcast - easy to implement, reaches most nodes quick, collision & lossy links → multiple flooding Epidemic – xchange info to know when data propagation is needed, slow?, robust to transient disconnections, can reach later connected nodes –TinyDB uses a hybrid approach (flooding, then epidemic) to install & stop queries

15 15 Common Multi-Hop Developments Most current multi-hop routing implementations discover & manage list of neighboring nodes for possible routes Lossy & asymmetric links w/ dynamic characteristics – link quality estimator Routing layer implementations have begun to use Send & Intercept interfaces (getBuffer allows routing layer to control offset of app payload in msg buffer) Augment low-level network abstractions to include i/f for promiscuous communication, where the network stack can pass non-locally addressed packets up to a higher level component Recently - addition of a send queue

16 16 Observations Many multi-hop protocol implementations in TinyOS built on top of AM abstraction Applications predominantly used tree-based routing Applications increasingly using reliable dissemination for programming or reconfiguration Several progressions in development of multi-hop net –Evolution of a neighborhood management table with ability to reject asymmetric links & select low-loss routes –Use of snooping (as opposed to broadcast) to gather neighborhood information & construct initial routes –Appearance of send queues & some traditional networking techniques

17 17 Network services - Power mgmt TinyOS power mgmt. through the interaction of –Service’s StdControl.stop – to stop the service; At the end of a round of data collection, each mote calls StdControl.stop to stop both the onboard sensor hardware (IntersemaPressure) and the radio (CC1000M, UARTM) –The HPLPowerManagement component - puts the processor into power-save mode (via adjustPower) compatible w/ current hw state –The TinyOS timer service - At the start of the next data collection round, the timer wakes mote up, and StdControl.start is called to restart sensors and radio Power mgmt illustrates cross-layer control at a very low-level – HPLPowerManagement check w/ hw Power mgmt is an abstraction that must inherently be specialized

18 18 Network services - Time synch All implementations use service similarly –Rely on GenericComm hook to place a time stamp in packet – this allows very precise time-synchronization Current approach taken by TinyOS –Provide mechanism to get & set current system time, but depend on appls to choose when to invoke synchronization Another example of cross-layer control in TinyOS A general abstraction will do more than it’s needed Gradual time shifting is suitable in some situations, while others require sudden shifts to correct time

19 19 Abstractions General abstractions –The AM abstraction –Abstractions for tree-based routing, particularly Send & intercept i/f Specialized abstractions –Specialized abstractions have appeared for both power- management & time synchronization –General version for many services, such as time synch in TinyOS, are hard to get right In-flux abstractions –Commonly found but changing between apps & HW versions, often in conflicting fashion –Epidemic propagation Absent abstractions –A few abstractions expected to be there based on the literature, but that were absent in the code base –Distributed cluster formation –Incoming (receive) queues

20 20 Common Techniques Communication scheduling & snooping –Comm. sched. refers to disabling radio except during pre-arranged times when a pair of nodes expect to exchange data –Snooping tends to reduce the overall comm. burden on network, but requires node to spend energy listening to its radio & receiving packets Cross-Layer control: –Each node is generally dedicated to a single task – this allows app to choose which instance of a particular abstraction (e.g., S-MAC vs. AM) it prefers w/o concern for operation of other apps –App is the only SW component capable of orchestrating activities of all of the device’s subsystems –Resource constrained nature of sensor networks Static resource allocation: –Allocate buffers at compile-time, somewhat controversial –Much better to statically allocate right # of buffers, lead to better composition

21 21 EmNets vs. the Internet Internet –Collection of independent end points sharing a common routing infrastructure –Goal is connectivity –Tool is Internet Protocol –Intelligence is end to end EmNets –Networked systems of small, often battery-powered embedded computers –Homogeneous systems deployed for an application-specific & collaborative purpose –Resource constraints, this might change –A very different set of goals & principles –Every node is both a sensor & a router –Relative communication/computation cost → move from e2e logic to in-network processing

22 22 Conclusion Classify abstractions use in TinyOS based on code study –More mature – AM, tree-based routing –Most abstractions are not there yet Major reason for absence of consensus -unusual degree to which app specialization matters –Motes run only one app at a time – no need for shared abstractions –Power mgmt affects all level of system & always app-specific –Limited resources → specialized implementations –Real-time constrains of apps – need prices control over timing Some techniques that work well –Cross-layer control – better use of resource & more control over timing –Static resource planning – more robust & modular How lasting & wide-ranging are these trends?


Download ppt "CS 443 Advanced OS Fabián E. Bustamante, Spring 2005 The Emergence of Networking Abstractions & Techniques in TinyOS P. Levis, S. Madden, D. Gay, J. Polastre,"

Similar presentations


Ads by Google