TinyOS

1. TinyOS By Morgan Leider CS 411 with Mike Rowe

2. Background • Created at UCBerkeley • Used by over 500 groups • tinyos.net • Uses • Habitat Monitoring • Shooter Localization • Pursuer-Evader

3. Design Features • Cross-layer control • Static Resource allocation • Snooping & scheduled communication

4. Design Requirements • Work with current and future designs • Allow diverse implementation of operating system services and applications • Support varying hardware • Address the unusual challenges of sensor networks

5. Hardware • Motes-small resource constrained computing nodes • Mica motes • Radio capable of 40Kbps • 4Mhz processor • 1-4k of ram • Up to 128K of storage • 32Khz external clock

6. General code info • TinyOS requires 400 bytes for core OS • Supports • Event-driven execution • Flexible concurrency model • Tasks • Events • Component oriented application design • Apps use only the components they need

7. Language • Written in nesC • An extension of C • Stripped down • No function pointers • Static • No dynamic memory allocation • Call-graph fully known at run time

8. Writing in nesC • Everything is a component • Module – application code, implements interfaces • Configurations – connect interfaces • All components use modular interfaces • Group commands and events together • Bi-directional interfaces to support hardware interrupts

9. Writing in nesC • Discourage sharing of data • Asynchronous operation with interrupts • Synchronous operation with tasks • Make event code atomic • Optimizes • Inlines small functions • Eleminates unreachable code • Reduces cpu usage by 30% and code size by 10%

10. TinyOS features • Multi-hop communication • Tree-based collection • Intra-network routing • Dissemination • Broadcast – everyone transmits once • Epidemic – send when needed, snoop

11. TinyOS Features • Scheduling • Timed listening and communication • Reduces collisions • Extends Life • Synchronization • Time-stamped messages • External Clock • Accurate to within +/- 1 ms

12. Flexible Power Scheduling • Idle listening costs tons of power • Provides communication schedules for local nodes • Tree based topology • Adaptive slotted communication schedule used to route packets • Allows for global routing schedules • Base/root nodes have higher duty cycles

13. Node States + Reservations • Sending • Receiving • Advertisement – receive from parent node with available reservation slot • Transmit pending – send reservation request • Receive pending – receive a reservation request from child • Idle

14. Effects of Power Scheduling • High efficiency AA battery gives about 221 hours or 9 days of operation without power management. • 1274 hours or 53 days of operation with power scheduling • Can be increased even more

15. Trickle – A TinyOS component • “A self-regulating algorithm for code propagation and maintenance in wireless sensor networks” • Designed with 3 principles • Low maintenance – scalable and infrequent data exchanges • Rapid propagation – must be able to update every node in a network within 2 mins • Scalability – handle few to hundreds of neighbors, don’t rely on mapped info because wireless networks change

16. Trickle’s (Polite Gossip) • Periodically broadcast code summaries to local neighbors • Stay quiet if another neighbor has broadcast identical code summary • Older summaries result in broadcast of an update • Newer summaries result in request for update • Few seconds of operation an hour • Prevents network flooding

17. Trickle’s Code • Requires only 11 bytes of state on node • Broadcasts and listens every interval I for time T • Transmission time is T/2 • Max of 2 transmissions every interval i • Transmissions suppress other broadcasts • Each node has a 1/(num of local node/ max 75) chance of broadcasting

18. Trickle’s Code • If over 75 neighbors, collisions begin to happen • 512/75 or 1024/75 chance of broadcasting • Does not have overhead of discovering and maintaining local groups

19. Trickle’s Benefits • Traditionally – have to rebroadcast all code to entire network if a node disconnects for a while • Trickle – local distribution where needed • Tremendous power savings • 1 bit broadcasted costs 1000 cpu cycles of power • 64k file costs days worth of operation time

20. TinyDB – A TinyOS component • Problems with databases in wireless networks • Frequency of queries • Relevance of a node’s data • Order of query samples • Is a sample worth processing?

21. TinyDB features • Query optimization • Do work on motes to reduce broadcast size • Eliminate recursive queries • Identification of similar or unchanged info • Ability to specify sampling rate and minimum sampling rate • Dynamic adjustment of sampling rate based upon power and minimum specified lifetime

22. Deluge – A variant of Trickle • Trickle is designed for single packet dissemination • Deluge designed to handle large data objects

23. Deluge Features • Message suppression • Robust asymmetric link creation • Get rid of bad and find new neighbors • Dynamic advertisement rate adjustment • Minimize collisions in node cells • Spatial multiplexing allows parallel transfers of data

24. How Deluge works • Divides data objects into fixed-size pages • Broadcasts all pages, in order • Must receive 1 page before can start the next • 16 bit cyclic redundancy checks • Updates OS by page • Capable of catching up nodes with only local communication

25. Conclusions • TinyOS is a highly customizable and adaptable operating system. • Used by hundreds of reported groups. • Open source. • Dozens of modules available for download for free at tinyos.net Any Questions?