The Emergence of Networking Abstractions & Techniques in TinyOS

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

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

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

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

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

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

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

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

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

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

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

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

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-countor 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)

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

Common Multi-Hop Developments • Most current multi-hoprouting 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 & Interceptinterfaces (getBuffer allows routing layer to control offset of app payload in msg buffer) • Augment low-level networkabstractions to include i/f for promiscuouscommunication, where the network stack can pass non-locallyaddressed packets up to a higher level component • Recently - addition of a sendqueue

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

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

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 whento 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

Abstractions • General abstractions • The AM abstraction • Abstractions for tree-based routing, particularly Send & intercept i/f • Specialized abstractions • Specializedabstractions have appeared for both power-management & time synchronization • General version for many services, such as time synch in TinyOS, are hard to getright • 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

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

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

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?

The Emergence of Networking Abstractions & Techniques in TinyOS